The Software Bill of Materials, Part 4: SBOM with Debricked

At Debricked, we favor and currently support the CycloneDX format for SBOMs. This is not to say that there are no use cases that are a better fit for the SPDX format. Still, we believe that the license support in CycloneDX is sufficient, and the additional vulnerability fields it provides are very useful.

---

Catch up on other posts in our SBOM series:

The Software Bill of Materials, Part 1: Benefitting from the SBOM

The Software Bill of Materials, Part 2: Drivers, motivators, and challenges

The Software Bill of Materials, Part 3: The SBOM file

Generating an SBOM 

Generating or exporting an SBOM is available for our enterprise-tier customers. If you have integrated your repositories with Debricked, an SBOM can be generated as a report. You can choose to generate the SBOM for a single repository or a chosen set of repositories, or you can generate a global report for all your integrated repositories.

The SBOM will be generated as a JSON file and emailed to the email address associated with your account.  

Some of the things that will be found in the SBOM generated by Debricked are: 

• All dependencies, including transitive dependencies, together with their CPE and/or PURL identifier. 
• The identified license for the dependencies. Both the SPDX license short name and the actual license text is provided. As external references, we also point to the URLs of the actual license information. This reference is denoted “Proof of License” and enables anyone to find the license file easily. 
• The vulnerability data for each dependency. This data includes the vulnerability identifier (CVE, GHSA, etc.), the source, the CWE, a description of the vulnerability, references to more information, the CVSSv2 and CVSSv3 scores, and dates when it was published and last updated. 
• Relations between dependencies. All dependencies are listed for each library, providing the complete dependency graph for all open-source components. If a library has no dependencies, this is indicated with an empty list.  

Using the API 

If you prefer to use our API, the SBOM can be generated using the corresponding endpoint. There are a few API endpoints to choose from, and we refer to the API documentation for a complete overview. One of them is to simply generate an SBOM based on a selected set of repositories, as shown below.

Here you can choose if you want to include vulnerability and/or license data as well. Using the API will require an access token. A refresh token can be generated in your Debricked account, which can be used to generate a JWT token. Or you can just use your login ID and password to generate a JWT token immediately. 

Uploading and analyzing an SBOM 

If you have an SBOM and want it analyzed, Debricked can do it for you. We even monitor the dependencies for new vulnerabilities, and we can alert you if any are found.

Manual upload 

The easiest way to analyze an existing CycloneDX SBOM is to upload it in the Debricked GUI. Just go to Repository settings, and click the Manual scan button.

Here you can select the SBOM file or just drag and drop it. The SBOM will show up as a new repository, listing all vulnerabilities, licenses, and dependencies. If there is a new vulnerability, it will also show up in the user interface.  

Adding SBOM to a repository 

The manual scan option will show new vulnerabilities in the UI. If you want to be alerted, e.g., with an email, every time there is a new vulnerability, then you can simply add the SBOM to be scanned as part of the CI/CD. When scanning the repository, Debricked will find the SBOM file and scan it for new vulnerabilities.  

Upon a scan, you can set up an automation rule to trigger existing or new vulnerabilities. You can tailor the automation rule to, e.g., trigger an alert if the vulnerability is of high or critical severity. Below, we show an example that will send an email to all Debricked account administrators upon a scan if there is a new vulnerability or a vulnerability with at least high severity.

This will allow the administrators to be reminded of high-severity vulnerabilities on every scan but only to be alerted to lower-severity vulnerabilities once. Also, vulnerabilities that have been triaged not to affect the organization or software will not cause any alerts. This is ensured by checking the box “Ignore unaffected vulnerabilities.” 

Let us look at an example of how you can use GitHub for monitoring and alerting on identifying new vulnerabilities. To trigger a scan, you use a scheduled GitHub actions workflow. Workflows are added to the .github/workflows subfolder. For Debricked, the workflow can look like this.

name: Debricked scan 

on: 

  schedule: 
    - cron: "0 9 * * *" 

jobs: 
  vulnerabilities-scan: 
    runs-on: ubuntu-latest 
    steps: 
    - uses: actions/checkout@v2 
    - uses: debricked/actions/scan@v1 
      env: 
        DEBRICKED_TOKEN: ${{ secrets.DEBRICKED_TOKEN }}

This will run a new scan of the SBOM every day at 9 am and trigger alerts according to the automations rule above. 

It is, of course, possible to do similar scheduled scans if you are using other CI/CD tools. 

Concluding 

Since Debricked supports scanning and monitoring SBOMs, the SCA tool is not only for software producers and developers. It is also a powerful tool for purchasers and consumers. Debricked will handle the automation and interoperability parts, monitor new vulnerabilities and license changes, and alert you on any significant changes.  

Once the requirements to supply an SBOM together with software products are met, all stakeholders throughout the value chain will be able to better understand the products’ security. This will lead to more secure products, better responses to new vulnerabilities, and transparency in the software supply chain.