We’re living in the age of accelerated consumption and delivery. You can get a seemingly infinite selection of products delivered to your door within two days, for free, from thousands of miles away. You can access an endless variety of services online within mere seconds: Movies, music, games, education and even health care. These modern marvels are afforded to us by relatively recent advances in software development, delivery and operations.
Among those advances are the adoption of DevOps practices, continuous integration and continuous deployment (CI/CD) pipelines, and automating everything from infrastructure provisioning to testing and quality assurance. These advances enable developers to deliver software faster and think about security earlier in design and development to ship safer software.
What is Shift Left and Why Does it Matter?
“Shift left” is a philosophy for addressing the pitfalls of traditional waterfall-style development. In waterfall, a number of IT teams work over the course of many weeks or months, culminating in a big and beautiful software release. Of course, people make mistakes, forget things, and maybe don’t communicate well with each other. When it turns out that application elements don’t interoperate well, the teams frantically attempt to fix what’s possible and jettison what isn’t, with a very serious deadline staring them in the face. Products inevitably ship late, still somewhat broken, and with security bolted on as an afterthought.
To shift left means to introduce security process and tooling earlier into the design and development phases. Security should be just as critical as functionality and quality. It’s a great idea because discovering a critical, build-failing vulnerability in a critical dependency after you’ve built dozens of functionalities on top of it hurts a lot more than if it’s found before you build anything at all. Maybe fixing the problem is as simple as using a newer version of a dependency, but now you have to make sure everything you’ve customized still works as intended.
There are a number of forms of application security testing (AST) that aim to detect code-level issues early in the systems development life cycle (SDLC). Two common types of AST when shifting left are software composition analysis (SCA) and static application security testing (SAST). Put simply: SAST tests the custom code your developers write; SCA tests dependencies you include in code.
Assessing the security of modern applications requires both testing types. If you believe shift left means not only finding problems but also fixing them, then developer-friendly tooling is necessary. Exactly what that means can be subjective depending on developer workflows in the organization, but at the very least, developers need self-service, seamless integration into their existing CI/CD toolchains and actionable results. Because most developers aren’t security experts, security findings must prioritize the riskiest problems, point to the source of the issue and provide contextualized fixes, rather than making the developer hunt for them on their own.
Augmenting AST With Runtime Intelligence
One challenge with doing a lot of early testing—especially security testing—is that the more you test, the more findings you discover. Unfortunately, some of the results will be false positives and others may be true positives that pose a relatively low risk. Development teams with a high degree of security expertise must sift through and vet findings to prioritize flaws that are severe and actionable, but such practitioners are in short supply and this type of work is tedious.
Addressing the pitfalls of security testing isn’t simple, and it involves gathering as much contextual information as possible to begin to reason about the risk associated with each finding, usually expressed by what exploitable code is actually exercised.
Reasoning about vulnerability risk is not easy. We try to rank the criticality of issues to decide on an action. We can split the problem into two parts:
The context of the vulnerability itself includes metrics of severity, like the CVSS score, and threat intelligence, like whether exploits are publicly available or attacks are prevalent in the wild. This information is readily available from scanning tools and third-party sources like NVD, MITRE and CISA.
The afflicted asset’s environmental context, however, is specific to your application and your infrastructure. Only your organization can really fill this part in. For example, is the impacted application protected by mitigating security controls? Is it exposed to the internet? Does the vulnerable component even get used at all? This is difficult or impossible to know until the application is running in its intended production environment.
Shift left is a way forward for modern cybersecurity, but the approach can be vastly enriched by pulling in runtime insights. This helps to prioritize what to fix first, removes friction, saves cycles of numerous IT teams and reduces your organization’s vulnerability risk.
What Happens After Release?
The whole point of shift left is to release secure software faster, but what happens next? Your flawless, beautiful code is delighting your customers with its stunning feature set and impressive performance. Then, on some idle Friday afternoon, right before what should have been a long holiday weekend, you get hit with a horrendous zero-day that you could never have predicted even if you tried.
When that happens, you need to respond by quickly identifying all of the affected workloads running in your environment and prioritizing them for remediation. You may need to take those workloads offline to patch immediately, limit network access to them, or otherwise mitigate the problem if a patch is either unavailable or taking too long to deploy. The point is that in real life, shift left is only one part of a successful security program, and the protective, detective, and remediation activities for your production environments on the right are also critically important to your organization’s safety and success.
Conclusion
Shift left alone was never going to solve all security problems, but it does create foundations for reliable, fast and secure software delivery pipelines. Security and development teams alike often suffer from a deluge of noise and few useful signals. What they really need are consistent and prescriptive ways to make sound decisions about risk. Gathering context from multiple sources through multiple layers of the stack, including runtime signals, substantially improves the quality of the information that DevSecOps teams receive from their tools and must act on.
Effi Goldstein, director of products at Snyk, co-authored this article. Check out Sysdig and Snyk’s 2022 Container Security Trends: Expert Panel Livestream for more information.