Ability to block admission if image SBOM contains specific package (defined in Cue)

[jdolitsky]

Currently, the policy admission controller is able to block admission based on the presence of certain attestations, evaluated against some Cue code. For example, from here:

...
  policy:
    type: cue
    data: |
      package sigstore
      import "struct"
      import "list"
      authorityMatches: {
        keyatt: {
          attestations: struct.MaxFields(1) & struct.MinFields(1)
        },
...

I'd like the ability to, with similar syntax, prevent admission of a container with a SBOM that indicates it has a vulnerable package.

For example, the Log4Shell vulnerability (CVE-2021-44228) affects several versions of the packages "log4j-api" and "log4j-core". Given that I have a attached an SBOM to my image, I'd like to be able to prevent admission based on whether a vulnerable version of one of these packages is listed in that SBOM.

Not sure what the inline Cue might look like, but something similar to authorityMatches, such as packageMatches where we can specify that specific versions of specific packages are not to be allowed.

[jdolitsky]

Maybe also, as a prerequisite, the ability to block on whether the image has an SBOM at all

[vaikas]

I'm sure it's a hugely unpopular opinion, but I'm curious if we might want to revisit having sbom as a separate entity from a regular attestation? We have signatures, attestations, and sboms. We even have SBOMs as attestations, in a standard in-toto format. So, I guess why not just create an SBOM as an attestation and then use the policy like you've linked to evaluate it just like any other attestation. Having a parallel way to define policies just for SBOMs just feels a bit wonky.

[hectorj2f]

@jdolitsky The complexity of processing sboms (multiple formats, spdx or cyclonex ... in xml, json) and how to find those sboms is something that you don't want to do on an admission controller. I'd rather expect certain attestations to know if an image does not contain a certain package.