Adding another three letters to an already acronym-heavy field might seem like unnecessary jargon, but DevSecOps represents a genuinely important evolution of the DevOps mindset — one that many organisations are still failing to adopt.
What Is DevOps — and What Does Security Have to Do With It?
DevOps is broadly defined as the practice of breaking down silos between software development and IT operations teams, using automation and shared tooling so that both sides work toward common goals: shipping better, more stable software, faster. The cultural and process shift is as important as the tooling.
The problem is that security has historically been treated as a gate at the end of the pipeline — a quality check run by a specialist team immediately before (or, worse, after) release. That model is fundamentally incompatible with modern continuous delivery practices, where code ships frequently and at speed.
What Is DevSecOps?
DevSecOps means integrating security practices, tooling, and expertise into every phase of the software development lifecycle — from design and coding through testing, deployment, and operations. Rather than treating security as a separate discipline owned by one team, DevSecOps distributes security responsibility across the entire pipeline while still relying on specialist knowledge to define and automate the controls.
Red Hat’s chief security architect Mike Bursell framed it clearly in an interview with Computerworld UK:
“If you’re doing DevOps but not putting security at the centre of your process, you’re not doing DevOps properly. This isn’t to say that security should take over everything you do, because if that is what’s happening then you’re heading for paralysis, but that you should design security into your DevOps cycles. That’s DevSecOps.”
Mike Bursell, Chief Security Architect, Red Hat
Bursell adds that a good DevSecOps approach combines tools, process, and culture: engaging security experts, making them part of the delivery team, and having them embed their knowledge into automated processes so the whole organisation benefits — not just those with a security background.
Tools Are Not Enough
A common mistake when transitioning to DevOps — or DevSecOps — is treating tool acquisition as the primary goal. Meera Rao, senior principal consultant at Synopsys, cautions against this:
“Tools aren’t a catch-all solution. DevSecOps can’t be simplified solely by automating a set of tools. However, when tool automation is implemented well, its merits are irrefutable. When it’s done poorly, development, operations, and security teams will waste time, effort, and budget as a result.”
Meera Rao, Senior Principal Consultant, Synopsys
The lesson: select tools that fit your workflow and team culture, not the other way around. Automation should encode and enforce agreed security policies — not replace the thinking behind them.
You Don’t Need Every Developer to Become a Security Expert
One anxiety teams often raise is whether DevSecOps means every engineer must now become a security specialist. It doesn’t. As Bursell explained:
“I love security, but not everybody does, and you don’t want to be saying to every developer: ‘you now have to become a security expert’ — because that’s a lot to take in, and it’s never going to happen. But if you say, on the other hand, I have particular people or roles whose responsibility it is to ensure our policies are automated into the processes, then we just make sure people follow the processes and we can manage by exception — then it starts to make sense.”
Mike Bursell, Red Hat
Security awareness among developers is valuable and worth cultivating, but the architecture of a DevSecOps programme should not depend on every engineer having deep security knowledge. Automation and specialist-owned policies carry that weight.
The Risks of Leaving Security Until the End
Excluding security from early development stages creates compounding risk. Some realistic failure scenarios include:
- The security team discovers critical vulnerabilities at pre-release, forcing expensive late-stage remediation and delaying the release.
- An insecure release ships, is caught post-launch, and must be pulled back — damaging customer trust and team morale.
- An insecure version reaches production, is exploited by attackers, results in a data breach, and triggers regulatory penalties, reputational damage, and significant financial loss.
The further a security defect travels through the SDLC before being caught, the more expensive it is to fix — in engineering time, in process disruption, and in potential business impact. Shifting security left reduces that cost significantly.
What Does “Doing DevSecOps Right” Actually Look Like?
DevSecOps is a continuous improvement journey rather than a project with a defined end state. That said, there are concrete practices to build toward:
Open Communication and Collaboration
Security, development, and operations teams need visibility into each other’s work. Shared collaboration tools, unified dashboards, and joint planning sessions reduce friction between teams and prevent security from becoming an afterthought dropped in at the end of a sprint.
As Rao explains: “Application security teams should choose the most appropriate tools, technologies, and processes that support close collaboration” — specifically to break down the traditional silos between development, operations, and security.
Repeatable, Auditable Processes
Comprehensive changelogs, clear rollback points, and auditable pipelines are foundational. Rao notes: “Creating a repeatable and auditable process is important for DevSecOps teams to rely on and establish a budget around. Enabling security activities that adapt quickly to meet the challenges of changing business goals and continuously evolving threats facilitates collaborative change within a DevSecOps programme.”
Shifting Security Left
Daniel Kennedy, research director for information security at 451 Research, points to a measurable indicator of a functioning application security programme: defects being resolved earlier in the SDLC — “farther to the left,” in industry parlance.
“If SAST-type capabilities are being put in the hands of developers, as well as developer education components relevant to the code problem identified, less vulnerable code should make it into the builds. A later regression test or security audit should see a lower number of security defects. The continuous improvement piece comes in if you can start to introduce defects at a lower rate — and fix them earlier in the SDLC. Thus, they’re touched by fewer people, early in the cycle, and have the least impact and cost to fix.”
Daniel Kennedy, Research Director, Information Security, 451 Research
Measuring Progress
Quarterly reviews help teams stay on course. Rao suggests anchoring reviews around three questions:
- Where are we in implementing DevSecOps today?
- What challenges are we facing, and how can we overcome them?
- What is working well, and how can we address shortcomings?
Track metrics like the reduction in security defects identified per release, the stage at which defects are being caught, and the time-to-remediation for security issues. These provide both short-term feedback and long-term trend data.
DevSecOps Jargon Buster
The following terms come up frequently in DevSecOps discussions:
CI/CD — Continuous Integration / Continuous Delivery
The practice of automatically integrating, testing, and delivering code changes on a frequent basis. CI/CD pipelines are the primary mechanism through which security gates and automated testing are embedded into the development process. The goal is stable, releasable code at all times.
Continuous Integration (CI)
The practice of merging developer code changes back into the main branch frequently — often multiple times a day — with each merge triggering automated tests. This avoids the painful “integration hell” that occurs when teams delay merging until release day.
Continuous Delivery (CD)
The automated deployment of application code through a series of environments — development, staging, production — so that release-ready code can be shipped with minimal manual intervention.
IDE — Integrated Development Environment
A software application that provides developers with a code editor, compiler or interpreter, debugger, and build automation tools in a single interface. Security-focused IDE plugins can surface vulnerabilities as code is written, enabling immediate remediation.
SDLC — Software Development Lifecycle
The end-to-end process of planning, creating, testing, and deploying software. Typically represented as a cycle with phases including requirements analysis, design, implementation, testing, deployment, and maintenance. DevSecOps integrates security activities into each of these phases rather than treating security as a single late-stage gate.
SAST — Static Application Security Testing
A category of security tooling that analyses application source code, bytecode, or binaries for patterns indicative of security vulnerabilities — without executing the application. SAST tools can be integrated directly into CI pipelines and IDEs, giving developers immediate feedback on potential security issues as they code.
The Bottom Line
No system can be made 100% secure, but embedding security into your DevOps pipeline from the outset — rather than bolting it on at the end — dramatically reduces the probability and cost of serious vulnerabilities reaching production. DevSecOps is not a product you can buy or a project you can complete; it is a cultural and operational shift that pays dividends in reduced risk, lower remediation costs, and faster, more confident delivery.
Original source: techcentral.ie (via BestDevOps.com, August 2018). Quotes from Mike Bursell, Meera Rao, and Daniel Kennedy sourced from Computerworld UK.