A New Security Mandate for Scanning Infrastructure as Code
Three Reasons Why Scanning Infrastructure As Code Is Necessary
“It is the obvious which is so difficult to see most of the time.” - Isaac Asimov
TL;DR Last week, we released iacbot, a free solution to help developers test their Infrastructure as Code (IaC) – Terraform, CloudFormation, Kubernetes – to give them an easy way to fix misconfigurations. In this post, I’ll describe the three reasons scanning IaC should be a security mandate, and how you can get it done.
IaC Needs to Be on Our List of Things to Scan
Scan the servers, application code, container images – anything and everything. It’s what security teams do. We take pride in knowing what we have and what state it’s in…thus we scan ad nauseam.
So, why aren’t we religiously scanning our infrastructure as code (IaC, i.e. Terraform, CloudFormation etc)? Shouldn’t we scan what defines cloud services and hence our largest attack surface? Yes! Particularly since scanning IaC is the most efficient and cost effective way to eliminate cloud configuration vulnerabilities before they’re deployed. If there is an easy way to scan and fix IaC in development, it’s a no-brainer to do it because it has a high impact in reducing risk.
But here is the challenge. Deployments are occurring continuously. Take Spotify for example, they are releasing up to 20,000 times a day! For companies like that the question is less “if” you should scan – but how? How do you execute scans across:
- Hundreds of teams,
- Thousands of developers,
- Countless repos,
- Disparate pipelines with a
- Globally distributed footprint?
In this post, I will address both why scanning IaC should be a security mandate, and how you can get it done – without a heavyweight (and expensive) enterprise solution.
The Mandate to Scan IaC
When a core security capability is not being performed – like scanning cloud infrastructure in development – it’s often rooted in motivation. Or said more directly, it’s a function of risk awareness.
Mandates – typically driven by analysts, vendors and practitioners – usually drive that awareness, helping security leaders determine which risks matter, so they can prioritize what technologies and actions will help mitigate them. With the rapid pace of technology innovation for modern software development, we can’t afford to wait for an official mandate.
Here are three motivating reasons that you should view scanning IaC as a security mandate now, and take action.
1. IaC misconfigurations are highly likely to happen – so it’s important to catch and fix them
With IaC, developers are authoring and deploying cloud services alongside their applications. Until recently this was the exclusive domain of operations (DevOps, SRE). Now we have a 10x increase in the number of people deploying cloud infrastructure. That’s risky!
Developers are software experts first and infrastructure journey persons second. They’re under pressure to deploy their applications. In their haste (and occasional inexperience) they will take short cuts, like cutting and pasting existing vulnerable IaC, potentially duplicating errors, and exposing data. So you not only have more people creating potential exposures, now they can do it with speed.
Are you really comfortable leaving the configuration of IAM, Databases, and Buckets unchecked before being exposed?
2. Scanning post deployment helps, but isn’t solving the problem.
Some may argue that scanning deployed cloud services is good enough; their cloud security posture management (CSPM) solution is good enough to handle misconfigurations.
The problem with that approach is that whatever your CSPM can see, the bad guys may see too. If you find an inadvertently exposed S3 bucket, what’s to say the enemy didn’t already steal your treasure? The fact is you are risking breach by only taking a post-deployment approach.
Remember, most all cloud breaches have one thing in common – the exposure that led to breach was exploited after it was deployed.
Finding issues post deployment should be the exception. Finding and fixing issues pre-deployment should be the norm.
By bringing pre-deployment scanning into the mix you will round out your cloud security program. While your existing CSPM has value, without IaC scanning, it is woefully insufficient.
3. Scanning IaC in development is more cost efficient – saving time and work for security and development teams.
IaC scanning is extremely efficient. It runs fast with a relatively low false positive rate compared to application scanning. If you combine that efficiency with the fact that it eliminates a lot of remediation work – it ends up reducing costs.
Post deployment remediation invariably turns into mini-projects involving the security team. Instead, when you can scan IaC and make configuration changes early in development, they take minutes to fix.
We want to avoid growing backlogs of remediation work. It slows development teams, and the business, down.
It is for these reasons that IaC scanning should become a mandate.
Now you know it’s necessary, how do you get it done?
The only way to scale is by moving security teams out of the scanning game – shifting security responsibility (in this case scanning) left – to developers. Security teams have a 1:10 ratio to DevOps and a 1:100 ratio to development (or based on my experience, much higher – in favor of development).
Security is still accountable for security outcomes. Per the above, it is their responsibility to take actions to significantly reduce security risk to the organization. Security must enable development with the right solutions – ones that work for developers, not against them.
An easy, zero-cost way to help you meet this mandate: iacbot
Last week, we introduced iacbot - a free IaC scanning solution for developers. Security teams should be excited to give it to developers to use because it helps meet our mandate of adopting IaC scanning to reduce security risk – without impacting developer velocity.
While there are excellent open source tools available for IaC scanning, they can be difficult to use, or to use consistently across teams. iacbot runs in Github, automatically performing IaC scans, sending actionable information to developers so they can fix any issues without involving security teams.
With this GitOps approach, any developer provisioning IaC - Terraform, CloudFormation, or Kubernetes – simply connects to iacbot, iacbot analyzes the code in their repo, and the developer gets alerts about misconfigurations directly in their pull requests so they can fix them. It scans across code repositories regularly, and it scans whenever there is a change.
Whether you have a small team of developers, or thousands, this is a simple tool for them to use. It requires:
- Zero configuration – no typing
- Zero expertise – no need to understand how to use open source tools, or to learn about security
- Zero cost – iacbot is free!
We would love for you to try it. Watch our getting started video for security practitioners to see how easy it is to use, and share iacbot with developers in your organization to meet this important security mandate of scanning your IaC.
Drop me a line and let me know what you think - firstname.lastname@example.org. We’d love to hear from you.