< Back to Blog Home

At this point, most everyone in the IT industry is aware of the term DevOps or Development Operations. DevOps is a fundamental shift in the way we build, test and deploy our applications and services.

When performed properly, the benefits are many for both the builder and the users of the application. However, as DevOps has increased our delivery velocity, there is a real possibility that security can be left behind. There is some truth to that as traditional security checks and gates can slow the release process down and therefore are often saved for only ‘big releases’.

One the main tenets of DevOps is “Infrastructure as Code”. This is accomplished by defining your infrastructure (servers, network, storage) in a programming language and via tools that deploy that infrastructure automatically. By doing so, infrastructure can now benefit from software engineering practices like version control, code review, and unit testing.

Building on this theme has been the introduction of “Security as Code”. As expected, this is the automation of security checks and gates via code and integrated into the overall DevOps process again following software engineering practices. Of course, saying it is easier than doing it, so we’ll cover the major points and provide direction.

Pro Tip

Even if your application’s release cadence doesn’t require the speed that automation provides, the benefits of consistency and the elimination of manual steps alone can improve security.

Continuous Integration and Continuous Delivery (CI/CD)

Commonly referred as ‘CI/CD’, both are fundamental to integrating Security as Code.

Continuous Integration is a core practice of Agile development where all changes to the code are automatically built and verified allowing problems to be caught quickly. Continuous Delivery builds on this practice and is the automation framework that powers DevOps.

In turn, Security as Code uses Continuous Delivery as its control backbone for automating security and compliance checks.

How do we get started? Just like when first introducing DevOps, there is planning involved before you start modifying your pipelines. To start, you need to understand what your application is potentially vulnerable to.

A common approach is threat modeling to help determine your potential threats, vulnerabilities, and attacks vectors. Time spent here will help inform the security checks that you should be performing as part of the process.

Another key factor is secure coding standards. What are acceptable coding practices (see Pro Tip below), and how will your development team peer review themselves to maintain the standard? What tools can you use as part of your Continuous Delivery to support these standards and practices and alert when deviated from?

Finally, and based heavily on your threat model, what attack simulation do you want to expose your application to. How often and for what type of releases?

Pro Tip: The OWASP Foundation provides many tools and guidance to help developers and organizations with application security. The key initiatives which support designing, developing and deploying secure applications are: