As DevOps adoption has accelerated, one question has become unavoidable: where does security fit? Traditional security gates — bolt-on reviews at the end of a release cycle — simply cannot keep pace with continuous delivery pipelines. The following four topics, drawn from a panel discussion featuring Maria Loughlin and Chris Eng of CA Veracode and Alan Shimel of DevOps.com, outline the key considerations for any engineering team trying to weave security into a genuine DevOps practice.
1. A New Mindset and a New Speed
Moving from traditional software delivery to DevOps changes the tempo of everything — including security. Release cycles that once took months now take days or hours. Legacy security workflows designed around infrequent, large releases create bottlenecks when applied to small, rapid deployments.
Two specific gaps need attention:
- Scale. The volume of code being merged and deployed at any given time is far greater in a DevOps environment. Security tooling and processes must scale horizontally to match.
- Expertise. Many development teams lack deep security knowledge. If developers don’t understand common vulnerability classes — injection flaws, insecure dependencies, misconfigured secrets — they can’t be expected to avoid or fix them independently.
Addressing these gaps begins by accepting that the old model is incompatible with modern delivery speeds, and committing to a fundamentally different approach.
2. Faster, Cheaper, Better: Security Through Automation
Counterintuitively, DevOps creates genuine opportunities to improve security posture rather than degrade it — provided the right practices are in place.
Two DevOps principles directly support this:
- Shared operational responsibility. In a DevOps culture, engineers own outcomes end-to-end — from code commit to production health. Extending that ownership to security is a natural next step, not an external imposition.
- Automation and small batch sizes. Continuous delivery of small, incremental changes means that each change is easier to review and test. Automated Static Application Security Testing (SAST), Software Composition Analysis (SCA), and secret scanning can run inside CI pipelines and produce results in the same feedback loop developers already use. The more security is automated, the lower its marginal cost per deployment — and the more readily it is adopted because it no longer feels like an obstacle.
The practical goal is to make security checks a normal part of the pipeline — running alongside unit tests and linters — rather than a separate process owned by a separate team operating on a separate timeline.
3. The People Aspect: Just as Important as the Technology
Tooling alone does not produce a secure DevOps practice. How development and security teams interact with each other is equally important, and frequently overlooked.
Key principles for healthy cross-team collaboration:
- Empathy and respect. Security engineers need to understand delivery pressure. Development engineers need to understand threat models. Neither team serves the business well by treating the other as an obstacle.
- Risk-based, contextual prioritization. Not every vulnerability is critical. Security teams that insist on blocking a release over a low-severity theoretical risk in a non-public-facing service will erode the trust needed for long-term collaboration. A risk-based approach — triaging findings by exploitability, exposure, and business impact — keeps the relationship functional.
- Leadership alignment. The partnership between development and security must be modeled and mandated from the top. When security and engineering leadership share a common goal and hold each other accountable, that culture propagates downward through the teams.
The security team’s role in a DevOps environment shifts from gatekeeper to enabler — providing libraries, patterns, scanning tools, and guidance that make it easier for developers to build securely from the start.
4. Parting Advice: Start Small, Think Long-Term
Practical guidance from practitioners who have navigated this transformation tends to converge on several consistent themes:
- Make the secure path the easy path. Provide pre-approved, pre-hardened building blocks — base container images, internal libraries, infrastructure modules — so that developers default to secure choices without having to become security experts themselves. Reducing friction is the most durable way to improve secure behavior at scale.
- Start small and iterate. Attempting to instrument every pipeline, remediate every vulnerability, and train every engineer simultaneously is a recipe for stalled programs. Pick one team, one pipeline, or one vulnerability class and build a working model. Demonstrated success builds organizational confidence and budget for the next phase.
- Invest in your people. Technology cannot compensate for a skills gap. Teams that don’t understand secure coding practices, common attack vectors, or the tools in the pipeline cannot be fully accountable for outcomes. Targeted training, pair programming with security engineers, and regular threat modeling exercises are all mechanisms for closing that gap.
- Secure executive sponsorship. A DevSecOps transformation that lacks visible support from leadership will stall at the team level. Executive sponsorship ensures that security investment is protected during roadmap negotiations and that cross-team conflicts get resolved rather than avoided.
Summary
Bringing security into a DevOps practice is not a single project with a finish line — it is an ongoing cultural and technical evolution. The four themes above provide a practical framework: adapt your mindset and tooling to the pace of DevOps, automate security to reduce its cost and friction, invest in the human relationships between teams, and build incrementally with leadership backing. Organizations that address all four dimensions together are better positioned to deliver software that is both fast and secure.
This article is based on a panel discussion originally published on DevOps.com, featuring Maria Loughlin and Chris Eng of CA Veracode and Alan Shimel of DevOps.com.