One of the most common questions I get from teams starting their DevSecOps journey is “okay, but who actually does what?” It’s a fair question — DevSecOps deliberately blurs the old lines between development, operations, and security, and that can leave people unsure where their responsibilities start and stop. Let’s clear that up.
The Core Idea: Shared, Not Siloed, Responsibility
In a traditional model, security was a separate team’s job. In DevSecOps, security is a shared responsibility distributed across roles — but “shared” doesn’t mean “nobody’s specifically accountable.” Each role has a distinct piece of the puzzle.
Developers
Developers are the front line of DevSecOps. Their responsibilities include:
- Writing secure code following established guidelines (input validation, parameterized queries, proper authentication handling)
- Fixing vulnerabilities flagged by automated scans in their code
- Participating in threat modeling for features they’re building
- Avoiding hardcoded secrets and using approved secrets management tools
Developers aren’t expected to become security experts overnight — they’re expected to apply the guardrails and guidance the security team provides.
Operations / Site Reliability Engineers (SREs)
Operations engineers focus on the infrastructure and runtime side:
- Hardening infrastructure configurations (servers, containers, cloud resources)
- Implementing least-privilege access controls
- Maintaining monitoring and alerting for security-relevant events
- Managing patching cycles for operating systems and platform dependencies
- Ensuring backup and disaster recovery procedures are tested and reliable
Security Engineers
Security engineers shift from being gatekeepers to being enablers:
- Selecting, configuring, and tuning security tooling (SAST, DAST, SCA, container scanning)
- Defining security policies and thresholds for automated pipeline gates
- Providing training and support to developers and security champions
- Leading incident response when something does go wrong
- Conducting deeper assessments like penetration testing for high-risk systems
Security Champions
A security champion is a developer or engineer embedded within a product or platform team who acts as the local point of contact for security matters:
- Triaging security findings for their team’s codebase
- Bridging communication between their team and the central security function
- Advocating for security work to be prioritized in sprint planning
- Helping onboard new team members to secure coding practices
flowchart TD
Sec[Security Engineering Team] --> Champ1[Security Champion - Team A]
Sec --> Champ2[Security Champion - Team B]
Champ1 --> Dev1[Developers - Team A]
Champ2 --> Dev2[Developers - Team B]
Dev1 --> Ops[Operations / SRE]
Dev2 --> Ops
Ops --> Sec
Engineering and Product Leadership
Leadership’s role is often underestimated:
- Allocating time and budget for security work, not just feature velocity
- Backing decisions to delay a release for a critical vulnerability
- Setting organizational risk tolerance and priorities
- Modeling the behavior they want to see (asking about security in planning meetings, not just after an incident)
Compliance and Governance Roles
In regulated industries, a compliance or governance function often works alongside the DevSecOps team to:
- Map technical controls to regulatory requirements (SOC 2, HIPAA, PCI-DSS)
- Maintain audit evidence generated automatically from the pipeline
- Track continuous compliance drift rather than relying solely on annual audits
How Roles Interact in Practice
A typical vulnerability lifecycle touches multiple roles: a security tool run in CI flags an issue, a security champion triages it, a developer fixes it, operations verifies the fix doesn’t affect production stability, and the security team confirms it’s resolved. No single role owns the whole process — but every role has a clear, specific job within it.
Common Mistakes Around Roles and Responsibilities
- Assuming “shared responsibility” means nobody owns anything. Without clear expectations, security work falls through the cracks.
- Overloading developers without support. Asking developers to “own security” without training, tooling, or time allocation sets them up to fail.
- Keeping security engineers as gatekeepers instead of enablers. This recreates the old friction DevSecOps was meant to eliminate.
- Leaving leadership out of the loop. Without leadership buy-in, other roles lack the authority or time to prioritize security work.
For readers building out infrastructure-facing responsibilities specifically, the Linux category and Networking category on this site cover a lot of the hands-on operational skills that back up the SRE and operations side of this picture.
FAQs
Do small teams need all of these roles filled separately? No — in small teams, one person often wears multiple hats (a developer who’s also the security champion, for example). What matters is that the responsibilities are covered, not that every role has a dedicated headcount.
Is a security champion a full-time role? Usually not — it’s typically a part-time responsibility layered onto an existing engineering role, supported by a small amount of dedicated time each week.
Who’s ultimately accountable if a breach happens? Accountability usually sits with leadership and the security team collectively, but the goal of clear role definitions is to prevent breaches from happening in the first place by making sure no responsibility falls through the cracks.
Conclusion
DevSecOps works best when responsibility is distributed but not diffused — everyone has a role, and every role is clearly defined. Developers write and fix code, operations hardens and monitors infrastructure, security engineers build the guardrails and respond to incidents, champions bridge the gap, and leadership makes sure everyone has the time and authority to do their part. Get the roles right, and the process takes care of itself.
