This article is based on reporting originally published on InfoQ.
Security Becomes the Next Frontier for DevOps Teams
DevOps transformed how engineering teams ship software by uniting development and operations around shared tooling, automated pipelines, and a culture of continuous delivery. The next major challenge those teams face is security. In most organizations, security controls still operate as external gates — checklists and approval queues that slow releases down rather than integrated processes that move at the pace of the pipeline.
Gartner analysts predicted that the share of DevOps teams integrating security practices would grow from roughly 40% to approximately 90% by 2022, reflecting a broad industry shift toward what is now commonly called DevSecOps. Whether that specific forecast materialized on schedule is worth verifying, but the directional trend is widely corroborated by industry surveys and practitioner experience.
Why Integrating Security Into DevOps Matters
When security is treated as an afterthought, vulnerabilities are caught late — after code is already in production — when fixes are expensive and the blast radius of a breach is large. Embedding security throughout the software development lifecycle provides several concrete benefits:
- Earlier defect detection: Finding a vulnerability at the code-writing stage costs a fraction of what it costs to patch a production system.
- Reduced data breach risk: Teams that understand the threats their applications face can defend against the right risks in the right places.
- Continuous feedback: Security tooling wired into a CI/CD pipeline provides developers with actionable signals at the same cadence as build and test results.
- Scalability: Automated security controls grow with the team; manual review queues do not.
Shifting Security Left — and Extending It Right
The DevSecOps model asks teams to do two things simultaneously: shift left by integrating security earlier in development, and extend right by maintaining security visibility into production operations. As Jeff Williams, CTO of Contrast Security, explained:
“DevOps has dramatically improved the way that teams ship software quality and performance. DevSecOps has similar benefits for security, but requires changes in culture, people, process, and technology. Successful teams are both shifting security ‘left’ into development as well as extending ‘right’ into operations, and they’re leveraging instrumentation-based approaches like IAST and RASP instead of traditional outside-in scanners and firewalls.”
Jeff Williams, CTO, Contrast Security
Training is a foundational part of this cultural change. As Calvin Lo, program manager for training at Security Compass, noted:
“Training and security education is another crucial piece of the puzzle. By understanding threats and weaknesses of how applications are hacked, software professionals can gain direct expertise and then prevent many common problems from happening in the first place.”
Calvin Lo, Security Compass
Key Security Tools for the DevOps Pipeline
Several categories of tooling are particularly well suited to the DevSecOps pipeline. Each addresses a different phase of the development and operations lifecycle.
Interactive Application Security Testing (IAST)
IAST instruments a running application — much like APM tools such as New Relic, Dynatrace, and AppDynamics instrument it for performance — to detect security defects in real time without requiring dedicated security expertise on every team. Because IAST observes the application from the inside, it can identify issues that network-level scanners miss, including:
- SQL Injection: User input reaching an SQL command without proper validation.
- XML External Entity (XXE): An XML parser configured in a way that exposes local files to external users.
- API flow mapping: Understanding how data moves through an application to inform automated threat modelling.
Software Composition Analysis (SCA)
Modern applications depend heavily on third-party and open-source libraries. SCA tools scan those dependencies to identify known vulnerabilities (referenced in databases such as the NVD) and flag potential licence conflicts before they reach production. Tools like OWASP Dependency Check are well-established open-source options in this space.
Runtime Application Self-Protection (RASP)
Where a Web Application Firewall (WAF) watches network traffic from the outside, RASP lives inside the application runtime and can observe exactly how data is used by the code. This gives it the context to distinguish a real exploit attempt that reaches sensitive logic from an irrelevant crawler request — a distinction that WAFs structurally cannot make. RASP can block attacks while providing developers with information that is directly actionable at the code level.
Chaos Engineering
Chaos Engineering deliberately introduces failures — degraded dependencies, network partitions, resource exhaustion — into a system before unplanned incidents do. While not a security tool in the traditional sense, it builds resilience and helps teams understand failure modes that attackers might exploit, such as inadequate error handling or insecure fallback behaviours.
Why Traditional Security Tools Struggle in a DevOps Context
Many legacy security tools were designed for slower, waterfall-style release cycles. They create friction rather than feedback when dropped into a modern pipeline:
- Static Application Security Testing (SAST): Traditional static analysis can be slow to run and prone to high false-positive rates, particularly when it cannot traverse non-imperative code flows such as dependency injection or inversion-of-control frameworks. Triaging false positives requires security expertise that most development teams do not have in-house.
- Web Application Firewalls (WAFs): WAFs can see network traffic but lack architectural visibility into what the application code actually does with that data. Operations teams end up flooded with alerts from irrelevant crawler traffic, while developers get statistics (for example, SQL Injection block counts) that may be meaningless if the application uses a NoSQL database. The critical question — could this attack actually succeed? — often goes unanswered.
The core challenge for any security tooling in a DevOps pipeline is the combination of speed, accuracy, and appropriate skillset requirements. Tools that are too slow, too noisy, or too complex to interpret will be ignored or bypassed by teams under delivery pressure.
Where to Start: Frameworks and Resources
Teams looking to build or mature a DevSecOps practice have several well-established starting points:
- Microsoft Security Development Lifecycle (SDL): A process framework that prescribes security activities at each phase of development.
- OWASP: The Open Web Application Security Project provides free guidance, checklists, and tools including OWASP Dependency Check and the OWASP Top Ten.
- Gartner’s Application Security Hype Cycle: Useful for understanding the maturity and trajectory of specific security technologies.
- Free training: Vendors and non-profits offer role-specific security training for both managers and technical practitioners. Security Compass’s SD Elements platform is one example; OWASP and SANS also provide widely used educational resources.
Summary
Security in DevOps is not a single tool purchase or a one-time audit. It is an ongoing discipline that requires the same cultural investment as DevOps itself: shared ownership, automated feedback, continuous improvement, and a willingness to change existing processes. Teams that treat security as an integrated engineering concern — rather than an external compliance function — are better positioned to ship software that is both fast and defensible.