This article is based on an opinion piece originally published at cso.com.au. The arguments below expand on the original commentary for a DevOps engineering audience.
DevOps Is an Attitude — And Attitude Has Limits
DevOps brings genuine strengths to software delivery: faster iteration cycles, tighter collaboration between historically siloed teams, and a culture that prizes continuous improvement over rigid hand-offs. These qualities are valuable — but they are organisational and cultural qualities, not security capabilities.
Sophisticated cyber threats do not care how quickly a team can pivot. They require deep, specialised technical knowledge — the kind accumulated by dedicated security professionals over years of hands-on threat research, incident response, and adversarial thinking. An engineering team that has absorbed a “security mindset” through a DevOps transformation is better than one that has not, but it is not a substitute for that depth of expertise.
The risk, in fact, runs the other way: a fast-moving DevOps team without adequate security governance may introduce vulnerabilities more quickly than a slower, more cautious team would. Speed amplifies both good and bad decisions.
What Is Wrong With DevSecOps as Commonly Practiced?
The term DevSecOps — integrating security into the DevOps pipeline — has become widely used. The intent is sound: shift security left, catch vulnerabilities earlier, and make security a shared responsibility rather than a last-minute gate. In practice, however, organisations often implement it by embedding a security engineer or two inside individual product teams, then declaring the problem solved.
This approach has a structural weakness: it fragments security expertise. A single embedded security engineer can only cover so many threat vectors, review so many pull requests, and attend so many sprint ceremonies. When that person is spread across one team’s backlog, the broader organisation loses the aggregated intelligence that a centralised security function provides — pattern recognition across multiple projects, unified incident response, and the institutional memory of how past attacks unfolded.
Cybersecurity is a domain where collective expertise compounds. A team of five security specialists working together can cross-reference threat intelligence, escalate unusual signals, and cover one another’s blind spots in ways that five isolated individuals embedded in separate squads cannot.
A Better Model: Centralised Security as an Internal Consultancy
Most mature organisations already maintain a centralised security function. The improvement is not structural — it is about how that team engages with the rest of engineering.
Rather than operating as a reactive gate at the end of a release cycle (“does this pass a security scan before it ships?”), the security team should act as an internal consultancy that engages early and continuously:
- At the planning stage: Security requirements, threat models, and data classification decisions should be established before a line of code is written. This avoids expensive rework and prevents insecure-by-design architectures from reaching production.
- During development: Code review, dependency auditing, and secrets management guidance should flow from the security team into the DevOps pipeline — ideally through automated tooling that the security team owns and maintains.
- At release: Penetration testing, compliance verification, and sign-off on security controls should be a defined checkpoint, much as legal review is a checkpoint for contracts and marketing copy.
- Post-release: Ongoing vulnerability management, patching oversight, and threat monitoring remain the security team’s responsibility — not a burden distributed to developers who have already moved on to the next sprint.
The key phrase is passing through cybersecurity at the planning stage — not as a bureaucratic obstacle, but as a value-adding technical review that saves time and cost downstream.
Three Principles for a Security Team That Works With DevOps
For a centralised security team to function effectively alongside fast-moving DevOps teams, it needs three things that are often absent in practice:
1. Authority
Security controls — password policies, encryption standards, network segmentation rules, secrets rotation — must be enforced, not negotiated. A security team that can be overruled by a product manager under deadline pressure will not produce secure software. Authority means that security decisions carry organisational weight, backed by executive sponsorship.
2. Assurance
The security team provides assurance not by saying “trust us, it’s fine” but by systematically reviewing code, data flows, and operational workflows against defined enterprise security standards. This includes threat modelling, security architecture review, and formal sign-off processes that generate an auditable record.
3. Autonomy
The security team must retain the independence to act on its own judgment — to initiate a penetration test without waiting for a sprint to end, to patch a critical vulnerability outside a scheduled release window, or to escalate an incident without first seeking consensus from the affected product team. Autonomy is what allows security to function as a genuine check on the broader organisation rather than a department that can be managed around.
What This Means in Practice for DevOps Teams
For engineers working within a DevOps model, the practical implication is straightforward: security is a peer discipline, not a subordinate service. Engaging the security team early — before architecture decisions are locked in, before third-party dependencies are chosen, before a cloud service is provisioned — produces better outcomes with less friction than engaging them at the end.
Some concrete practices that support this model:
- Include a security team representative in project kick-off meetings and architecture design reviews.
- Use threat modelling frameworks (such as STRIDE or PASTA) as part of sprint zero activities for any feature that handles sensitive data.
- Integrate security-owned scanning tools (SAST, DAST, dependency checkers) into CI/CD pipelines, with the security team responsible for tuning and maintaining those tools.
- Define a clear escalation path so that developers know how to raise a potential security issue without it disappearing into a backlog.
- Treat security sign-off as a definition-of-done criterion for features that handle authentication, authorisation, payments, or personal data.
The Talent Scarcity Problem
Skilled cybersecurity professionals are in short supply across the industry. This scarcity is itself an argument against fragmenting security expertise across individual DevOps teams. Centralising those skills means the organisation gets the maximum return from each security hire — through shared tooling, shared threat intelligence, shared incident response capacity, and a coherent security posture rather than a patchwork of team-by-team interpretations.
Embedding security engineers wholesale into product teams may feel like a DevOps-native solution, but it risks burning out specialists who spend their days reviewing YAML configurations rather than working on the problems they were hired to solve. Retention of security talent is itself a security risk.
The Bottom Line
DevOps is a powerful delivery model. DevSecOps, as a cultural principle — writing more secure code, thinking about attack surfaces during design — is a worthwhile extension of it. But neither replaces the need for a centralised, authoritative, autonomous cybersecurity function that sits alongside the DevOps process rather than inside it.
The goal is not to slow DevOps down with bureaucratic security gates. It is to give fast-moving engineering teams a credible, expert partner that helps them ship securely — and that has the organisational standing to enforce that security when the stakes are high enough to matter.