opencontainers
Add a security annotation
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.
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).
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 org.securitytxt.url would be another reasonable annotation to use for this. Of course, I doubt they have an interest in adding OCI-related stuff to their spec so we'd be back to the discovery problem.
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?
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 org.securitytxt.url...
To be honest, the more I think about it, the more I like
org.securitytxt.url...
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:
- Discovery: how do users find the annotations they could be using? Is there a directory of them maintained somewhere?
- Other use cases: is there an option for users that wanted to point to their security.md file that doesn't follow RFC9116?
- Ownership: does securitytxt.org want to own and maintain the definition of OCI annotations?
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.