COMMENTARY: For over a decade DevSecOps has promised to improve security outcomes by removing silos between development, security, and operations teams. Done correctly, this approach integrates security throughout the entire development lifecycle, 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.[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]Organizations are not to blame. The security industry has promoted more problem-identification tools without improving the quality of the organizational processes or workflow, resulting in the same software outcomes. Security that’s superficially added to existing processes rather than genuinely integrated creates significant operational burden in development workflows. This is DevOps + Security – not DevSecOps. The result: more valuable developer time gets 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.
A case for software supply chain safety
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 lifecycle, letting teams integrate security as a practice directly into these shared processes in a manner that’s 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 how 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.The building blocks for supply chain safety
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.