DevSecOps, Supply chain

Why we need a better approach to DevSecOps

AI software can now handle many DevOps tasks automatically, eliminating the need for manual work. This allows for quicker and more efficient IT processes.

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.

The role of tools

The recommendations I just outlined focus on improved engineering practices, which are the foundation of DevSecOps' value. Once teams have invested in these fundamentals, tools can offer 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 get 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.

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.

Josh Lemos, chief information security officer, GitLab

SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy.

You can skip this ad in 5 seconds