TL;DR overview
- Infrastructure as Code (IaC) quality matters as much as application code quality: misconfigurations in Terraform, CloudFormation, or Kubernetes manifests can expose cloud environments to security breaches or outages.
- Common IaC quality issues include overly permissive IAM roles, unencrypted storage buckets, missing network segmentation, and hardcoded secrets—all of which Sonar's IaC scanning can detect.
- Integrating IaC scanning into CI/CD pipelines applies the same shift-left approach to infrastructure that static analysis applies to application code, catching issues before resources are provisioned.
- As cloud-native development grows, treating IaC files with the same quality and security rigor as application code is essential for maintaining a secure and reliable infrastructure posture.
New tech...same challenges
The great thing about tech is that useful innovations are always arriving. While Infrastructure as Code (IaC) isn’t brand new, it still feels shiny and its popularity is really taking off. For newcomers to the concept, here’s a quick summary:
IaC is the process of managing and provisioning infrastructure through machine-readable definition files, rather than physical hardware configurations or GUI-based config tools. The definitions may be maintained in a version control system such as Git. The approach used may be declarative (WHAT) or imperative (HOW). The declarative approach defines the desired state and the system executes what needs to happen to achieve that desired state. The Imperative approach defines specific commands that need to be executed in the appropriate order to achieve the desired state. The recent focus in IaC tools is on the declarative side (e.g., AWS CDK, Terraform).
One of the coolest aspects of IaC is that it brings a whole new dimension to what developers can achieve. It’s a powerful technology that offers more flexibility and independence to developers and cloud platform engineers.
"Technology alone is not enough." - Steve Jobs
And with great power, comes great responsibility. Just like source code, IaC can contain bad actors in the form of bugs and vulnerabilities. These can wreak havoc on your infrastructure and your organization’s reputation. And if you believe that the cloud provider is handling security for you - think again!
Who's responsible for security?
A concept called the Shared Responsibility Model comes into play here. Security is a shared responsibility between the cloud provider - such as Amazon Web Services (AWS), Microsoft Azure or Google Cloud Platform (GCP) - and the customer. In this 'shared model', the cloud provider is responsible for 'security OF the cloud,'. This means the cloud providers are responsible for securing the traditional compute services such as physical hosts, networking and virtualization.
Customers are responsible for 'security IN the cloud' and that means platform and resource configuration since that’s under your direct control. When you spin up cloud infrastructures, you're directly controlling the operating environment - this is true whether your instances are server-based or serverless.
Not all cloud developers are aware of this and/or comprehend the significance. One small mistake can expose a lot! The good news is that IaC is just code and at SonarSource, we know a thing or two about helping folks write Code Quality! 🤠 . This includes the popular languages and tools you’re using to configure and orchestrate your cloud infrastructures.
Secure your IaC with Sonar
We’ve added rules to the Sonar solution to detect code smells, bugs and vulnerabilities in your IaC projects. If you’re already using IaC in production or just exploring what it can bring, you’re probably developing cloud-native apps and this is where Sonar really adds value. With Sonar, you can find and fix issues in your IaC AND Sonar can scan the source code in your cloud-native apps as well. Whether it’s JavaScript running on the backend or AWS Lambda functions as part of your microservice, Sonar detects quality and security issues and helps you fix them.
Below are a couple of issue examples caught by our IaC specific rules:
Scope permission vulnerability in Azure with a secondary location
Authentication vulnerability in AWS
We know that folks don’t always deploy with a single cloud provider so we have rule coverage for AWS, Azure and Google platforms. We’re just getting started in the IaC/Cloud-Native space and we’re already bringing lots of value with the dozens of rules we’ve already added.
Getting started is easy
You can view our rules for CloudFormation and Terraform in the product. Or better yet, try them out yourself in SonarQube Server or SonarQube Cloud. Please visit our Community to give us feedback and to grab the latest product news.
Thanks for reading and happy, clean IaC coding!
Pick a blog topic to discover more:
- GitHub Code Scanning integration speeds vulnerability review
- 10 unknown security pitfalls for Python
- SonarQube for IDE Quick Fix feature modernizes coding in your IDE