Step 3. Utilise & Maintain the dependency catalog

Comply with US executive order with a Product-Level SBOM

The US executive order stipulates that if you provide software to any of the US government agencies you will be required to provide self-attestation on your software build practices as well as an SBOM. This normally means you will need to:

1. have a central storage of your services and their SBOM
2. a way to (easily) aggregate the service SBOMs onto the product level (which is the digital product/service) you provide to the US government (or even other external stakeholders)

VSM allows you to generate the Product-level SBOM within minutes and automatically for you by going to your product and generating it there. The output will be a CycloneDX SBOM aggregated from all the underlying service SBOMs. This will put you in a very comfortable position to comply with US government regulations.

> 📘 I cant see the option to download the Product Level SBOM

The product page will only show this option if at least one of the supporting services has a SBOM attached. Given that we only recently started to store the incoming SBOMs to generate the aggregated SBOM, you might need to wait until the supporting services' SBOMs are replenished.

Understand your software libraries in their business and technological context

Once you have mapped your service into your service catalog ( this is a one-time effort) you can dive into understanding your technological footprint and used libraries globally and on a service-per-service level.

On a per service level, VSM assimilates the SBOM information into an easily searchable format - that can also be tagged, for example for assessments:

On a global scale information from all collected SBOMs is brought into a central "Library Catalog" which allows thorough impact analysis at scale. Utilizing the other information collected as part of VSMs Service & API catalog provides a per-servicequick impact assessment of which services depend on a specific library, which teams are responsible for those services and which end-user-facing products are ultimately affected by them:

Library Assessment

From the Service Catalog, uploaded CycloneDX SBOMs, and mapped Teams and Products we already get a comprehensive picture of which software libraries are used, where, by whom, and which parts of the business depend on them.

With tagging we can take this to the next level, bringing in a vulnerability assessment as well as central documentation on the recommended remediation. For this we recommend two tags:

• Vulnerability Rating - this tag tracks whether a library exposes a known vulnerability or not. This score can be manually maintained or automated through VSMs GraphQL API. We recommend a 5 Point score:
  • No known issues
  • S4 Low - Plan for one of the next six Sprints
  • S3 Medium - Plan for one of the next four sprints
  • S2 High - Plan for one of the next two sprints
  • S1 Critical - Treat as S1 issue and fix or circumvent it as soon as possible. Immediate attention is necessary, any other sprint work is to be dropped in favor of it.
• Remediation - with this tag we provide guidance on how developers should deal with a known vulnerability. We recommend a 3 tier tag structure:
  • At target - the library should be kept at the current version
  • Downgrade - the library should be downgraded
  • Update Available - an updated version is available and should be used.

Maintain your SBOM data

The above analysis and resulting insights are only as reliable as the data they are based on. To ensure that your entire service catalog has appropriate SBOM data and to track that it is regularly updated VSM provides a central health dashboard - for the SBOM case, a key metric is the "Services with an SBOM" percentage, to ensure that your entire digital supply chain is appropriately documented.

In a similar fashion an assessment is made on a per-Product level to capture how much of a product's underlying have appropriate library information attached: