As we wrap up our Hacktoberfest festivities, we want to say a big thank you to the community for some amazing contributions. Checkov greatly benefited from the enhancements added by the team, like the new ability to scan JSON files for misconfigurations, performance improvements.
Another great contribution we wanted to highlight came from Paul Horton. Watch the clip below to see it in action or keep reading for a play-by-play!
Paul’s contribution added the ability to output Checkov results in CycloneDX XML, allowing users to create an infrastructure as code (IaC) software bill of materials (SBOM) in a standardized format to use in other SOC centric tools.
CycloneDX was built by the OWASP community to build a lightweight, standardized software bill of materials (SBOM). The SBOM was originally created to be passed on to dependent applications to check licensing for the packages included in software and has since been expanded to encompass security use cases. The concept of the SBOM is great for upstream users of software to track their supply chain, open-source dependencies, licenses, and vulnerabilities which, in the past, was a black box.
SBOMs became even more important when in 2013 the OWASP Top Ten added a new “A9 – Using Components with Known Vulnerabilities”—which was recently upgraded to A6 and redefined to “A06:2021-Vulnerable and Outdated Components.”Traditionally, SBOMs were meant for applications to include all of the open source dependencies with their vulnerabilities, but the definition is expanding to include infrastructure components, such as the output provided by this new feature. This elevates misconfigurations to the level of CVEs so that the right attention is paid to both. Additionally, this helps standardize the format of misconfiguration findings. There are many open source and proprietary tools that ingest CycloneDX XML files for use. For example, aggregation tools like DefectDojo have a way to consume them and security teams can prioritize and contextualize CVEs.
How to generate an IaC SBOM with Checkov
To generate a CycloneDX SBOM using Checkov, run your typical Checkov scan and append -o cyclonedx. For example:
checkov -d . -o cyclonedx | xqThis generates an XML output that can be added to other tools that analyze SBOMs. xq is added for formatting.
You can save the results to a file using:
checkov -d . -o cyclonedx > checkov_output.xmlHow to use a CycloneDX SBOM
For the purpose of this blog, we’ll use DefectDojo. I won’t go too deep into the details about DefectDojo, but it is an open-source tool created by Rackspace engineers as an improvement over spreadsheets to manage security scans, track remediations, and accept risk across application scanning tools. This is a powerful way to aggregate scan results findings, request peer reviews, and manage risk across multiple applications, infrastructure environments, and even across multiple security tools.
DefectDojo already has a native way to import Checkov JSON output files, but it can also import CycloneDX files. To add a CycloneDX file to DefectDojo, go to a relevant engagement and select Import Scan Results. Change the Scan type to “CycloneDX Scan,” and select an Environment. Choose the file where you stored the Checkov output and Import.
That will generate a report of all of the misconfigurations identified by Checkov. For each misconfig you’ll have many available options including adding a note, requesting a peer review, setting a service level agreement (SLA), or accepting the risk. Peer reviews allow other team members to check code for quality and security findings. In this case, it’s asking a team member to review if the finding is valid (true positive) or to help with a solution. An SLA is the defined and agreed amount of time within which an issue should be remediated. In the case of the example below, it means that the team managing this issue has agreed to remediate the issue in under 89 days. DefectDojo also includes a central dashboard for aggregated statistics.
Check out the other tools listed for other CycloneDX use cases.
···
This is just another example of the great contribution from our community. We may expand this output in the future, such as adding fix suggestions to the output that can be translated into mitigations in DefectDojo (issue opened). We’re excited to see how you use this output for your own use cases.
Also, while Hacktoberfest has come to an end, we still welcome any contributions to our open-source tools.
