Security as code: Best practices for continuous security and delivery
Why security should be treated as code and integrated into the development process
March 20, 2020 | By: Armando Franco
Just how DevOps defines infrastructure as code—through versioning, updating, automating—security needs to be defined as code, too.
What is security as code?
Security as code translates your guardrails and deployment into machine-readable language, building it into your DevOps process—from technical source deployment, security tools, feedback cycles and testing. It allows you to monitor all of it so you can see how your security is actually defined at any given point of time without costs or delays. And if there’s a problem, you can solve it.
How to insert security as code into continuous integration and delivery
Continuous integration and continuous delivery (CI/CD) set the foundation for integrating security as code in terms of automation and compliance. During continuous CI/CD, there is a continuous feedback loop every time code is changed or integrated, providing automated frameworks for building, testing and upgrading. Continuous security requires the same approach.
The first step to integrating security into your process is deeply understanding your environment, systems, architectures and technology platforms across your development and operations teams. Next is cleaning up all your libraries and frameworks—easier said than done. Finally, you’ll be positioned to integrate a risk and security design into your CI/CD workflow, automating security checks and controls in a way that is predictable and efficient.
When implementing security into your cloud technologies, it’s important to set up your cloud infrastructure in a way that is tangible through code. Security off-premise, especially in different environments, can be complex. It’s critical to ensure your production environments are fortified and treated as code in order to run your configurations through security accounts and monitor roles, privileges, authentications and authorizations in the cloud.
Two challenges of building security into DevOps practices
Before you can jump into implementing security as code, you need to set a solid foundation and understanding of your systems and frameworks, as well as your goals. Sometimes organizations will overwork their security solutions before they even define what their minimal acceptable risk is. The goal should never be to solve all security problems in one shot—the best approach is to start small, define a problem, then expand and scale.
Additionally, there’s not an expansive net of training available for building security upfront—you’ll need to compensate for this by leveraging real-world experience and developing your own learning solutions. To help create security champions, include your security analysts within your development teams and empower developers to develop with security in mind. For security to truly be folded into DevOps, security and development teams need to come together to embed automated tests and control management into the deployment cycle.
Continuous security is truly continuous. It’s an ongoing journey because there are always changes being made to policies and production. Ultimately, it comes down to an organization’s willingness to adopt change and shift from a Waterfall methodology to a DevSecOps culture, as well as shift from siloed teams to cross-functional or multifunctional DevOps teams—engineering, development, testing and operations all working together toward a common goal. When that happens, change follows quickly.
Armando Franco is a cloud and DevOps architect for TEKsystems Global Services. He is an expert in DevOps practices to implement next-generation cloud computing solutions to build lasting organizational value.