This article is based on commentary originally sourced from TechTarget, featuring insights from Ari Weil, Vice President and Senior Director of Industry Marketing at Akamai.
The DevSecOps Gap: Why Security Still Lags Behind Development
“If you’re not thinking about security at all, it’s crazy.” That blunt assessment from Ari Weil of Akamai captures a problem that has persisted in software delivery for years: despite well-publicized security breaches, many DevOps teams continue to treat security as a final-stage concern rather than a first-class requirement.
The DevSecOps movement promises to change that by shifting security left — integrating it from the earliest stages of the development lifecycle rather than bolting it on at the end. But in practice, adoption remains uneven. The cultural friction between developers and security professionals, combined with delivery pressure, means security checks are still frequently deferred until it is too late to address them cheaply.
Weil frames the core tension clearly: development teams move fast and ship frequently; security teams move deliberately and need time to evaluate risk. These rhythms collide. Even something as routine as selecting a third-party API carries security implications that often go unexamined under deadline pressure.
Tooling can help, but it is not sufficient on its own. “I don’t think tools will make this happen,” Weil said, “but in the same breath, without the right tools people have no ability to get ahead of this thing.” The real work is cultural and procedural, and it has to start somewhere practical.
Three Practical Steps to Integrate DevOps and Security
The good news is that you do not need to overhaul your entire pipeline overnight. Weil outlines three concrete, relatively low-friction steps that any team can take to begin bridging the gap between DevOps and security.
1. Start Where You Are
Before reaching for new frameworks or toolchains, take an honest inventory of your current state. Where is your organisation on its digital transformation journey? What external-facing applications are you building or maintaining today, and what security steps — if any — are already embedded in those workflows?
The key diagnostic question is simple: “What steps have I built into the process to make the app safer?” If the honest answer is “none,” that is your starting point, not a reason for paralysis.
Weil acknowledges that developers are rarely enthusiastic about adding security gates. The practical insight here is that developers will accept security measures that do not materially slow them down. Starting with low-friction controls — static analysis in the CI pipeline, dependency vulnerability scanning, pre-approved secure libraries — builds the habit without triggering resistance.
- Audit existing pipelines for any security checkpoints already in place.
- Identify the highest-risk external-facing applications as your first target.
- Choose tooling that integrates with existing developer workflows (IDE plugins, CI hooks) rather than requiring separate manual steps.
2. Communicate Freely — Break Down the Silo
The historical relationship between development and security teams is often adversarial: developers see security as a blocker; security teams see developers as a liability. Neither posture is productive.
Weil’s second step is to establish an ongoing, working relationship with whoever owns security in your organisation. This is not a one-time conversation before a release — it is a continuous channel. Security professionals are charged with keeping the business safe, which means they need visibility into what is being built and when. Developers, in turn, need early guidance so they can make informed decisions during design rather than scrambling to remediate issues at release time.
Practical ways to operationalise this include:
- Embedding a security champion or liaison within each development squad.
- Including security representatives in sprint planning and architecture review meetings.
- Creating shared Slack channels or equivalent spaces where both teams surface emerging issues without formal escalation overhead.
- Establishing a shared threat model that both teams contribute to and maintain.
The goal is mutual awareness: both sides should know about new projects, dependency changes, and infrastructure modifications before they reach production.
3. Embrace the Worst Case — Plan for Incidents Before They Happen
No matter how well you integrate security into development, incidents will occur. Weil’s third step is to prepare for them explicitly rather than improvising under pressure.
This means evaluating your security vendors and operational partners — the people responsible for your application once it is deployed — and asking hard questions before a breach forces the conversation:
- What is the run book when we come under attack? Who does what, in what order?
- What is the reporting process? How does information flow internally and, if required, to regulators or customers?
- What are the communication channels? Who is the single point of contact at each vendor or internal team?
- What does the SLA cover? What response time is contractually guaranteed, and what falls outside that scope?
Weil highlights a common failure mode: companies often discover a breach through social media rather than through their own monitoring, and then have no agreed plan for what to do next. That scenario — reactive, disorganised, public — is exactly the kind of incident that erodes trust in the security programme as a whole and can push teams back toward ignoring security entirely.
“If I can understand those basics, I can at least start building a cross-functional security effort,” Weil said. A documented incident response plan is both a practical roadmap and a forcing function: producing it surfaces gaps in coverage before an attacker does.
Key Takeaways
Bridging DevOps and security is fundamentally a people and process challenge that tooling can support but not replace. The three steps above are deliberately incremental:
- Audit what you have and identify where security is already absent from your delivery pipeline.
- Build a relationship between development and security teams before a crisis makes it necessary.
- Plan for failure by documenting your incident response process, SLAs, and communication channels now.
None of these steps requires a large budget or a new platform. They require intent, communication, and a willingness to treat security as a shared responsibility across the engineering organisation — which is precisely what DevSecOps, at its best, demands.