[question] How do you handle drift?

[JacobFrericks-Work]

Question

Lets say I have an SBOM ingested with some dependencies that are vulnerable, so I fix them and ingest a new SBOM without those dependencies.

If I do some queries, will the old/out-of-date SBOM still show up?

[pxp928]

Depending on the query you run, you could retrieve the old SBOM data. Currently, GUAC does not delete data but we will add some type of archival flag to data as needed in the future.

Currently, you could query based on the new version of the artifact you have generated that does not contain those dependencies. In that case, it will only include dependency information from the new SBOM (as the origin would be the new SBOM). The packages and artifacts nodes will remain the same between the two SBOMs if nothing has changed (only the dependency from the new version of the artifact will not include the vulnerable packages). If you queried the old version of the artifact (associated with vulnerable dependencies), those dependencies will show up with vulnerabilities associated with them from the old SBOM.

There are some changes we are making with regard to how dependencies are associated with artifacts and SBOMs. This will also make it easier to determine which dependencies are associated with a particular SBOM. #966 goes into more detail about this and also links to a design doc that expands the solution we are planning to implement. This issue is being actively worked on by the guac community.

Please let me know if that answers your question. :)

[JacobFrericks-Work]

So if I'm understanding your comment correctly, then I should be able to:

1. follow that demo (linked above) to ingest an sbom with vulnerabilities
2. modify that same sbom to not have any packages/files/relationships (creating a blank sbom)
3. again follow the demo to ingest the new empty SBOM, and expect that the step "Query pURL to determine vulnerabilities" returns no vulnerablities?

It doesn't seem to work for me. What am I missing?

[jeffmendoza]

Ah no, that should not work. It wouldn't make sense to modify an existing SBOM, as that is not a real world scenario.

Here is one example:

1. An SBOM is generated for package foo v1.0. It has dependencies on packages with vulnerabilities.
2. This SBOM is ingested into GUAC.
3. Package foo is fixed to not depend on those packages with vulnerabilities. A new version v1.1 is released.
4. An SBOM is generated for v1.1 and ingested into GUAC

At this point you are able to run guacone query vuln for either package foo@v1.0 or foo@v1.1. These have different versions so they are different nodes in GUAC.

• The node for foo@v1.0 will be connected to vulnerabilities through isDependency nodes and those will be reported.
• The node for foo@v1.1 will be not be connected to any vulnerabilities, so GUAC will return no vulnerabilities.

The above scenario is what would happen for packages released and distributed by version. Let's say you are generating SBOMs for your own project without releases. In this case, it is the responsibility of the build system and/or SBOM generator to insert a "version" of the top-level package based on the git commit hash. So if the latest release is v1.1 but dependencies were fixed in git only, the SBOM generator / build system would version the top level package in the SBOM as v1.1-1a2c3c (where "1a2c3c" is the first part of the git hash).

In general a package is expected to be immutable. foo@v1.0 shouldn't change, any change to the package itself that would result in a change in its graph should also result in a new version.

---

Another interesting scenario is where two different SBOM generators/scanners have different results when scanning the exact same artifact or package. In this case, the GUAC GraphQL API is setup to store all relevant metadata information in all "verb" nodes. For example the isDependency node has "Justification", "Origin", and "Collector" fields. The parser that reads an SPDX or CycloneDX SBOM will fill these out, so that you know where this relationship came from.

As a group we haven't fully built out all the commands and queries to fully utilize these metadata fields (for example, you can't filter on those when using the guacone query vuln command). We'd appreciate any help with scenarios you have come across on how we can use these fields to record what/where the information is coming from, and filter/query on these later!

[JacobFrericks-Work]

foo@v1.0 shouldn't change, any change to the package itself that would result in a change in its graph should also result in a new version.

This makes sense, thanks for the clarification.

So when I'm building an SBOM, how do I indicate the version? Is that taken from the root level version key? And is the hash taken from the root level serialNumber key?

[jeffmendoza]

No, the version of the component being described is what is important, not the bom version

This one: https://github.com/CycloneDX/specification/blob/1.5/schema/bom-1.5.schema.json#L259-L263
"The component that the BOM describes."

Version is either pulled from purl
https://github.com/CycloneDX/specification/blob/1.5/schema/bom-1.5.schema.json#L503-L508
or version
https://github.com/CycloneDX/specification/blob/1.5/schema/bom-1.5.schema.json#L460-L465

GUAC code is here:
https://github.com/guacsec/guac/blob/main/pkg/ingestor/parser/cyclonedx/parser_cyclonedx.go#L80-L96

[JacobFrericks-Work]

That makes sense. So just to say it again, to make sure I understand the source code correctly, there are two ways to specify the sbom version to keep them separate inside guac:

1. Specify the purl inside the component section of the sbom, which includes the version
2. Specify the name and version inside the component section of the sbom, and let guac take it from there