There are several existing SBOM approaches already in existence. This proposal does not seek to replace any of them. It is also agnostic amongst all of them. This proposal fundamentally focuses on allowing tracking the tree of artifacts inherent to an SBOM through the entire chain and allowing them to be associated with metadata. From its perspective, GitBOM treats all of the other SBOM approaches as metadata. SBOM is an artifact tree + metadata A Software Bill of Materials (SBOM) of an artifact is fundamentally a tree of artifacts their associated metadata. Artifact Tree Examples:

NOTE: Much of this thinking has evolved into a simpler form here There are a number of existing SBOM approaches already in existence. This proposal does not seek to replace any of them. It is also agnostic amongst all of them. This proposal fundamentally focuses on allowing the tracking of the tree of artifafts inherent to an SBOM through the entire chain and allow them to be associated with metadata. From its perspective any and all of the other SBOM approaches may be treated as metadata. SBOM is a tree A Software Bill of Materials (SBOM) is fundamentally a tree of artifacts and associated metadata.

This document covers possible ideas for storing and publishing GitBoms Storing GitBOMs during builds When a compiler or linker writes out an artifact, it should store the GitBOMs related to the artifact in subdirectory structure of the directory into which the artifact is written: .bom/objects/${first 2 characters of git ref}/${last 38 characters of git ref} When a compiler or linker is utilizing a child artifact, it should inspect the artifact for an embedded GitBOM reference. If it finds one, it should look for a .bom/ subdirectory in the directory containing the child artifact. If a .bom/ subdirectory exists it should copy all descendent GitBoms for the child artifact into the .bom/ subdirectory for the directory into which it is writing the artifact being built. Storing GitBOMs in a git repo

The Wireguard implementation in VPP is imitating the implementation in the Linux Kernel. In terms of implementations on the wire, this is good. In terms of consumable APIs, it turns out to be deficient for the various ways folks would like to consume it. Motivation Currently we have three known uses cases for wireguard in vpp: Network Service Mesh NSM which would like to be able to cross connect another interface using L3XC to a wireguard peer. This could be done either with per peer interfaces. Calico-VPP VPN GW