This article draws on expert perspectives originally published by TechTarget on the convergence of DevOps and security practices.
Why DevSecOps Is No Longer Optional
Call it DevSecOps, SecDevOps, or simply “security in DevOps”—the terminology is secondary. What matters is that software security can no longer be treated as a gate at the end of the delivery pipeline. With high-profile breaches continuing to make headlines, the question for most engineering organisations is not whether to integrate security into DevOps, but when and how.
The structural challenge is significant. According to Derek Weeks, VP and DevOps evangelist at Sonatype, a survey by the company found a ratio of roughly one security professional for every 100 developers. That imbalance means traditional security review processes—where a dedicated security team audits code before release—simply cannot scale. Engineering teams need a fundamentally different approach.
Five Practical Strategies for Adopting DevSecOps
1. Switch Roles to Build Empathy
One of the most effective ways to close the cultural gap between developers and security professionals is to have each side experience the other’s job. Derek Weeks recommends a structured exercise: have a security engineer spend a week building a small application, then have developers attempt to find flaws in it. The exercise works in the other direction too—developers building something they then hand over to security to attack.
This kind of role-switching creates genuine empathy. Developers gain an appreciation for how much thought goes into threat modelling, and security professionals gain respect for the constraints developers work under. “It’s hard to do and harder to build, but this lets each side see how it looks from the other,” Weeks noted.
2. Make Collaboration Informal and Continuous
Gene Kim, co-author of The DevOps Handbook, argues that small, low-friction steps can produce large cultural changes. His suggestion: invite a security professional to the team’s regular code review meeting. No new tools required.
The value is immediate. Instead of receiving a 120-page audit report when code is nearly in production, developers get quick, actionable feedback during a meeting they already attend. Security professionals, in turn, stop being perceived as blockers and start being seen as collaborators. “Informality builds gratitude and mutual trust when you have a common goal,” Kim said.
Practical starting points for informal security collaboration include:
- Inviting a security engineer to sprint planning or backlog refinement sessions
- Adding a standing security agenda item to retrospectives
- Using shared Slack channels or chat tools so security feedback is visible in the developer workflow
3. Automate Security Testing Early—Don’t Hunt for Problems
Given the shortage of security professionals, relying on manual security reviews is neither scalable nor efficient. Weeks recommends shifting from a “hunter” mindset—where someone manually searches for vulnerabilities—to an automated testing mindset, where security checks are built into the CI/CD pipeline from the start.
This means starting the conversation about security requirements at the requirements stage, not after the first release candidate is cut. Automated security testing tools—covering static analysis (SAST), dependency vulnerability scanning, and dynamic analysis (DAST)—should be integrated into the same pipeline that runs unit and integration tests.
Key places to embed automated security checks:
- Pre-commit hooks: Lint for known insecure patterns before code is even pushed
- CI pipeline: Run SAST tools and dependency scanners on every pull request
- Staging environment: Execute DAST and penetration testing tools against running applications
- Production monitoring: Use runtime application self-protection (RASP) or observability tools to detect anomalies
4. Create Developer Security Champions
Tim Buntel, VP of Products at XebiaLabs (now Digital.ai), identified a structural solution to the security skills shortage: the security champion model. Rather than relying solely on a central security team, organisations identify developers within each team who take a special interest in security and are given additional training and responsibility.
Security champions serve as a bridge. They are embedded in the development team—understanding its velocity and constraints—but maintain a close relationship with the central security function. They can raise security concerns early, advocate for secure design patterns, and review pull requests with a security lens without creating bottlenecks.
There is also a career incentive. As Buntel noted, security expertise is highly valued in the market. A developer who invests time in learning common vulnerability classes, secure coding patterns, and threat modelling becomes more valuable both to their current employer and to the broader industry.
“If someone takes the time to learn about the top 10 security flaws, it’s going to increase their professional value and the value to the team.”
Tim Buntel, VP of Products, XebiaLabs
5. Train Developers in Security Fundamentals
Pete Chestna, Director of Developer Engagement at Veracode, points to an obvious but often overlooked fact: most developers have received little or no formal security training. Addressing this directly pays significant dividends.
Chestna applies a 90/10 rule: roughly 90% of common vulnerabilities can be avoided by developers who understand a relatively small set of security concepts. SQL injection, cross-site scripting (XSS), insecure direct object references, and misuse of cryptographic libraries are not advanced topics—they are learnable by any experienced developer with a modest investment of time.
Resources for getting started with developer security training include:
- The OWASP Top 10 list of critical web application security risks
- OWASP’s WebGoat and Juice Shop intentionally vulnerable applications for hands-on practice
- Secure coding guidelines published by language-specific communities (e.g., the Python, Java, and Go security documentation)
- Internal lunch-and-learn sessions led by security champions or external specialists
DevSecOps Is a Cultural Shift, Not Just a Tooling Change
The common thread across all five strategies is cultural change. Tools matter—automated scanning, dependency management, and secrets detection all reduce risk—but tools alone will not close the gap between development velocity and security assurance.
DevSecOps succeeds when security is treated as a shared responsibility across the entire engineering organisation, rather than a function owned exclusively by a separate team. That means hiring decisions, onboarding processes, sprint ceremonies, and architectural review boards all need to reflect security as a first-class concern—not an afterthought appended to the definition of done.
Starting small is fine. Inviting a security engineer to one meeting, automating one class of vulnerability checks, or running one role-switching exercise can begin to shift the culture. The goal is to make incremental, sustainable progress rather than attempting a wholesale transformation that collapses under its own weight.
Key Takeaways
- The developer-to-security-professional ratio makes manual security reviews unscalable; automation and shared responsibility are the only viable paths forward.
- Role-switching exercises between developers and security engineers build lasting empathy and collaboration.
- Embedding security professionals informally in existing developer rituals (standups, code reviews) is a low-cost, high-impact first step.
- Automated security testing should be integrated at every stage of the CI/CD pipeline, starting from requirements.
- Developer security champions reduce dependency on centralised security teams and create career growth opportunities.
- Basic security training for developers eliminates the majority of common vulnerability classes at low cost.