October 5 2021 | 2 min read
Executive | October 5 2021 | 2 min read
What’s left to say about shift-left security? Making informed decisions earlier in the development process has clear benefits, enabling organizations to reduce re-work, improve security, and ultimately deliver faster. It also helps to protect brand integrity by addressing security issues before they reach production. This moves the Shift Left approach beyond the realm of Security into a business enabler.
But there has been an element missing from the discussion: you can “extend right” by incorporating Infra as Code into your process in order to make smarter, more contextual decisions earlier in the development process. Infra as code has transformed the way DevOps teams manage changes to infrastructure. By processing these changes as code, you can increase automation and agility – and improve security at the same time.
When making risk-based decisions, context is everything. The more context we have, the more informed decisions we can make. While the focus of much of the DevSecOps movement has been to shift decision-making earlier in the SDLC, there hasn’t been enough discussion about the types of information that can be shifted left.
A product is not just a collection of code. The risk of a cloud/SaaS product also includes:
Even in the case of non-SaaS applications, there is always a distribution method, with its own unique characteristics and risks (how many of you actually do MD5 checksum verification when you download software from the Internet?) There is also an environment in which the product is run, from Windows servers to virtual machines to containers. No matter what the product is, its risk profile needs to include information from design to code to production (these days, usually cloud). But let’s focus on SaaS applications:
Infrastructure as code (IaC) is what makes shift-left security for cloud configurations possible. IaC also allows us to make better decisions about the infrastructure before they become production settings! You can evaluate infrastructure configurations at the commit to develop branch or at pull request and analyze the risk of the change in the context of the entire application.
IaC is also blurring the lines between infrastructure and application, enforcing the need for a more holistic approach to product security.
One change we have seen that illustrates the shift to thinking about security more holistically is the rise of the product security title. This role encompasses not only applications themselves but recognizes that applications do not exist in a vacuum. There are many elements that are part of a product’s security and practitioners need to think broadly about the risk.
It is crucial that we help product security practitioners by giving them the information they need to make decisions on product risk. This means having visibility across all types of components in your product and using that visibility to take a contextual, risk-based approach to security.