Bill of Materials

Using RKVST to track a Bill of Materials

A common pattern for tracking asset lifecycles 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, and can 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 then 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. Jitsuin 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.

Example 2: Connected Device Digital Bill of Materials (DBOM)

Maintaining an up-to-date Software Bill of Materials (SBOM) is a great start to ensuring trustworthiness in your digital supply chain. However there is more to connected devices than monolithic software builds or firmware. Also crucial to understanding your assets' provenance are hardware build standards and components, software configuration, even trained AI models and their lineage. These collectively are known as the Digital Bill of Materials (DBOM). A change in any single one of these can alter the trustworthiness of the whole stack.

Considerations

The pattern for DBOM is essentially the same as SBOM but with more stakeholders and more potential sources of change. This makes the Access Policy definition more complex for write operations but

Edit this page on GitHub