Software supply chains are at the heart of cloud-native deployments and are increasingly becoming targets for attacks. One weakness, whether isolated or connected with others, can lead to exposed secrets, injected malicious code, leaked sensitive data, and more. Implementing a shift left security will help remove these vulnerabilities from the software supply chain to ensure your cloud resource configurations are protected from avoidable vulnerable attacks.
A vital component of a software supply chain security implementation is the security of your Infrastructure-as-Code (IaC). Bridgecrew by Palo Alto is a core element for their Prisma Cloud Code Security feature and is one of several tools that will help automate your IaC security.
We chose Bridgecrew because of its rich features, support for several platforms, and ease of use. This blog details some of these features and how easily they can be implemented.
What is Infrastructure-as-Code (IaC)?
Infrastructure-as-Code (IaC) is the process of automating the provisioning, configuring and management of your on-premise or cloud-based IT resources by describing your desired state using scripts and templates. Rather than implementing these processes manually, which will make your processes and environments inconsistent and prone to avoidable human error while also being difficult to scale.
Several IaC frameworks are available, and they communicate with the cloud provider or on-premise systems through APIs. Some of these frameworks are environment-agnostic and can be used almost anywhere, for example, HashiCorp’s Terraform, while others only work in specific environments. For example, AWS CloudFormation only works in AWS.
The Benefits of IaC
The several benefits of IaC have made it an essential component of provisioning and administering IT resources. Some of these benefits are:
- Easy to scale — It gives you the ability to create identical or similar workloads for your deployment environments (Dev, Test, Prod) or different projects.
- Easier and quicker to perform disaster recovery by quickly creating a new and identical production environment.
- Storing IaC templates and scripts in a Version Control System (VCS) like git gives you a single source of truth and a history of your infrastructure changes.
- Less experienced engineers can make use of IaC scripts and templates (developed by more experienced team members) to deploy complex workloads without fully understanding the setup. Caution — you will need to have strict permission in place to control what is allowed.
- IaC scripts and templates are idempotent, meaning they will produce the same result every time.
Risk of Security Misconfiguration with IaC
Despite the many benefits IaC offers, it poses a significant security risk. You could end up with security misconfigurations in your IaC templates and scripts due to either human error or lack of experience, leaving your workloads vulnerable to attack. Attacks caused by such vulnerabilities could be much more devastating than if the misconfigured workloads were provisioned and managed manually. This is because you would most likely have used the same misconfigured IaC template and scripts to scale your workloads across different deployment environments and projects.
Gartner predicts that, by 2025, 99% of all cloud breaches will be traced back to preventable misconfigurations or mistakes by end users and that 45% of companies will have experienced a software supply chain attack. Scary, but likely accurate.
What is IaC Security?
It is the implementation of software supply chain security tools and processes in your workflow to remediate any security-related misconfigured templates and scripts and mitigate the risks mentioned in the previous section. The tools analyse the IaC templates and scripts against a set of pre-defined security policies to identify any security-related misconfiguration and offer a fix before they can be applied (shift left). And where the resource has already been provisioned, the tool will recommend updating the configuration.
On the other hand, “Code Peer Reviews” is one process you can implement to help mitigate security risks.
What is Bridgecrew?
Bridgecrew is an IaC security tool that enables teams to automatically identify and fix misconfigurations during build-time and runtime against a set of Bridgecrew policies which are constantly being updated. It ships with over 1800 built-in policies that cover security and compliance best practices for AWS, Azure, GCP, Dockerfile, Kubernetes, Helm, etc. In addition, teams can create Python or YAML-based custom policies for particular use cases. On the other hand, teams can suppress the built-in policies that are not applicable.
To enforce these policies against your IaC templates and scripts during build-time, Bridgecrew provides the option for teams to integrate the tool with their Version Control Systems (VCS) and CI/CD pipelines. For runtime protection, Bridgecrew supports the integration with all the major cloud providers to enable teams to identify and fix misconfigured resources provisioned on those environments. However, to avoid drifts in your resource configuration, Bridgecrew does not recommend this approach, even though it also provides the option to fix such drifts. This is because your code repository should always be your single source of truth.
Bridgecrew also supports integrating the tool with your Kubernetes clusters to help protect your Kubernetes workloads during runtime.
Click here for steps on how to Sign Up for Bridgecrew Cloud.
Integrating Bridgecrew with your Version Control Systems
Bridgecrew supports integrating with VCS hosted on platforms like GitHub, GitLab, Azure Repos and Bitbucket to enable teams to use the tool to address security misconfiguration in their IaC templates and scripts during build-time.
After you have successfully integrated the tool with your code repositories, it will scan your IaC files and highlight security-related configuration issues as errors graded as LOW, MEDIUM, HIGH or CRITICAL depending on their severity with the option to either fix or suppress the error. Click here for steps on how to integrate Bridgecrew with your VCS.
To review the misconfigurations identified by Bridgecrew in your IaC files, click the dashboard and select the repository of interest as shown below.
That will then take you to the incident page from where it will display the recommended changes to your misconfiguration and with the option to either fix or suppress the errors. See an example below.
To fix your misconfigurations, click the FIX button and submit your changes by clicking the SUBMIT button at the top right-hand corner of your screen (see below).
This will generate a Pull Request (PR) in your Version Control System (VCS), which you should review and approve to merge your changes to your main (trunk) branch. If your VCS is integrated with a CI/CD pipeline, this will trigger a deployment.
And there are instances where Bridgecrew will not be able to make recommendations to your ‘misconfigurations’ simply because it does not have visibility of your use case. For example, if you create a wide-open ingress firewall rule (as shown below), it will highlight it as a misconfiguration to draw the developer’s attention to the ‘error’. It will then be up to the developer to either suppress the ‘error’ or address the ‘misconfiguration’ as per their use case.
Integrating Bridgecrew with your CI/CD Pipelines
This is the preferred way to integrate Bridgecrew with your workflow. It automates your infrastructure security by scanning your IaC files for misconfiguration when your automated build pipeline runs, which helps enforce your shift left security (DevSecOps) implementation.
You can implement this integration either by using Bridgecrew’s CI/CD providers, which use a wizard to help you construct the steps and command to execute or by reviewing Bridgecrew’s documentation to help identify those steps and commands.
Bridgecrew currently has providers for the following CI/CD systems:
- Terraform Cloud (Sentinel)
- Terraform Cloud (Run Tasks)
- GitHub Actions
- AWS CodeBuild
Integrating Bridgecrew with an Azure Pipeline
The reference architecture diagram below (for clarity, it uses a self-hosted build agent with Bridgecrew CLI utility already installed) shows an example of how you can integrate Bridgecrew with your CI/CD pipeline.
The components of the solution are:
Checkov by Bridgecrew — It is an open-source static code analysis tool for IaC that ships with over 1000 built-in policies to help developers implement security and compliance best practices for AWS, Azure, GCP, Dockerfile Kubernetes, etc. You can install it on your development computer or integrate it with your IDE to scan your IaC files. In this reference architecture, we are integrating it with the developers’ IDE (Visual Studio Code). The idea here is to ensure developers have the opportunity to implement these security and compliances best practices during the development phase of their IaC before pushing the changes for approval and subsequently merging them to the remote repository’s main branch for deployment. Integrating the tool with your IDE will scan your files and highlight any misconfiguration with links to the policy it is using for reference. For example, in the Dockerfile below it is recommending not to use the latest tag for your base image.
Azure Repo — It is the version control system used for this solution to store and version the IaC files and scripts and also track configuration changes to the resources managed by the code.
The Azure Pipelines — It automates building the IaC templates and the deployment of the resources.
Terraform — It is the IaC framework used in this solution.
Below are the workflow steps:
- A developer will push their changes from a feature branch and raise a PR to have their changes approved and merged to the main branch after hopefully addressing any misconfiguration in their implementation raised by Checkov.
- This action will trigger the PR validation pipeline, which will validate the changes and then scan for any misconfiguration using Bridgecrew. The build will fail if any misconfiguration is found. The developer will then be required to fix the errors before their changes can be approved a subsequently merged into the main branch for deployment. On the other hand, the build will succeed if Bridgecrew does not find any misconfiguration in the changes. The changes can then be approved and merged into the main branch, ready for deployment. It is recommended to have a manual approver implementation who will review and approve the changes before deploying them to your environment.
Note: Bridgecrew has two flags, soft-fail and hard-fail, which determine whether to pass or fail a build if misconfigurations are found, and soft-fail is the default flag. So, you will need to use the hard-fail flag for your implementation if you want your IaC builds to fail if misconfigurations are found.
Integrating Bridgecrew with your Runtime Environments
Bridgecrew Cloud integrates with the three major cloud providers (AWS, Azure and GCP) and Kubernetes.
Integrating Bridgecrew with your Cloud Providers
It is the least recommended way to integrate Bridgecrew with your workflow, especially where the resources are managed using IaC templates and scripts, and it is because, as mentioned in the what is Bridgecrew? section, it will cause drifts in your resource configuration. Although the tool provides a feature to address drifts in your resource configuration, your source code repository should ideally be your single source of truth.
When you integrate Bridgecrew with your cloud runtime environment, the tool will scan your resources for misconfiguration and output the results on the incident page, from where you will have the option to either fix or suppress the error, as seen below.
You may notice that Bridgecrew does not provide the fix option for some resource misconfiguration. In such cases, it will still provide you with a recommendation of how to fix it.
Click here to learn more about how you can integrate the tool with your cloud provider.
Integration Bridgecrew with your Kubernetes Clusters
There are two ways you can integrate Bridgecrew with your Kubernetes cluster workflow:
- Deploy Bridgecrew CLI with CronJob to scan your Kubernetes resources periodically for misconfiguration. Like integrating with your cloud provider, the tool will output the errors to the incident page, from where you can either fix or suppress them.
- Deploy a Kubernetes admission controller where Bridgecrew scans your Kubernetes manifest files for misconfiguration and the admission controller blocks resources that fail the check from being deployed to the cluster. Below is an example of the error the admission controller generates when you attempt to deploy a resource that violates a security policy to the cluster.
Refer to the documentation here for more information on how to Bridgecrew with your Kubernetes cluster workflow.
We hope this blog has demonstrated the importance of IaC security in your software supply chain and how easily you can use tools like Bridgecrew to automate your IaC security.
So, if you are looking for a tool to implement your IaC security, we will encourage you to explore Bridgecrew, which offers a 14-day trial period.
GFT regularly implements Bridgecrew or its open-source sibling, Checkov, to secure IaC software supply chains for our financial services customers. Bridgecrew is the core component of the Code Security feature of Palo Alto’s Prisma Cloud; a suite of security tools categorised by Gartner as a Cloud Native Security Protection Platform (CNAPP). Prisma Cloud includes Cloud Security Posture Management, Cloud Workload Protect (Twistlock & PureSec acquisitions), Cloud Infrastructure Entitlement Management and Cloud Network Security in addition to Code Security.
If you’d like to know more about any of these products please contact GFT for more information. We are a Palo Alto partner that specialises in all 5 of the Prisma Cloud security solutions.