Publish auditable image to cloud-based repository service

[blakehatch]

In order for third parties with strong security requirements to use our images, deploying them to an accessible repository service such as Dockerhub that is clearly auditable would help with this.

The main deliverable here is that the hosted image must have the extensively documented Dockerfile that generated it be directly linked in the repo for a security team to easily be able to look over.

[aaronmondal]

I think this needs a bit of rephrasing.

I believe the ask here is for an easily visible page like the "vulnerabilities" section in registries like DockerHub.

The way these audits work is that a vulnerability scanner looks at the contents of the images and matches them against vulnerability databases. What DockerHub shows is just the visualization of that.

AFAIK the de-facto standard for this is trivy: https://trivy.dev/

What we currently do have:

• The signature and verification process via cosign. The verification process is outlined in SECURITY.md.
• An SBOM at https://github.com/TraceMachina/nativelink/network/dependencies

What is currently missing:

• Us actually publishing audit results in some easily accessible fashion. This essentially means running vulnerability scanners on our images in CI and publishing that data in "human readable" form.
• Us documenting that our SBOM already exists and quite reliable since all our dependencies are pinned (except for that docker-compose workflow we really need to get rid of :sweat_smile:)
• Us documenting that vulnerabilities will be published here: https://github.com/TraceMachina/nativelink/security/code-scanning
• SALSA attestations for our builds. Our infra was built with support for this in mind, so many pieces are already in place, bit it's still a nontrivial effort to get this working. The two options here are GitHub actions and Google Cloud Build.

I think the most immediate thing we can tackle is to run vulnerability scanners on our builds by default.

We can also publish images to other registries, but we should be very mindful with that. Additional registries mean additional API keys in GitHub that tend to be long-lived and introduce complexity with room for errors. Not saying that I'm against it, but if we do this I'd like it to be largely automateable without any long lived keys stored in GitHub. I think I'd prefer if logic like that was handled outside the nativelink repository. I.e. to have a separate repo or cloud infra monitor our repo and handle building and publishing images from an entity that is not GHA.

[blakehatch]

I agree with all these points.

However, the simple initial spirit of this issue is to to put an image with a well-documented Dockerfile to some cloud-based repository service that is commonly expected and used by customers (Dockerhub).

If we can accomplish all of these points in a reasonable time to address this issue that would be great!