On SBOMs, BitBucket, and OWASP Dependency Track

The museum of old and new architectures I am involved with forced me to look into safeguarding them. For instance, an old dependency can turn CVE or a solid open-source project can go commercial. This is where the concept of a Software Bill of Material (SBOM) came into existence to catalog the license and dependency ecosystem of systems. This build artifact, in its turn, is then analyzed to determine whether the constituting components are:

1. Vulnerable to exploitation, or
2. Licensed under unpalatable conditions, such as being too commercial or too predatory.

This article will explain how to control such vulnerability using:

1. BitBucket pipes for SBOM generation, and 
2. How OWASP's Dependency Track can analyze it.  

Know Your Risk

Not knowing what lurks in your code and containers is bliss, but dangerous. However, popping all your components through a dependency analyzer can give overwhelming feedback. It is better to dashboard and embed in team culture that the amount of dependency issues should always be less today than it was yesterday.

Wikipedia states that: "The Open Worldwide Application Security Project (OWASP) is an online community that produces freely available articles, methodologies, documentation, tools, and technologies in the fields of IoT, system software, and web application security." It is therefore not surprising that they provide a platform to track and analyze vulnerabilities in systems. Its most striking feature is its main dashboard:

The biggest graph in the middle displays the number of vulnerabilities for all projects being tracked. Metrics on critical, medium, and low ones are displayed just below. Dependency Track retrieves known vulnerabilities from one or more sources. The most notable of these is the list of Common Vulnerabilities and Exposures (CVE) from the United States National Vulnerability Database. Each CVE is assigned a level of criticality from unknown and low to critical. This risk analysis is performed by Dependency Track at regular times behind the scenes using the relevant Software Bill of Material (SBOM) as input. 

The section directly below the biggest graph details policy violations, with policies being configured according to what one finds important. One can register certain dependencies as unwanted, or one can mandate that certain licenses or even group of licenses be dashboarded and reported upon. This feedback mechanism is configurable on a per policy basis.

The top section then depicts portfolio vulnerabilities, projects at risk, vulnerable components, and a risk score over time.

There are more views, graphs and statistics such as progress on auditing, vulnerability per project over time and vulnerability per component over time amongst others, but let us rather turn our attention to how BitBucket can generate and send the SBOM to Dependency Track.

BitBucket Prepares the SBOM

The preparation of the SBOM happens in the BitBucket CI/CD pipeline that executes after pull requests are merged to the main branch. This ensures that the dashboards are always up to date with the state of affairs. 

I used a BitBucket pipe that wraps syft to generate a CycloneDX SBOM. The syft commands for code and container interrogations differ slightly.

Code Sniffing

The syft command to analyze code from the root of your project is as follows:  

syft --output cyclonedx-json=code-cdx-sbom.json -v --java-use-network true .

This command outputs the SBOM to a file called code-cdx-sbom.json and uses the network to retrieve license information from the internet; for instance, from the central Maven repositories.

The syft BitBucket pipe from shiftleftcyber (thank you!) is then configured in the script block of the BitBucket pipeline to wrap this syft command as follows:

- pipe: docker://ccideas/syft-bitbucket-pipe:1.0.0
  variables:
    SYFT_CMD_ARGS: '. --output cyclonedx-json=code-cdx-sbom.json'
    SYFT_JAVA_USE_NETWORK: 'true'

The readme of the syft project lists an impressive array of supported languages, but I only used it on Java and JavaScript with a Python project in the backlog.

What Lurks in Your Containers?

To scan a container from your registry, one runs the following command within the scope of a "docker login":

syft --output cyclonedx-json=container-cdx-sbom.json docker.s2c.co.za/container:latest --from registry

The corresponding BitBucket pipe is:

- pipe: docker://ccideas/syft-bitbucket-pipe:1.0.0
  variables:
    SYFT_REGISTRY_AUTH_USERNAME: sadilar
    SYFT_REGISTRY_AUTH_PASSWORD: $DOCKER_PWD
    SYFT_CMD_ARGS: 'docker.s2c.co.za/container:latest --output cyclonedx-json=container-cdx-sbom.json --scope all-layers'

The all-layers switch instructs syft to inspect all layers of the container image and not only the final product.

BitBucket as the Medium of Deposit

All that remains is for Dependency Track to ingest the SBOM. I used the sister pipe of the BitBucket pipe that generated the SBOM:

- pipe: docker://ccideas/sbom-utilities-pipe:1.5.0
  variables:
    PATH_TO_SBOM: code-cdx-sbom.json
    SEND_SBOM_TO_DTRACK: 'true'
    DTRACK_URL: https://deptrack.test.s2c.co.za
    DTRACK_PROJECT_ID: df3327b2-5439-43ab-bb33-1f24228b6074
    DTRACK_API_KEY: $DTRACK_TEST

I specified three input parameters:

1. URL of Dependency Track instance
2. The ID of the Dependency Track project to load the SBOM
3. The API key to authorize the upload

The project ID can easily be found by clicking "View details" from the project view:

Followed by copying the Object Identifier at the bottom:

The API key is found in the similarly named entry field of the Automation team, accessible from the left panel's Administration menu:

Conclusion

Past incidents taught that exploitation of weaknesses tend to result in service disruptions that can spill over into neighboring systems or industries. It causes unexpected expenses and inconvenience. Recovering from it will diverge developers and resources away from team targets. 

The licensing of an open project, furthermore, can turn commercial and result in an organization being slapped with backdated licensing fees. On the other end of the scale, demands can be made to open-source critical IP used to gain the competitive advantage due to predatory license conditions. 

It is therefore the responsibility of each developer to implement and support active strategies to counter these risks. Should your code be on BitBucket, the approach outlined above can help your system(s) get with the program. However, the Dependency Track API does not limit access to BitBucket exclusively and there must be ways to get Software Bill of Materials to it from other CI/CD pipeline technologies.