Reframing DevSecOps: Software Security to Software Safety

For over a decade DevSecOps has promised to improve security by removing silos between development, security and operations teams. Done correctly, this approach integrates security throughout the entire development life cycle, increasing velocity, decreasing costs and reducing security incidents.

However, organizations often think they’re “doing DevSecOps” when they’ve simply created new teams (Dev, Sec and Ops) and bolted on new security tools that fail to achieve an integrated, governed process. A laundry list of security tools (SAST, DAST, SCA, CSPM) produces a mountain of vulnerability findings, employing entire security teams to manage. Similarly, developers are sifting through a frustrating amount of noise.

Organizations are not to blame. The security industry is promoting more problem-identification tools without improving the quality of the organizational processes or workflow to get better results. Security that is superficially added to existing processes rather than genuinely integrated creates significant operational burden in development workflows. This is DevOps + security — not truly DevSecOps.

The result is that more valuable developer time is consumed understanding and fixing issues while vulnerabilities, knowingly or unknowingly, pass through the pipelines into production. This cycle of inefficient and largely ineffective security practices, coupled with the constant tension between development velocity and security requirements, leads to burnout among both security and development teams.

Why Software Supply-Chain Safety Matters

Instead, organizations should converge platform engineering and product security engineering teams into shared processes as a way forward. This fosters closer collaboration and a shared understanding of the entire system life cycle, enabling teams to integrate security as a practice directly into these shared processes in a manner that is developer-centric and organic to the teams they serve. With security woven into the fabric of the organization, tools serve as assurance mechanisms after safe practices have been employed and problem identification aids rather than being relied upon as primary security controls.

A templatized, repeatable, process-led approach, driven by collaboration between platform and security teams, leads to a fundamental shift in the way teams think about their objectives. They move from the concept of security, which promises a state free from danger or threat, to safety, which focuses on creating systems that are protected from and unlikely to create danger. This shift emphasizes proactive risk mitigation through thoughtful, reusable design patterns and implementation rather than reactive threat mitigation.

Supply Chain Safety Building Blocks

The following processes, independent of tooling, are the building blocks for systems that increase the safety of infrastructure and first-party applications. While these controls don’t guarantee zero security issues, they greatly reduce the possibility by improving code and infrastructure safety standards.

• Infrastructure guardrails: Platform engineering practices provide standardized templates for deploying secure infrastructure components, allowing developers to focus on application development. These templates enforce security measures, such as encryption and logging, preventing common cloud misconfigurations and ensuring security observability.
• Language features and frameworks: Modern programming languages offer built-in security features that help reduce vulnerabilities when used correctly. Enabling features like automated memory management and strict type-checking can prevent many potential security issues.
• Toil reduction via code generation and refactoring: Automated tools can identify vulnerable libraries and dependencies, allowing for easier remediation through templates and minimal base images. By using AI for code analysis and refactoring, developers can eliminate unnecessary dependencies, reducing the attack surface and maintenance burden.
• Abstract security functions: Security sidecar proxies handle authentication and authorization across applications, ensuring only authorized services can communicate. A service mesh control plane can be used to manage access controls centrally, reducing the complexity of application code while consistently enforcing security.
• Software governance: Rules such as branch protection and dual approval can be programmatically enforced to ensure multiple team members review changes before code is merged. These policies, defined in machine-readable formats, should be enforced by the CI platform to maintain consistent security across projects.
• The human factor: Successful DevSecOps requires aligning incentives and integrating security into the development workflow. By fostering collaboration through training, shared metrics, and regular cross-team meetings, teams can reduce operational burdens and improve software resiliency together.

Strategic Tool Implementation

The recommendations above focus on improved engineering practices, which are the foundation of DevSecOps’ value. Once teams have invested in these fundamentals, tools can provide assurance checks as a function of safety. For example, organizations can leverage dependency proxies to create a controlled environment where all third-party packages are automatically scanned, validated and cached before reaching development environments.

Security tooling should also be integrated strategically into CI pipelines, using a tiered scanning approach that balances speed and thoroughness. High-fidelity, fast-running checks, such as secrets detection, software composition analysis (SCA) and bespoke rules for security anti-patterns, should be run on every commit and enforced by the CI system.

Process-Led Roadmap to Future Success

The outcomes between security products and product security are vastly different with the latter producing far greater value. Instead of continuing to shift responsibilities, development teams should embrace the platform security engineering paradigm. By building security directly into shared processes and operations, development teams can scale up to meet their needs today and in the future.

Only after these strong foundations have been established should teams layer in routinely run security tools for assurance and problem identification. This approach, combined with aligned incentives and genuine collaboration between teams, creates a more sustainable path to secure software development that works at scale.