DevOps has become a popular way of ‘shifting left’ infrastructure, making it easily consumable, in a self-service manner for developers. Tools like HashiCorp Terraform automate public cloud resource consumption and make it both testable and reproducible. By using the same continuous integration, deployment and delivery pipeline methodologies, infrastructure is becoming a commodity. While the DevOps movement makes infrastructure consumption easy, there are other areas that are not yet as fortunate. Both testing (unit, performance, load) as well as security are not so easy to shift left.
But what is shift left?
To shift left means to move a task to earlier stages in a process. Often, this also shifts responsibility from an expert in that field to the end-user or requester of a process.
Let’s look at a practical example of shifting left infrastructure consumption in a ‘before’ and ‘after’.
The Old Way
The Old Way consisted of a process, requiring input and work from two disciplines sequentially, with responsibilities for both split across teams. The simplified version of the process went like this: the Development team develops software, and hands it over to the Operations team for deployment and production management like monitoring. The process flows from the developers to operations, and needs a handover from one group of experts to another to complete the process.
The New Way
In the new way, the different disciplines work together more closely, often in a single, multidisciplinary team. While the process still requires input and work from both disciplines, the sequential dependency is removed. Instead, everybody works to make sure that their expertise is available on-demand and self-service to whoever is earlier than them in the process, moving the tasks they performance in The Old Way to earlier stages.
This principle of shift-left means a couple of things:
- Remove the human dependency of expertise
- Make that expertise and knowledge available on-demand and in a self-service manner
- Automating much of the consumption process into a (set of) service(s).
For example; in the Old Way of infrastructure provisioning, system architects and engineers needed months to purchase and configure infrastructure after a developer requested resource to run a new app on. In the New Way These days, public cloud services make infrastructure consumption on-demand (automated) and self-service (not requiring any human intervention). Consequently, the responsibility to choose the right infrastructure services, as well as proper configuration, monitoring and maintenance now lies with the group consuming the resources: the developers.
Downsides of shifting left
A major downside of shifting left is transferring knowledge and expertise. If developers can now consume infrastructure, how do we make sure they actually know how to make the right choices? And complete the right tasks to not forget about sizing, security, resilience and high availability?
In part, shifting left is hard, because creating services that capture that (sometimes tribal) knowledge is hard if the team is not experienced in creating services. Teams are often created around a technical skill or expertise, not around ability to create and maintain services.
But with the advantages in agility, moving tasks to earlier in the process and making them more on-demand and self-service make sense, especially if the tasks being shifted are (becoming) commodity, like infrastructure and adjacent components, such as databases, message queues, object storage, virtual machines and containers.
Shifting left Security and Testing
Other fields, especially those not yet commoditized, are harder to shift left.
The temptation to create consulting-based services (which are not on-demand nor self-service) to circumvent problems with the complexity and variance that come with fields that are not yet commoditized is definitely there. But these half-baked services do not shift-left and require existing workflows and processes to be changed to fit the consulting services, instead of the other way around: moulding the service to fit existing processes and workflows.
Paradoxically, it’s often seasoned consultants that are able to resist that temptation and create proper self-service, on-demand services to help organizations shift left security and testing.
Veracode is one such example. Veracode offers software services to move security work to earlier in the development process, preventing security bugs and issues going to production and preventing the re-work associated with fixing those issues.
Veracode Greenlight
Greenlight is all about DevSecOps, or shifting code security scanning left. Instead of scanning code for vulnerabilities after-the-fact, Greenlight scans code as the developer writes, giving immediate feedback to the developer without changing or disturbing their process as they work. And, more importantly, helps developers learn from their mistakes by explaining issues and recommending ways to fix them without requiring a consultant or training.
Remember the challenge of transferring expertise and knowledge while shifting left? By integrating best practices and solutions for security issues, Greenlight codifies the consultant’s knowledge and integrates it directly with the developer’s IDE. This way, a developer not only sees what improvements they can make in their code, but also understand why. Elevating the developer’s knowledge is an important factor in behavioral changes to prevent similar mistakes in the future.
Read more about Veracode Greenlight: DevSecOps with Veracode: Getting the Greenlight on Security
The benefits of this short feedback cycle are obvious: surfacing vulnerabilities in code before any time is wasted on mitigating the security issues in production and other re-work.
Similarly, the Veracode DevOps Scanner runs as part of the CI/CD pipeline and does ‘security integration testing’. It executes a full static code analysis for the entire application, not just the changes in the file being committed and pushed to production. By running this analysis and returning results as soon as possible, DevOps Scanner creates a positive feedback loop for developers, letting them know what parts of their code needs improvements to pass security policies (like the OWASP Top-10) and regulatory requirements.
Shifting left makes sense
Summarizing, shifting left makes sense, even for areas that are not yet commodity. Any effort to make processes run more smoothly, with less sequential dependencies on other teams, more self-service and on-demand capabilities helps simplify how people work and collaborate.
Security is no exception, and Veracode Greenlight is a prime example of how to shift left security to earlier in the process.
