A DevSecOps culture lasts when secure behavior is the easy default, teams own the risk in their own services, and feedback arrives fast enough to act on. Training and posters help little by themselves. Change the pipeline, the incentives and the ownership model, and attitudes follow.
What does culture mean in practice?
OWASP's Security Culture project frames it as the shared values, habits and practices that shape how an organization handles security. In engineering terms, culture is what people do when nobody is checking: whether they raise a concern during design, whether a failing scan blocks a release, whether a post incident review ends in a fix.
NIST's Secure Software Development Framework (SP 800-218) gives the practices behind that: prepare the organization, protect the software, produce well secured software and respond to vulnerabilities. It is practice oriented and does not prescribe tools. CISA's Secure by Design material adds a principle that shapes culture: manufacturers should take ownership of customer security outcomes, rather than shifting burden to users.
What changes behavior most?
Defaults over decisions. If a new service template ships with authentication, logging, dependency scanning and a restrictive policy already wired in, the secure path costs nothing. If security is an extra ticket, it loses to deadlines.
Fast, local feedback. A finding in the pull request, with a suggested fix, gets handled. The same finding in a quarterly PDF does not. Feedback also has to be trustworthy: if a tool cries wolf, people stop reading.
Clear ownership. Each service has a named team that owns its vulnerabilities. A central security team that owns everything owns nothing in practice.
Shared language. Developers and security staff should use the same severity scale and the same definition of done for a fix.
Constructed example: a 40 engineer company
The security lead used to send monthly lists of vulnerabilities, which engineers called noise. She changed three things. First, the service template got a pipeline step that fails on newly introduced critical flaws that are reachable from the code. Second, each team got a dashboard of its own findings, sorted by exploitability. Third, one engineer per team became a security champion with two hours a week reserved for this work and a seat in design reviews.
Within a quarter the arguments shifted from "why is security blocking us" to "why is this one still open". Nothing about people changed. The system did.
What commonly goes wrong?
- Gates with no escape hatch, so teams route around them.
- Gates with too many false positives, so teams ignore them.
- Metrics that reward closed tickets rather than reduced risk.
- Blame after incidents, which teaches people to hide mistakes.
- Champions appointed without time to do the work.
How do you measure progress?
Use outcomes, not activity. Time from disclosure to fix for exploited vulnerabilities, share of services using the template, number of design reviews with a security voice, and recurrence of the same class of flaw all say more than training completion rates.
Safeguard's policies and gates run in pull requests and CI, and its reachability analysis helps keep findings relevant so that people keep trusting the signal. Gates can be tuned per team, and automated fix pull requests are off by default, so teams adopt automation at their own pace.
How to check or apply this
- Pick one pain point developers already complain about, such as slow reviews or noisy scans, and fix it first.
- Put security checks in the service template so new projects start secure.
- Show each team its own findings, ranked by exploitability and reachability.
- Name a champion per team and protect their time.
- Write blameless reviews after incidents and track the follow up fixes.
- Agree on a short exception process with an expiry date.
- Review outcome metrics quarterly and drop checks nobody acts on.
Quick check
Does security training change culture?
It helps awareness but rarely changes habits alone. Defaults, fast feedback and ownership change what people do daily.
What is a security champion?
A developer who acts as a team's point of contact for security, with reserved time to review designs and help triage findings.
Sources
- OWASP Security Culture project
- NIST SP 800-218, Secure Software Development Framework
- CISA, Secure by Design
Last reviewed: 18 October 2026.
