Include architecture and/or image digest in JSON output

[cbandy]

Is your feature request related to a problem? Please describe.

When scanning an image index, JSON reports do not indicate which architecture the results are about. I can see the image architectures and digests in log messages but not in JSON.

$ preflight-1.7.2 check container 'registry.access.redhat.com/ubi9/buildah:latest' > preflight.json
level=info msg="certification library version" version="1.7.2 <commit: f1bfa27d3f87bc9b95936aaeb4edc6a92a268645>"
level=info msg="running checks for registry.access.redhat.com/ubi9/buildah:latest for platform amd64"
level=info msg="target image" image="registry.access.redhat.com/ubi9/buildah:latest"
…
level=info msg="This image's tag latest will be paired with digest sha256:0e0d263a42c4971c43290489181dfc58ed723a0797400abe2002cdb219e4bb84 once this image has been published…
…
level=info msg="running checks for registry.access.redhat.com/ubi9/buildah:latest for platform arm64"
level=info msg="target image" image="registry.access.redhat.com/ubi9/buildah:latest"
…
level=info msg="This image's tag latest will be paired with digest sha256:73312575856fc4d64b33c757ac3ec0807cb5b3c0527c05b5284832b4e9219791 once this image has been published…
…

$ cat preflight.json
{
    "image": "registry.access.redhat.com/ubi9/buildah:latest",
    "passed": …,
    "test_library": { … },
    "results": { … }
}
{
    "image": "registry.access.redhat.com/ubi9/buildah:latest",
    "passed": …,
    "test_library": { … },
    "results": { … }
}
{
    "image": "registry.access.redhat.com/ubi9/buildah:latest",
    "passed": …,
    "test_library": { … },
    "results": { … }
}
…

Describe the solution you'd like.

I'd like more details in JSON about the image that was scanned.

I'm deep in image contents all the time, so I think I might like a platform field in the JSON that looks like the OCI index field:

{
  "image": "registry.access.redhat.com/ubi9/buildah:latest",
  "platform": {
    "os": "linux",
    "architecture": "amd64"
  },
  "results": {}
}
{
  "image": "registry.access.redhat.com/ubi9/buildah:latest",
  "platform": {
    "os": "linux",
    "architecture": "arm64"
  },
  "results": {}
}

I could infer the platform from a digest field, so that's a second possible solution. Lots of other things can be inferred from the digest, so perhaps it could obviate other feature requests.

{
  "image": "registry.access.redhat.com/ubi9/buildah:latest",
  "digest": "sha256:0e0d263a42c4971c43290489181dfc58ed723a0797400abe2002cdb219e4bb84",
  "results": {}
}
{
  "image": "registry.access.redhat.com/ubi9/buildah:latest",
  "digest": "sha256:73312575856fc4d64b33c757ac3ec0807cb5b3c0527c05b5284832b4e9219791",
  "results": {}
}

$ skopeo inspect --raw docker://registry.access.redhat.com/ubi9/buildah:latest
{
    "manifests": [
        {
            "digest": "sha256:0e0d263a42c4971c43290489181dfc58ed723a0797400abe2002cdb219e4bb84",
            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
            "platform": {
                "architecture": "amd64",
                "os": "linux"
            },
            "size": 595
        },
        {
            "digest": "sha256:73312575856fc4d64b33c757ac3ec0807cb5b3c0527c05b5284832b4e9219791",
            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
            "platform": {
                "architecture": "arm64",
                "os": "linux"
            },
            "size": 595
        },
…

Describe alternatives you've considered.

Perhaps the image field should have a digest instead of a tag. This change is potentially disruptive.

{
  "image": "registry.access.redhat.com/ubi9/buildah@sha256:0e0d263a42c4971c43290489181dfc58ed723a0797400abe2002cdb219e4bb84",
  "results": {}
}
{
  "image": "registry.access.redhat.com/ubi9/buildah@sha256:73312575856fc4d64b33c757ac3ec0807cb5b3c0527c05b5284832b4e9219791",
  "results": {}
} 

[acornett21]

Hi @cbandy thanks for creating this issue, and providing some ideas that you have thought about. The results.json file is used as the payload preflight sends to our backend system, so this file has to conform to that systems schema. This means we'd have to have changes made in that system first before making changes to preflight.

With that said the first 2 options you purpose at face value seem like possibilities that the backend team could agree to to implement. The 3rd option is a non-starter as I'm fairly certainimage is used by other systems, and tag being part of that is important. I'd rather stick to an addition of fields, then change the meaning/data of an existing field.

I'll reach out to the backend team and we can go from there, though I don't think there would be any movement on this till after the 1st of the year.