Implementing Multi‑Layered DevSecOps: Balancing Strong Security with Rapid, Frequent Deployments

Our DevSecOps approach is divided into multiple layers to strike a proper balance between the need for strong security and the demand for rapid, frequent deployments.

DevOps transformed how we integrate and release software, moving from slow, annual cycles to daily or even hourly releases. While DevOps broke many barriers and enabled fast market response, a critical barrier remains: security operations (SecOps).

To include this essential group in continuous integration and deployment (CI/CD), we redefine DevOps as DevSecOps. The challenge mirrors that of DevOps: developers want fast, frequent changes; operations need stability; security teams favor stability because each change may require repeated security testing and re‑certification.

How can we expect these teams to redo their work daily or weekly as we move at DevOps speed?

Security Layering

Before diving deeper, we should discuss a key security practice: layered security or defense‑in‑depth. This approach applies multiple overlapping security controls across layers, creating a network of defenses that work together to protect technical systems.

In a layered security model, companies mitigate intrusions using controls such as WAN gateway firewalls and static data encryption. No single control can fully protect a system, and the same principle applies to application security analysis.

Engage with your application security team to learn which scanning tools they use. Expect a list of tools or tool types rather than a single solution, because no one tool can cover everything.

This raises the earlier question: when running many scans with many tools, how can we maintain a continuous deployment cycle? Some scans take hours or days, making this a daunting task.

Inline Scanning

Although some security tools require long runtimes, faster tools can be used early in the development lifecycle to form the first DevSecOps layer. This embodies the "shift‑left" concept—moving processes from the end of the lifecycle to the beginning or middle.

The first layer should include tools that run in seconds or minutes, such as code linters, unit tests, static code analyzers like SonarQube, OWASP Dependency‑Check, and a subset of integration tests.

You might wonder how code cleanup and unit testing fit into DevSecOps. Software bugs provide perfect footholds for attackers; for example, OWASP’s top web‑app security reports (2013, 2017) list code injection as the #1 vulnerability. Unit tests and static analysis help catch these errors early, potentially preventing security flaws.

Because these scans are quick, they should be placed at the far left of the lifecycle. When developers push code to the Git repository and open a pull request, these tools run to ensure the code passes before merging, keeping the main branch buildable and giving developers rapid feedback.

Pre‑Deployment Scanning

The second DevSecOps layer runs within the deployment pipeline and may take minutes to an hour. It can include deeper third‑party vulnerability scans, Docker image scans, and malware scans.

A key point is that scanners run after the build artifact is created but before it is stored in an artifact repository such as Artifactory or Amazon Elastic Container Registry. Any failure at this stage should immediately halt the deployment and alert the development team.

Parallelization is also crucial in this layer and beyond. Developers want their changes deployed quickly, and running multiple scans sequentially (each possibly lasting an hour) would unnecessarily slow the pipeline. Running scans in parallel reduces total time to the duration of the longest scan.

Post‑Deployment Scanning

The next layer runs after code is deployed to a pre‑production environment. Tools may include performance and integration tests as well as application scanners like OWASP ZAP. This layer should be fast—ideally under an hour—to give developers quick feedback and limit impact on the CD flow.

To avoid shipping vulnerable code to production, this layer must be part of the CD pipeline and be capable of deleting the artifact, rolling back the environment, or failing the pipeline if a vulnerability is found.

Depending on industry, security, and regulatory requirements, successful completion of this layer can automatically trigger production deployment, provided sufficient automated scans and tests demonstrate the application’s security and robustness.

Continuous Scanning

Most of the scanners discussed are embedded in the CI/CD pipeline. Our goal is to provide reasonable security assurance while minimizing impact on pipeline timelines.

The final DevSecOps layer is Continuous Scanning (CS), analogous to continuous integration, testing, and deployment in DevOps. CS includes tools such as Nessus, Qualys, IBM App Scan, and other infrastructure, application, and network scanners.

CS runs asynchronously, delivering ongoing feedback to developers. How developers receive and act on this feedback requires agreement among stakeholders; developers should address feedback promptly and resolve issues within an appropriate turnaround time.

The frequency and trigger mechanisms for these tools must also be agreed upon. After deployment, tools can be invoked via CI/CD pipelines using APIs, or they can run on a schedule. Regardless of the method, scans should run frequently—not just once a year—to provide meaningful security coverage.

Conclusion

Just as a single tool or principle cannot guarantee the security of a technical system, the security of an application cannot rely on one or two tools or scanners. A layered approach that applies diverse tools and scans is required to reasonably ensure the safety of both the application and the underlying infrastructure.