The accelerated CI/CD practices that cloud environments have enabled has led many developer teams to create automated script tools that replace the manual configuration and provisioning of apps by communicating directly with the cloud provider’s API. This approach to software production is known as Infrastructure-as-Code (IaC), and essentially forms the building blocks upon which the rapid deployment and update of apps and web services via the cloud is based. In other words, developers don’t have to keep building the same launch pad whenever they want to quickly tweak an app’s functionality, but can instead use a pre-existing IaC template.
IaC speeds up deployment, eliminates one-off non-standard configurations, and builds consistency and repeatability into the software provisioning process. But while this type of automation is a major boon for developers, it’s a potential source of vulnerability if there’s a flaw in the template itself. This is the flipside of agility: when simple configuration changes can leave sensitive data and private servers exposed in the cloud, the security implications of this level of automation are profound.
As such, the next step in shifting left in software development is to push security compliance to the very start of the process by ensuring that the IaC templates, the initial foundation upon which code is written, are free from known vulnerabilities. Up until now, the nature of the templates has proven to be problematic for traditional security teams, and may explain why they have continued to favour a reactive posture, because the software platforms on which the templates are written – CloudFormation, Terraform etc – are not familiar to them. However, a new generation of automated scanning tools enables pre-deployment static analysis of IaC templates, treating them just like any other piece of code and performing the relevant security and compliance tests.
Just as tools have been developed specifically for the cloud to automate and speed up all stages of the software process, so too do security solutions now exist that support the non-stop CI/CD paradigm from beginning to end. But tools won’t change the post-deployment fix culture on their own – that will only happen when developer and security teams work closer together rather than in opposition to each other. Security must accept that it’s both possible and desirable to enforce corporate policies before run-time, while developers must allow security to be involved from the ground up.
The closer we can shift “hard left” and push security consciousness to the very start of the process, the nearer we will be to establishing a threat protection model that’s based on proactive prevention rather than reactive remediation.
