SBOM-Fridays: I. Introduction to and relevance of SBOMS

In the context of ever increasing software supply chain security needs, the SBOM is gaining traction as a standardized means to find, map and assess dependencies & vulnerabilities of a given software solution. But what is an SBOM? What does it look like? How do I get it? Where and how is it used?

In this series I will tackle all of these questions and more. Having discovered some of the SBOM-potential with a lot of enthusiasm, I would also like to make a deeper dive in this blog, and go beyond just the basics. At the end of this series we will have a detailed proof-of-concept for a smart way to use up-to-date SBOMs, generated at run-time, to increase awareness about the vulnerabilities in your solutions and even mitigate them. Sounds fun? Wait till Compliance starts talking about this.

1. So, What is an SBOM?

   At its core, a Software-Bill-of-Materials is a formal, machine-readable inventory of all components—open source, commercial, and proprietary—that make up a software product. On top of that are mapped dependencies and vulnerabilities, allowing for a precise and highly detailed localization of flaws, breaches, CVEs and their impacted surroundings. Compare it with an ingredient-list enriched with information about (possible) food-allergies and emergency treatment instructions.
   
   

   Its original usage was to manage open source vulnerabilities, based on concepts used in Software Composition Analysis (SCA) tools throughout the early 2000s. Around 2010 these early prototypes began to formalize into machine-readable standards, paving the way for today’s SBOM formats.
   
   

   In 2017, somebody got sloppy and the SBOM concept gained widespread attention and adoption as a countermeasure to dependent companies falling like dominoes over a single breach. (Somebody else was also charged with insider trading, fun story, click the links).
   
   

   Anyway, US & Canadian governments put their support behind SBOMs with Executive Order 14028 and Critical Cyber Systems Protection Act (CCSPA) respectively and EU followed with the Cyber Resilience Act to be implemented shortly.
   
   

   In Asia, Japan is the most proactive country, with the Ministry of Economy, Trade and Industry releasing a “Guide of Introduction of Software Bill of Materials (SBOM) for Software Management”.
   
   

2. What does it look like?

   You can present an SBOM as a JSON, XML or Protobuf. While JSON is most common in modern tooling, some sectors and compliance frameworks indicate a preference for XML due to its strong support of schema validation and structured metadata. More important than the document’s format is that its structure conforms to one of two standardized specifications:

   1. CycloneDX: an open standard, driven by OWASP or

   2. SPDX: ISO/IEC 5962:2021 (describes version 2.2.1 of the SPDX specification)
      
      

   The structure and semantics of the content adhere to the following rules:

   1. Must contain: BomFormat & specVersion. The components by name, version, supplier, unique identifiers (e.g. package URL) and (top-level) relationships and dependencies.

   2. Strongly recommended to include for security and traceability: license info, cryptographic hashes (SHA-1/SHA-256 digests), dependency graph & nested relationships and dependencies

   3. Nice-to-haves in the domain of usability, automation, and compliance:
      VEX metadata, digital signatures, public key (for signature verification), build info, external references and digests

   4. to really tie a bow around it, you can further enrich your SBOM with (meta)data of your own choosing like package authors, READMEs, risk ratings and more.

This breakdown works well with both CycloneDX and SPDX, though each has its own nuances. SPDX is more focused on licensing and compliance and CycloneDX leans into security and vulnerability tracking. This series will focus on CycloneDX mostly, but the principles are the same regardless of format or framework.

Check a highly condensed example below. Mind you, these artifacts swell to 200k lines of JSON easily!

    {
      "bomFormat": "CycloneDX",
      "specVersion": "1.5",
      "serialNumber": "urn:uuid:b18d79fd-a9a4-4c5d-8d39-4a4f01960f5f",
      "version": 1,
      "metadata": {
        "signature": {
          "algorithm": "RSA-SHA256",
          "value": "hUS1ERS4FUAPMtH...U2l0wAeBMbE1/VNkVfMUudJeQ==",
          "keyId": "blog-sbom-key",
          "publicKey": {
            "kty": "RSA",
            "n": "wfod3A...1VVlqV3FNUWw_yk61FVXWnnY3SuQ",
            "e": "AQAB"
          }
        },
        "timestamp": "2025-08-09T11:54:55.3542905Z",
        "authors": [],
        "properties": [{
          "name": "sbomDigest",
          "value": "sha256:4DDC08A6C28C6...E49538E000CF1DB7"
        }]
      },
      "components": [{
        "type": "framework",
        "bomRef": ".NET@net8.0",
        "licenses": [],
        "cpe": "cpe:2.3:a:microsoft:.net",
        "purl": "pkg:nuget/.NET@8.0.0",
      }],
      "externalReferences": [{
        "url": "https://www.software-url.com",
        "type": "website"
      }]
    }

or in XML:

    <?xml version="1.0" encoding="UTF-8"?>
    <bom xmlns="http://cyclonedx.org/schema/bom/1.5" 
         serialNumber="urn:uuid:b18d79fd-a9a4-4c5d-8d39-4a4f01960f5f" 
         version="1" 
         specVersion="1.5">
      <metadata>
        <timestamp>2025-08-09T11:54:55.3542905Z</timestamp>
        <signature>
          <algorithm>RSA-SHA256</algorithm>
          <value>hUS1ERS4FUAPMtH...U2l0wAeBMbE1/VNkVfMUudJeQ==</value>
          <keyId>blog-sbom-key</keyId>
          <publicKey>
            <kty>RSA</kty>
            <n>wfod3A...1VVlqV3FNUWw_yk61FVXWnnY3SuQ</n>
            <e>AQAB</e>
          </publicKey>
        </signature>
        <authors/>
        <properties>
          <property name="sbomDigest">sha256:4DDC08A6C28C6...E49538E000CF1DB7</property>
        </properties>
      </metadata>
      <components>
        <component type="framework" bom-ref=".NET@net8.0">
          <cpe>cpe:2.3:a:microsoft:.net</cpe>
          <purl>pkg:nuget/.NET@8.0.0</purl>
          <licenses/>
        </component>
      </components>
      <externalReferences>
        <externalReference type="website">
          <url>https://www.software-url.com</url>
        </externalReference>
      </externalReferences>
    </bom>

3. Where and how is it used?

   There are two categories of usage:

   A. Compliance, legal audits, international standards and transparency.

   In short, the boring stuff. Basically, SBOMs will be required for software vendors around the world, their importance and content will only expand in the coming years.
   
   

   For instance, under Executive Order 14028, a federal software vendor might need to submit an SBOM alongside every release so an agency can instantly check for known vulnerabilities before deployment.
   
   Furthermore, the National Institute of Standards and Technology (NIST) has published several Special Publications addressing supply chain risk management and software integrity, including SP 800-161 and SP 800-218, underscoring the role of SBOMs in risk identification and mitigation strategies for federal and critical infrastructure software systems.
   
   

   Also, in medical device software, the FDA’s pre-market cybersecurity guidance now recommends SBOMs for transparency and patient safety.
   
   

   For ISO.27001 Information Security Management System & audits too, this can be an artifact of significant value. Given adequate tooling, it can quickly shed light on the structure and granularity of a given system, indicating the identification, documentation & mitigation of risks and threats.
   
   

   I’ve included some links, should you be into those kinds of things.

   B. Static and evolutionary analysis and insights of a software solution, its dependencies and vulnerabilities.

   From a developers or architects perspective, just looking at a code base through a narrow lens of dependencies and vulnerabilities alone, already increases awareness. With strategic tools, we can transform these perspectives into prevention and mitigation investments. I see two distinct sources of information or awareness: static and evolutionary analysis of SBOMs. See it as reading the ingredients on a 2020 Coca-Cola bottle, and then comparing it to a 1920 one.
   
   

   Some examples: Version 1.0.0 contained a vulnerability that was not known at release time. We had no background scanner-service running, and release only twice a year (Where my waterfall boyz at?!). By the time version 1.0.1 is released, the package may have been patched and updated in your code base. No knowledge whatsoever was ever present in your documentation. Great for your sleep, not so much for Compliance anymore..
   
   

   So you write a test, that if a vulnerability is found, you stop the release-pipeline to investigate. And you write a background service that continuously checks for new vulnerabilities, alerting you immediately in such cases. These are simple, static analysis followed-up by action-plans if needed. We’ll dive into this more thoroughly on the fourth installment of this series.
   
   

   We can also take a more historic or evolutionary approach. Let’s say, on every vulnerability found with the scanner, we generate a new SBOM. Version 1.0.1 had an SBOM generated on release and a clean bill of health, vulnerabilities-wise, everything smooth sailing. Scanner finds a newly discovered vulnerability in the NuGet Index/Repository, alerts you, and generates a new SBOM.
   
   

   Given a good interpreter, you immediately see Module X in Project Y used Package Z and has a vulnerability V. You know to which version of your software it is tied, you know exactly when it was introduced.
   
   

   Multiply this by a 100 releases, and you have a documented heat map of vulnerabilities in your code bases’ dependency graph, ready to be assessed, mitigated or rolled into action-plans.
   
   

   This is the cool part. We will go much deeper into this on installment 6 of this series.
   
   

4. How do I Get it?

   You can start generating SBOMs yourself using open-source tools, or opt for paid SaaS solutions that integrate with your code base or repository.
   
   

   If you stick with this blog series, you’ll be able to generate one yourself by the end, without adding much extra dependencies in your code base or costs in the compliance department.
   
   

   Next part we will give an overview of the technical flows needed for an orderly generating of SBOMs and start with the first step!
   
   

   After that, we’ll also look into the Engine itself (part III) and into signing, presenting and delivering the produced artifact (part V). The series will conclude with some general remarks.
   
   

   If you already have some questions about this first part, make yourself heard!
   
   

   Thank you for reading.