Bill of Materials
Using RKVST to track a Bill of Materials
A common pattern for tracking an assets lifecycle is the Bill of Materials pattern. This is a good choice when dealing with multi-stakeholder systems which change over time, and it is important for the stakeholders to understand the composition of that system no matter who - or what - has changed things.
Modelling such systems in RKVST can help to rapidly answer questions like “what is in my estate?”, “how did it come to be here?”, and “who brought it in?”. In audit situations the Asset histories also allow stakeholders to look back in time and ask “what did it look like to me at the time? Can I show that I made the best possible decision?”
Example 1: Software Bill of Materials (SBOM)
By keeping all the component packages and release history for a software package in one easily identifiable and integrity protected location, all relevant stakeholders can be sure they have the best and most up-to-date information on what software is in their supply chain and how it got there. Stakeholders can then readily identify problems if this record diverges from observed reality.
Considerations
Key to any successful RKVST integration is keeping the number of Asset attributes manageable and meaningful. Do not add every entry in the SBOM as an Asset attribute. Instead, preserve Asset attributes to carry essential metadata such as final build hashes and assured current versions, and put the full details of each released version in attachments and Events.
Note: There are good standards for storing and exchanging SBOM data such as SWID/ISO/IEC 19770-2:2015, Cyclone DX, and SPDX. RKVST recommends adopting standard data formats wherever possible, as these vastly improve interoperability and utility of the data exchanged between RKVST participants.
SBOM as a living document: As a vendor, try to model each final software product as an Asset, and releases/updates to that software product as Events on that Asset. That way, a single Asset history contains all the patch versions of a pristine build standard.
Link to real assets: In reality, not every machine is going to be patched and running identical versions of software, and certainly not the most up-to-date one. As a user of devices, try to link the SBOM from your vendor to the device by having Asset attributes for the Asset Identity of the vendor-published SBOM and the version installed on the device. That way it is easy to find devices that need attention following an SBOM update.
Access Policies: Always try to avoid proliferating Access Policies and make as few as possible with clear user populations and access rights. Typically, very few parties need to update the SBOM record, but many people will need to read it.
Remember that RKVST is a shared evidence platform. It is there to help share and publish the SBOM and create the trust and transparency that is demanded of modern systems, to ensure the security of the digital supply chain.