When Log4Shell was first reported, companies scrambled to figure out if and how they were affected by the vulnerability. Despite their best efforts, few companies were able to fully grasp the extent of their exposure. Finding the vulnerable package inside the applications their teams built was key, but companies also needed to identify which external parties or vendors were affected by the vulnerability.
But as many companies found out during the immediate aftermath of the Log4Shell discovery, getting the information they needed to properly understand and address their risk exposure was far more difficult than expected.
And while Log4Shell generated a lot of attention in the media, headline-making vulnerabilities aren’t the only source of code security risk. Cloud misconfigurations are still pervasive and contribute to both vendor and customer risk exposure. All it takes is one open S3 bucket for personal information and proprietary customer data to be exfiltrated and abused.
Leveraging SBOMs to understand risk
These sources of risk, coupled with the increase in software supply chain attacks, highlight the real need for more tooling that provides comprehensive reporting and inventory management of open-source software usage.
Many industries, particularly finance and government, are starting to acknowledge this need. In 2021, the White House issued an executive order to improve national cybersecurity and dedicated an entire section of the document to outline steps to enhance software supply chain security. Included in that section was a new requirement that vendors provide a software bill of materials (SBOM).
An SBOM is a list of components, along with relevant metadata such as versions and licenses, that make up software. These lists are typically in a standardized, shareable format. By leveraging SBOMs, companies can easily inventory and understand risks in packages and resources in both internally-sourced and externally-sourced software.
A recent study by the Linux Foundation found real, tangible benefits to using SBOMs:
- 51% of organizations surveyed find that SBOMs make it easier for developers to understand dependencies across application components.
- 49% of organizations said SBOMs make vulnerability monitoring easier.
- 44% of organizations find SBOMs make license compliance easier to manage.
We’re excited to announce that Bridgecrew now makes it easier to generate SBOMs that document all the open-source packages and infrastructure resources that comprise cloud-native applications.
Extending SBOMs for full-stack visibility
SBOMs traditionally include open-source packages and their vulnerabilities, such as Log4J and CVE-2021-44228. And because traditional SBOMs don’t include cloud infrastructure resources, organizations are blind to their cloud infrastructure risks. This is a major challenge because the lowest hanging fruit for a bad actor is oftentimes an unencrypted storage bucket or an overly-permissive firewall rule—which, according to Unit 42 by Palo Alto Networks, are all too common. Traditional SBOMs also don’t give visibility into an organization’s exposure to risk from vulnerabilities in a cloud provider’s service.
With that in mind, we’ve added the ability to include resources found in infrastructure as code (IaC) to SBOM exports. When you use the platform to generate SBOMs, the SBOM includes all packages found in application code and container images, along with resources found in IaC templates like Terraform and CloudFormation. Additionally, the SBOM provides important risk information such as open-source licenses, vulnerabilities, and misconfigurations for those resources so that organizations can understand the legal and security exposure of the software.
Watch the video or keep reading to learn how to generate an SBOM with Checkov and Bridgecrew.
Generating an SBOM
Bridgecrew offers two ways to generate an SBOM. You can either use the open-source tool Checkov or you can leverage the platform to download reports. You can also export SBOM reports by leveraging Checkov’s output format either locally or in CI/CD pipelines. This makes it simple to operationalize SBOM creation and versioning by generating an SBOM and storing it as an artifact of every CI/CD run.
From the platform, Bridgecrew offers the ability to choose the format and materials you want to include in your export.
Understanding your risk surface
Generating an SBOM for cloud-native applications is easier than ever with Bridgecrew. Armed with these tools, you can get visibility into your risk exposure and can provide your customers with that same information. And while the adoption and operationalization of SBOMs are still in their early days, we’re excited to help organizations leverage this technology to better communicate their risk exposure and prevent supply chain attacks.
All Bridgecrew capabilities, including SBOM generation and supply chain security, are also a part of Prisma Cloud’s industry-leading cloud-native application protection platform (CNAPP). To learn more about Prisma Cloud’s CNAPP, download the datasheet.