By Josh Lemos, chief information security officer, GitLab.
For years, DevSecOps has promised to bolster security by removing silos between development, security, and operations teams and integrating security throughout the entire development lifecycle. When implemented correctly, this approach can increase speed, reduce costs, and minimise security incidents.
Many Australian organisations believe they are practicing DevSecOps when, in reality, they have merely added security teams and tools without achieving true integration or software governance. Security tools like Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Software Composition Analysis (SCA) can generate an overwhelming amount of vulnerability findings, leaving security teams and developers frustrated by excessive noise.
The root issue isn’t the organisations, but rather an industry prioritising problem detection over process improvement. Superficially adding security to existing workflows creates significant operational bottlenecks in development workflows. Without genuine integration, this approach is just DevOps plus security, not true DevSecOps.
This leads to valuable developer time lost identifying and addressing security issues, while vulnerabilities still make it into production, sometimes unnoticed. This inefficient cycle, combined with the constant tension between development speed and security demands, ultimately leads to burnout across both development and security teams.
Software supply chain safety matters
Instead, organisations 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 organisation, tools serve as assurance mechanisms and problem identification aids after safe practices have been employed rather than being relied upon as primary security controls.
A templatised, 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 emphasises proactive risk mitigation through thoughtful, reusable design patterns and implementation rather than reactive threat mitigation.
For example, AirWallex, an Australian-based fintech company, uses an AI-powered DevSecOps platform to incorporate security into its development processes while speeding up software delivery. By integrating automated security checks into its Continuous Integration and Continuous Delivery (CI/CD) pipelines, the company has minimised alert noise, identified vulnerabilities at an earlier stage, and streamlined workflows. Additionally, consolidating various DevOps tools into the DevSecOps platform has enhanced collaboration, increased visibility, and strengthened security while reducing costs.
Key components of 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 standardised 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 authorisation across applications, ensuring only authorised 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 in DevSecOps
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, local organisations can implement dependency proxies that automatically scan, validate, and cache third-party packages before they enter development environments.
Security tools should be integrated into CI pipelines using a tiered scanning approach that balances speed and thoroughness. Essential checks like Secrets Detection and Software Composition Analysis (SCA) should be run on every commit and enforced by the CI system.
The distinction between security products and product security is significant, with product security offering greater value. Development teams should embrace a platform security engineering approach, embedding security into shared processes to scale efforts effectively.
Once these foundations are built, teams can incorporate routine security tools for assurance and problem identification. This strategy, combined with collaborative efforts and aligned incentives, fosters a sustainable and scalable approach to secure software development in Australia.
