No pain, big gain
Adding SBOM creation and distribution to your work flows is simple and straightforward. There should not be any need to change your existing tooling, and adding the new steps should slot right in with multiple tool options available.
The process looks something like this:
Steps
Step 1: Build your software
An essential fact to remember is that SBOMs are created against built artefacts, not source code. For example, different builds can introduce different dependencies, and different operating system targets will have different runtimes, network stacks and so on, all of which are key sources of vulnerabilities.
Happily, in many cases there is no need to change the way you build and release software in your CI/CD system, nor any need for source code intrusions such as instrumentation or annotations. Just build and package the product, then add a step to generate the SBOM from it.
Step 2: Generate SBOM for this build
A variety of tools exist to create an SBOM for your build product or component, CycloneDX tools, Syft, and Snyk among them. Which is right for you will depend on a number of factors including programming language and deployment methods (binaries, containers or SaaS).
NOTE: Most SBOM tools at the present time don't actually output the full minimal set of information as defined by NIST/NTIA. Make sure you include as much of this as you can.
If you're not sure which tooling to use, or how to include the additional metadata required for NIST Foundational compliance, we've created an example that uses Syft to generate an SBOM from a Docker container in our GitHub samples repository.
Step 3: Store the SBOM for later reference
It is not necessary to store SBOMs for every build you make: CI builds and test runs, for example, don't need to be saved. However you should store the SBOM for every production build that you make just in case you (or one of your customers) need it later.
You can do this practically anywhere: in the build package itself, on a simple file share, or in an artefact store such as Artifactory. But as you look towards step 4 it may well make sense to store them in a place purpose-built for sharing and distribution when you need it: either RKVST SBOM Hub if your needs are simple, or RKVST if you need more control over who gets to see what in your SBOMs.
REMEMBER you are in complete control of your SBOMs and release data. Your SBOMs are stored safely and privately for you until you choose to share them with others.
To see how to integrate RKVST APIs into your workflow and upload SBOMs we have created simple examples in our GitHub samples repository:
Step 4: Distribute the SBOM to relevant interested parties
Now you are ready to take the final and most valuable step in your SBOM journey: share it with interested parties.
Here you have 2 options:
RKVST SBOM Hub
RKVST
If your use case is more complex and you'd like to enjoy the benefits of listing and indexing your SBOM publicly but still need find grained governance of sharing the contents, you can enjoy the best of both worlds by combining the 2 solutions. If that interests you, take a look at our article on that topic.