Remember when (at least part of) the industry realised "DevOps isn't a job title"? We're making the same mistake again, now with DevSecOps. Companies are hiring "DevSecOps Engineers," thinking they've solved security.
They've just renamed the problem.
The Déjà Vu Moment
Some years ago, organisations started to rush into hire "DevOps Engineers" believing they could buy their way into better collaboration and faster delivery. Instead, they got siloed teams with new titles, operating much like the old separation between development and operations.
The 2016 State of DevOps Report by Puppet (published by DORA.dev now) found that high-performing organisations treated DevOps as a cultural practice, not a job description. Teams that successfully adopted DevOps had shared ownership across roles. The same principle applies to security.
What DevSecOps Really Means
DevSecOps isn't about adding another specialist to your team. It's embedding security thinking throughout your software lifecycle:
- Planning: Threat modelling during design reviews
- Development: Secure coding practices and peer review
- Build: Automated security scanning in CI/CD
- Deploy: Infrastructure-as-code validation and policy enforcement
- Operate: Runtime security monitoring and incident response
When security becomes everyone's concern, it stops being an afterthought.
The Trap of Security Silos
Here's what happens when you hire a "DevSecOps Engineer":
- The team feels relieved "security is handled now"
- Developers stop thinking about security in daily work
- The DevSecOps person becomes a bottleneck
- Security issues pile up in a backlog
- When breaches happen, there's finger-pointing
This creates false ownership. Security becomes "someone else's problem" — just with a fancier title. One person can't review every line of code, attend every architecture discussion, or monitor every deployment. They become a gatekeeper rather than an enabler.
According to the 2023 State of DevOps Report by DORA (DevOps Research and Assessment), organisations with distributed security practices had 2.6x faster incident response times compared to those with centralised security teams.
Shared Responsibility in Practice
What does shared security responsibility actually look like?
CI/CD Pipeline Security
- Developers write secure code and run pre-commit hooks
- Platform teams configure and maintain security scanning tools
- Security specialists set policies and review high-risk changes
- Everyone responds to vulnerability alerts in their domain
Infrastructure-as-Code Reviews
- Infrastructure engineers implement secure-by-default configurations
- Developers review IaC changes that affect their applications
- Security teams provide baseline policies and compliance checks
- Managers ensure time is allocated for security work
Threat Modelling
- Product managers identify high-value assets and attack surfaces
- Architects design systems with security constraints in mind
- Engineers implement controls and mitigations
- Security experts facilitate sessions and provide guidance
Everyone contributes based on their expertise and context.
Building a Security-First Culture
Cultural change doesn't happen by mandate. It requires:
Psychological Safety: Teams need to report vulnerabilities without blame. Google's Project Aristotle research identified psychological safety as the foundation of high-performing teams. The same applies to security: a blameless postmortem culture focused on systems, not individuals, encourages transparency.
Tooling That Enables: Security tools should help developers ship faster, not slow them down. Fast feedback loops: Catching issues in the IDE or at commit time for example helps to reduce friction. The shift-left movement, documented in the Building Security In Maturity Model (BSIMM), shows that earlier detection dramatically reduces remediation costs.
Incentives That Align: If teams are measured only on feature velocity, security loses. Include security metrics in team goals: vulnerability remediation time, security test coverage, or compliance adherence.
Knowledge Sharing: Security champions programs, internal training sessions, or capture-the-flag exercises democratize security knowledge. The OWASP Security Champions Guide provides a framework for building these programs.
Investment in Training: Allocate budget for security training across all roles, not just security staff.
Measuring DevSecOps Maturity
How do you know your approach is working?
Process Metrics:
- Time from vulnerability discovery to remediation
- Percentage of security issues caught before production
- Number of security-related incidents
- Compliance audit findings trends
Cultural Metrics:
- Cross-functional participation in security reviews
- Security improvements suggested by non-security staff
- Team confidence scores around security practices
Operational Metrics:
- Mean time to detect (MTTD) security issues
- Mean time to respond (MTTR) to incidents
- Percentage of automated vs. manual security checks
Avoid vanity metrics like "number of DevSecOps engineers hired" or "security tools purchased." These measure inputs, not outcomes, outcome-based metrics drive real improvement.
Making It Real: A Roadmap
Starting this journey? Here's a pragmatic approach:
Month 1-2: Assess and Educate
- Survey current security practices
- Identify gaps and quick wins
- Run awareness sessions across teams (maybe even start with this one!)
Month 3-4: Enable and Automate
- Implement security scanning in CI/CD
- Establish baseline policies for IaC and containers
- Create shared documentation and runbooks
Month 5-6: Embed and Iterate
- Integrate security into sprint planning
- Start regular cross-functional security reviews
- Gather feedback and adjust processes
Ongoing: Measure and Improve
- Review metrics quarterly
- Celebrate security wins publicly
- Evolve practices as threats change
The Role of Security Specialists
This doesn't mean security expertise doesn't matter. Specialised security professionals are crucial — but their role shifts from gatekeepers to enablers:
- Build platforms and tools that make secure practices easy
- Provide expertise for complex threat modelling
- Stay ahead of emerging threats and vulnerabilities
- Coach teams and build security capabilities
- Handle security incidents and forensics
They're force multipliers, not single points of failure.
Security isn't a department: It's a habit. DevSecOps succeeds when everyone owns it.
Stop looking for the perfect DevSecOps hire. Start building a culture where security is everyone's responsibility, supported by the right expertise, tools, and incentives. That's when security truly shifts left — not just in your pipeline, but in your thinking.
The question isn't "Who should we hire to do DevSecOps?" It's "How do we make our entire team security-conscious?" Answer that, and you'll build something far more resilient than any single role could provide.
Further Reading:
Top comments (0)