8 Ways to Secure Your Microservices Architecture
You’ve heard the saying “less is more”, but for developers and software architects, the opposite can be true— especially as customer and business demands mean they have to be more agile. The ongoing transition from monolithic architectures to microservices is a perfect example.
Compared to monolithic applications, which house all code in a single system, microservices are small, autonomous units that address individual functions and work with others to help an application function. This makes them a good choice for developers who need to deliver large, complex applications rapidly, frequently, and reliably. Operating with these distributed components brings several benefits, but also its own unique set of security requirements. Instead of a single entry point, microservices offer dozens or even hundreds of potential points of vulnerability—and as such each one needs to be effectively secured in order for an application to operate effectively.
4 benefits of microservices
While this may seem like a daunting task, securing your microservices comes down to implementing a series of best practices that make security an integral component to how your developer teams work—without compromising productivity.
Here are eight steps your teams can take to protect the integrity of your microservices architecture.
1. Make your microservices architecture secure by design
Much like construction workers need to strategically layer rebar and concrete to build strong foundations for skyscrapers, developers must embed layers of security in applications to protect the data they hold. Within microservices architecture, this means being “secure by design”—keeping security top of mind at every stage of production, from design to build to deployment.
When it comes to writing your code, this means implementing a form of continuous stress testing on your architecture. In part, this means testing your continuous integration (CI) and continuous delivery (CD) pipelines. This can be done by simultaneously implementing security unit tests such as static analysis security testing (SAST) and dynamic analysis security testing (DAST):
• SAST will detect vulnerabilities in your code, as well as the libraries you import. It works from the inside and therefore requires a scanner that’s compatible with your programming language.
• DAST works from the outside, mimicking malicious attacks, to identify vulnerabilities. Unlike SAST,
it doesn’t depend on a specific language.
These unit tests can be built into your delivery pipeline to help minimise the manual security checks that might burden your developers. The Open Web Application Security Project (OWASP) also offers a series of resources and analysis tools to help your team implement best practices as they build out software.
2. Scan for dependencies
Many libraries used to develop software depend in turn on other libraries, which means much of the code deployed to production consists of third-party dependencies. This makes security an even bigger concern, as these relationships could create large chains of dependencies, which might pose vulnerabilities for your systems.
These points of failure can be eliminated by regularly and thoroughly scanning an application’s source code repository, new code contributions, and deployment pipeline for vulnerable dependencies (including updated release versions).
While the majority of applications supply release notes, only 75% report security issues—and just 10% report common vulnerabilities and exposures. Knowing your dependencies helps ensure there are no vulnerabilities due to new pull requests and that your code is up to date at the time of deployment. In addition to enabling security alerts in your repository, tools like Github’s Dependabot can help automate updates via pull requests.
3. Use HTTPS everywhere
This may feel like a basic principle, but it’s important to implement consistently as a foundational el