How Security as Code Can Accelerate DevSecOps

In 2021, major hacks are revealing new vulnerabilities to modern applications and the infrastructure they run on. GitLab’s Cindy Blake shows IDN why automation and security-as-code can provide broad protections and deliver a more reliable DevSecOps.

Tags: application, CI, DevOps, DevSecOps, IaC, pipelines, security,

Cindy Blake, GitLab
Cindy Blake
Sr. Product Marketing Manager & Security Specialist

"The rise in recent attacks has made us stop and think how to secure more than just the code. Some attacks highlight a failure to protect the SDLC process."

Application Architecture Summit
Modern Application Development for Digital Business Success
September 23,
Virtual Summit

Security as Code is a driving force for the current evolution of application security. It goes hand-in-hand with modern software development and the rise of Infrastructure as Code.


The DevOps methodology has broken down the silos between Dev and Ops, while the cloud has contributed toward empowering developers to start coding quickly. The infrastructure needed to house the code in the cloud can be easily configured. 


It’s this configuration step that often exposes opportunities for mistakes and security vulnerabilities. In order to eliminate manual steps and to improve consistency and security, these configurations become codified as Infrastructure-as-code (IaC).


IaC enables scale, speed, consistency, visibility, and traceability of changes made to each configuration. The challenge is there are many levers to pull. With configuration settings in cloud services, containers, orchestrators, and in software build and deployment tools, it’s difficult to be confident about proper overall configuration.


With automation, policies can be configured centrally and applied consistently to all projects, removing individual decision-making (and its potential for error) but creating a centralized target for anyone wanting to inject malicious configurations.


Therein lies the danger.


Configuration can be automated, repeatable, and follow standards or, it can be a mess of one-offs created without understanding the impact of the choices. Either way, security must be considered for the hardware, the apps, and the infrastructure that the apps depend upon as they’re developed, deployed, and used. With settings codified as IaC, you must treat THAT code with the same rigor you would of application code.


The catalyst here is automation - and how software time-to-use will be accelerated. Because the IaC is automated, it happens almost instantly. Now, you can push both infrastructure and code to production in one step. If it’s not secure though, vulnerabilities can be rolled out with the code with almost no time to test configuration integrity.


This necessitates automation of security checks, and the need to bake them into the software assembly and deployment processes rather than as separate efforts handled by separate security teams. So in the end, IaC begets Security-as-code.

IaC Requires a New Way of Thinking About Software Security

The rise in recent attacks have made us all stop and think about the security of the software factory itself and how to secure more than just the code. Some attacks highlight a failure to protect the SDLC process.


In the wake of increasing attacks, President Biden initiated an Executive Order for cybersecurity. Everyone in the software community should take notice as this could potentially require a level of effort not seen since Y2K where every application was inspected for how it handled date variables and many required re-architecture. This new focus on securing the software supply chain promises a similar level of introspection.

Where to Start? Security Automation – or Security-as-Code

The most fundamental step is security automation, or security-as-code. It is best enabled by uniting and simplifying development and security processes within a single platform. This powerful automation is needed to secure IaC and to provide controls demanded by modern applications and upcoming regulations.


There are three main elements to address:

Deliver more secure code. This means automatically test the code you create, within the CI pipeline, to identify and remove vulnerability risks. Determine execution policies for what scans are used and to what scope of your application portfolio they’re applied.


Ideally, you’d want to run at least SAST, DAST, dependency and container scans at every code commit. Consider a DevOps platform that has all these scanners built in to eliminate complex tool chain integrations. Next, determine policies for actions required when vulnerabilities are identified.


Secure app’s surrounding infrastructure.  This requires testing for misconfigurations then monitor for unanticipated changes.


Consider all the many aspects of your modern software, including:

  1. Containers - what’s in them (libraries and dependencies).
  2. Orchestrators (ex. Kubernetes) - configured to direct how, where, and when containers run, governing which apps can talk to which other apps and what compute and storage resources are each app allowed to consume.
  3. Cloud services - the environment hosting virtual machines and containers.
  4. Coded configurations (IaC) such as APIs, packages, Helm charts, Terraform, etc. As monolithic apps get broken into microservices, authentication and authorization embrace more use of APIs. You must test them and ideally capture, store, and view all cloud API calls for audit purposes.

Secure the software factory itself.
 This entails securing the CI pipeline, that is essentially your software assembly line, against malicious intervention. Managing access (human, machine, and API) is fundamental. Apply Zero Trust principles that include things like least privilege access to your DevOps tool chain and the application’s infrastructure above. Access Management isn’t enough alone. An automated CI/CD can consistently apply additional common controls for compliance such as separation of duties, merge approvals, and more (which in turn also simplifies audits).

Modern software applications require modern application security methods, even beyond simply shifting left. As development cycles accelerate, security as code becomes paramount. With this change comes added benefits not possible with traditional more siloed methods -- velocity, visibility to risk, and control.


Prepare now for this broader scope of application security by truly embedding security into your software factory, end-to-end.


Cindy Blake is the Senior Security Evangelist at GitLab, a provider of software for DevOps and SDLC.  Cindy collaborates around best practices for integrated DevSecOps application security solutions with major enterprises. She is also the author of The CISOs Guide to Securing Next-Gen Software.