Understanding security relevant fields of CycloneDX files

Question

Basically, title. I have a program that checks for security relevant changes between two cylconeDX SBOM's, formatted in json.

I've written an application to diff the two sbom's, though, I am noticing that there are fields that change from run-to-run that don't seem to be relevant to actual component change, e.g. sha256 hash changes of a particular component property; e.g.:

"components":[
  {
    "bom-ref":"foo",
    "name": "bar",
    "cpe": "foobarCPE",
    "properties": [
      {
        "name":"syft:someLocation:idx:layerID", 
        "value":"sha256:some_sha_here"
      }
    ]
  },
  {
   "bom-ref":"{foobar}",
   ...
  }
]

If I ignore the [components][properties] field, is there the potential for relevant changes in a component's nature to be missed? And as a tag-along, should I be considering less information here? Based on some light reading, it seems like the purpose of CPE's exist to guarantee a common way to indicate significant changes in baselines, but I am somewhat unclear.

Answer 1

Following up on this answer, some months later, a few months wiser.

The crux of the issue, here, was that the sha256 hash for some docker layers were changing. This was indicating that the construction of the layer itself had changed. This should be static, otherwise.

You might think to yourself, "that seems problematic". From a security standpoint, indeed it should. The change in hash indicated that the layers themselves had been altered. Due to how the dependencies of this particular project were constructed, the docker containers of several different repoes were using different version numbers of various dependencies, depending on some corner cases.

So, if you have landed here wondering, "Can I disregard the changes in hash?" It depends. Are you trying to make security assurances? If so, this is probably a show-stopper, until you can figure out how to properly attribute your dependencies. Are you trying to build an SBOM? Then it's probably fine. In our case, the solution was to compile a set of keys, comprised of the dependency's name, version, and source.

If things had changed from run-to-run, there was a report that would state what was added, what was removed, and what had changed. This may be insufficient for your use-case, but it solved our problem. YMMV.