Embracing the 'shift left' approach in secure software development at Glasswall

The concept of "shifting left" has been integral to software development since testing expert Larry Smith introduced it in 2001, advocating for integrating the QA process earlier in the lifecycle. In the realm of security, this term has gained substantial traction, emphasizing the importance of incorporating security measures early in the Software Development Lifecycle (SDLC). But why do we shift left? And once shifted, how do we maintain that position? Why not just start left from the beginning?

At Glasswall, automation is at the core of our development processes, a principle we’ve detailed in previous blog posts. Automation has empowered us not only to shift left but to stay left. However, automation's effectiveness hinges on a robust framework of requirements, encapsulated in our well-defined Secure Software Development Lifecycle (SSDLC). The SSDLC integrates security from the beginning of the development process and sets clear expectations for our development practices, making the automation process seamless.

A high-level overview

Our SSDLC is the blueprint for secure development at Glasswall. While SDLCs generally consist of rules or guidelines to follow, we recognized early on that merely referencing these guidelines is not enough. They need to be deeply integrated into daily activities to avoid overlooked requirements and ensure consistent security practices.

To embed our SDLC into the daily workflows of our development teams, we integrated some key principles directly into Azure DevOps. Here’s how we did it:

Templates

Managing multiple security tools across various build pipelines can be complex and resource-intensive. Implementing each tool independently for every pipeline isn’t feasible. This is where templates come in.

We’ve developed a set of templates for each type of security tool we use—Static Application Security Testing (SAST), Software Composition Analysis (SCA), Infrastructure as Code (IaC), Container Scanning, and more. These templates standardize and simplify the integration process.

Each template manages the implementation and configuration of its respective tool, including setting severity thresholds, scan types, code directories/locations, etc. This allows us to selectively apply these templates to specific pipelines based on the requirements of each service.

Build validation and triggers

In our SDLC, every Pull Request must undergo scrutiny by security scanners and tools. Using our templated security tools, we’ve implemented triggers and build validation to ensure that each Pull Request activates the relevant security templates for its service. These templates act as security gates, ensuring only vulnerability-free code is merged into the master or main branches.

Additionally, we’ve set up scheduled triggers to routinely scan and report on our master codebase at least once a week, providing a consistent security baseline.

By embedding these principles into our daily workflows, we’ve created a secure, automated development environment that aligns with our SSDLC. Stay tuned for more insights into how we continue to innovate and secure our development practices at Glasswall.