Create and distribute Software Bill-of-Materials (SBOM) for Python artifacts

[sethmlarson (Seth Michael Larson)]

@steve.dower

I’m especially in favour of using whatever metadata we have to indicate that known vulnerabilities are not impactful. That’s a massive issue (specifically, people not understanding that “known vulnerability” doesn’t necessarily mean an actual problem or risk), and it would be great for us to lead in showing that there’s a way to handle that.

This is something I’m figuring out how to do right now, I agree we’d want to have this when we start publishing SBOMs (though I suspect uptake of SBOMs themselves might be slow, so maybe we have some time in-between?)

I know that specifically Grype has support for ingesting VEX statements (other tools may too) in order to show true affectedness of vulnerabilities for components in an SBOM and they want to make VEX statement usage automatic rather than manual to increase usage. I posted my proposed architecture and that seemed to have a positive response, so I am hopeful we’ll be able to ship with this at least for some tooling?

@steve.dower

I don’t think we need to include them in the packages themselves, but can just publish them at predictable URLs. But I’m not quite sure where the tooling has landed around this yet - certainly nothing I’ve encountered expects to find them in the actual install files.

There is guidance for SBOM naming, this guide was put together by the OpenSSF SBOM Everywhere SIG (and I was a contributor) which applies to releases which are a “flat” lists of artifacts (like the ones on Download Python | Python.org).