Add a security annotation #1284
Conversation
sudo-bmitch
requested review from
jonjohnsonjr,
stevvooe,
sajayantony,
tianon and
cyphar
as code owners
There was a problem hiding this comment.
I don't love it, I don't hate it. I personally think something less prescriptive is better (ie more akin to description than all our URL-only annotations), but I do agree that if we do it, it should be just the one single annotation (and I won't block it further if others feel strongly one way or another).
I guess what I'd really like to see is some group creating a new set of their own annotations so we stop being the clearinghouse for every single annotation everyone might want as if we're the only body who can define keys people should use for interpretability (especially since the nature of their names means we can't reasonably be a "trailing spec" in doing so without causing the same naming pain and suffering we caused with the initial spec changes off Docker).
annotations.md
Outdated
| - This SHOULD be the immediate image sharing zero-indexed layers with the image, such as from a Dockerfile `FROM` statement. | ||
| - This SHOULD NOT reference any other images used to generate the contents of the image (e.g., multi-stage Dockerfile builds). | ||
| - If the `image.base.name` annotation is specified, the `image.base.digest` annotation SHOULD be the digest of the manifest referenced by the `image.ref.name` annotation. | ||
| - **org.opencontainers.image.security** URL to get the image security policy (see [RFC 9116][rfc9116] for an example). (string) |
There was a problem hiding this comment.
Maybe "for a possible format" or something so it's clear this doesn't HAVE to be RFC 9116 (which as I said on the call, personally feels like a weird standard to apply for container images)?
There was a problem hiding this comment.
Note that RFC 9116 is published on web sites, but isn't limited to websites. The entry for GitHub points to HackerOne which includes things like the GitHub CLI in their scope. I've updated the PR with this change and a const in the Go spec for the new annotation.
Signed-off-by: Brandon Mitchell <[email protected]>
sudo-bmitch
force-pushed
the
pr-annotation-security
branch
from
2d0dbbb to
8595108
Compare
Would that be a return to label-schema? If so, I'll politely disagree. That's just trading one standards group for another and I see value in consolidating the two. If we're pushing for each group to make their own annotations for common data, I worry that would create a discovery issue. Just for security, there are countless groups all in the same space, CNCF TAG Security, OpenSSF, and OWASP to name a few. Hunting around in multiple locations to find all the well known annotations for different types of metadata people want to include is not a great user experience. |
|
The devils-advocate argument against putting this in the actual spec would be that |
|
Security bugs are just that, bugs, with their own severity. How/who do we contact today based on information in image-spec annotations? for any bug? |
We have annotations for the public source code and image authors. Security reports differ from bugs not just severity, but in disclosure policies that would prevent the use of public bug trackers. Security researchers acting in good faith with a coordinated disclosure policy would only use a public bug tracker when other options failed. |
|
To be honest, the more I think about it, the more I like |
For the strict syntax that requires the URL points to the RFC9116 implementation, that makes a lot of sense to me. But it leaves the concerns:
For me, when the 3rd party is not responsible for any part of the image creation or consumption process, it feels wrong for OCI to offload this responsibility to them. And I think it's reasonable for users to not know to look to that 3rd party for the annotation definition. |
Fixes #1283. We had a discussion on this in today's meeting and there was indecision on whether we should have it at all, and if we include it how prescriptive the value should be. So I'm raising this to give us something specific to review.