This article is based on insights originally shared on networkworld.com, drawing on firsthand observations from the RSA Conference and the intersection of DevOps and security practices.
The DevSecOps Debate: Two Seemingly Contradictory Principles
The RSA Conference — one of the major annual enterprise security events — has increasingly devoted track time to security in the software development process. Among the topics gaining traction is the convergence of security and DevOps, variously branded as SecDevOps or DevSecOps. Strip away the buzzwords, though, and there are two foundational principles worth examining carefully:
- Security is a process, not a product.
- Security is about behavior, not process.
At first glance, these sound contradictory. But read them end to end — behavior first, then process — and they form a coherent philosophy:
Security is about behavior, not process. Security is a process, not a product.
Behavior is the foundation. Process is what you build on top of it. Products and tools come last — not first.
Why Security Teams Can’t Scale Through Process Alone
A widely cited observation in security circles is that most organizations have roughly 1.6 security professionals for every 100 developers. Whether or not that exact figure holds universally, the underlying point is undeniable: security teams are dramatically outnumbered.
This ratio makes one thing clear — a security team cannot audit, review, and remediate its way to secure software by acting as a gate at the end of the pipeline. There simply aren’t enough people. The only scalable approach is to change the security culture within the development team itself: to create a security mindset rather than a security checkpoint.
This is the behavioral dimension. Until developers understand why security matters — not just that it’s required — any process imposed on them will be treated as friction rather than value.
Building a Security Culture: Start With the Why
Training in foundational security concepts is a practical starting point. When developers understand the real-world consequences of common vulnerabilities — SQL injection, insecure deserialization, broken authentication — they are far more likely to internalize secure coding practices rather than treating security reviews as a bureaucratic hurdle.
Effective approaches to building a security culture include:
- Secure coding training tailored to the languages and frameworks the team actually uses.
- Threat modeling workshops that involve developers early in the design phase, not after code is already written.
- Security champions programs — embedding a security-aware developer within each team who serves as a local resource and advocate.
- Blameless post-mortems on security incidents, treating them as learning opportunities rather than occasions for punishment.
- Making security visible in sprint reviews and team metrics, so it isn’t invisible until something goes wrong.
Establishing a Security Process: The How Follows the Why
Once a team has the cultural foundation — once developers genuinely care about building secure software — you can define a repeatable security process. A well-known reference point is Microsoft’s Security Development Lifecycle (SDL), which structures security activities across each phase of development: requirements, design, implementation, verification, and release.
The key principle when establishing a process is to start simple. A minimal, consistently followed process beats an elaborate one that gets bypassed under delivery pressure. Typical components of a pragmatic DevSecOps process include:
- Threat modeling during design to identify risks before a line of code is written.
- Peer code review with a security lens, using defined criteria for what reviewers should look for.
- Static Application Security Testing (SAST) integrated into the CI pipeline to catch common vulnerabilities automatically.
- Software Composition Analysis (SCA) to identify known vulnerabilities in open-source dependencies.
- Dynamic testing (DAST) against running services as part of integration or staging pipelines.
- Security sign-off criteria as part of the definition of done, not as a separate post-development gate.
Tools Are an Amplifier, Not a Substitute
A common failure pattern in DevSecOps adoption is jumping straight to tooling. The thinking goes: “If we deploy a SAST scanner, our code will be secure.” It won’t be — at least not without the cultural and process foundations in place first.
A telling example: a static analysis tool deployed at one organization surfaced thousands of issues. Management was satisfied with the dashboards. Developers, having no security process or culture to anchor the findings to, ignored the output entirely. The tool generated noise, not improvement.
Tools work when:
- Developers already understand what the findings mean and why they matter.
- There is a defined process for triaging, prioritizing, and remediating findings.
- The tool output is actionable — low false-positive rates, clear remediation guidance, and integration with the existing workflow (e.g., tickets filed automatically in the team’s issue tracker).
- Teams have the time and support to act on findings, not just generate them.
In short: tools amplify an existing process. They cannot replace one that doesn’t exist.
The Open Source Dimension
For teams building open-source software, the challenge is compounded. Contributions come not only from employees but from a globally distributed community of external contributors, each with varying security awareness and backgrounds.
The fundamentals, however, remain identical. The goal is community buy-in — making the importance of security a shared value that contributors understand and embrace, rather than a set of rules imposed by maintainers. Practical measures for open-source projects include:
- A clearly documented security policy (commonly a
SECURITY.mdfile) covering responsible disclosure, supported versions, and how to report vulnerabilities. - Automated security checks on pull requests, so every contribution is screened consistently regardless of who submits it.
- A contributor guide that includes security expectations alongside code style and testing requirements.
- A private channel for reporting security issues, so vulnerabilities are not disclosed publicly before a fix is available.
The Sequence That Works
To summarize the approach in the order that it actually has to happen in practice:
- Build behavioral change first. Invest in training, champions, and culture so developers care about security outcomes.
- Define a simple, repeatable process. Identify where in the SDLC security activities belong and make them part of normal workflow.
- Select tools that reinforce the process. Choose tooling that integrates with your CI/CD pipeline and produces actionable, low-noise output.
- Iterate and mature. Start simple, measure outcomes, and gradually expand coverage as the team’s security capability grows.
Security products are everywhere. Security behavior is rare — and it is behavior, not a purchase order, that actually reduces risk.