The mass adoption of “infrastructure as code” not only revamps deployment velocity but also introduces new kinds of risks as applications are deployed across multiple environments.

To mitigate these risks, a new approach of scanning whether the open-source package is vulnerable or not was created. Checkov, a static analysis tool for infrastructure as code, enables IaC inspection in complex distributed environments.

Checkov goes beyond runtime scanning of cloud infrastructure and cloud-native clusters to include fixing any security misconfigurations at the code level, according to Barak Schoster (pictured), senior director and chief architect at Palo Alto Networks Inc., which acquired Checkov creator Bridgecrew in March 2021.

“We started doing infrastructure as code with Terraform, Kubernetes manifest, CloudFormation, serverless, and the list goes on, and we created an open-source product around it named Checkov, which has an amazing community of hundreds of contributors,” Schoster said. “We will scan your infrastructure code, your application packages that you’re using from package managers like NPM or PyPI, and we scan those open-source dependencies. Let’s say that you have a vulnerable open-source package, and it was fixed in a later version. We will bump the version for you to make your code secure.”

Schoster spoke with theCUBE industry analyst John Furrier during a recent digital CUBE Conversation. They discussed why scanning infrastructure as code is fundamental when mitigating risks in complex distributed environments.

Scrutinizing the entire software bill of materials

A new approach of analyzing the whole software bill of materials, known as SBOM, has been necessitated to comprehend the different risks, making infrastructure as code more efficient, according to Schoster.

“We empower the engineer with tools to analyze the entire dependency tree of your software bill of materials,” Schoster said. “The thing that we will always focus on is making a fix accessible to you. Let’s say that you’re using a misconfigured backup; we have a bot that will fix the code for you.”

By inspecting configurations in CI/CD and runtime, Schoster believes vulnerabilities are addressed beforehand.

“You should vet all of the open-source Terraform modules that you’re using, because you might have a leakage,” he pointed out. “We rely a lot on cloud infrastructure, and in the past year, cloud providers have disclosed that they were vulnerable to Log4Shell attack. So we understand today that when we talk about cloud security, it’s not only about the infrastructure itself, but also is the infrastructure’s open-source package vulnerable?”

By making security teams enablers instead of gatekeepers that block releases, best practices allow for a simplified yet secure process surrounding infrastructure as code.

“We tried to and succeeded to democratize the creation of policy as code, the ability to inspect your infrastructure as code and tell you, ‘Hey, this is the best practice you should consider using before applying a misconfigured S3 bucket into production or before applying a misconfigured Kubernetes cluster into your production or dev environment,” Schoster said.

Here’s the complete video interview, one of many CUBE Conversations from SiliconANGLE and theCUBE:

Photo: SiliconANGLE