Add attestations for binaries compiled from source

[LaurentGoderre]

No description provided.

[whalelines]

A few questions/suggestions.

It would be interesting to know if there is a generic package PURL, i.e., that is not tied to any distribution or GitHub.

[whalelines]

If we are adding the syntax directive to the alpine-variant Dockerfile, should we not also add it to the debian-variant Dockerfile?

[neersighted]

Previously left in draft as @whalelines beat me to it.

A couple concerns, both related to form and substance:

• Attributing the installed openssl/erlang to packages seems incorrect to me; when sourced from a distribution even the "same" version can be wildly different, as patching upstream software (and having drastically different opinions at times) is the name of the game. It seems misleading at best, and dangerous (if scanners are blindly trusted) at worst to do so.
• The boilerplate is pretty long/brutal, and it seems like 99% of this should be the same across any DOI. Could this be factored into a helper/generic function of bashbrew, such that this is both DRY and any knowledge of how to properly construct these JSON segments is centralized in once place/updated uniformly?
• It feels like a PACKAGE-MANAGER ref may not be most correct here in any case; since there is not a package manager involved. While a new generic/doi namespace could be constructed and a matching package feed used, that will require scanners to have knowledge of both. Knowing that, maybe an OTHER reference would be more appropriate, as it would make it clear that a "special" DOI advisory feed is in use? (ref: https://spdx.github.io/spdx-spec/v2.3/package-information/#7213-examples)

[LaurentGoderre]

@neersighted I was thinking of making into some kind of modular template but didn't know if was to be part od the first pass or after

[tianon]

I think we're going to have a really hard time convincing maintainers who aren't us to add and maintain files like this (even for us, hand maintaining SPDX files feels really dangerous and error prone 😅).

Is there some way we could supplement the scanner to learn how to recognize the versions of the software in various official images? Then we could centralize logic like detecting gosu correctly, for example (which would allow us to finally probably VEX its false positive CVEs out), and could maintain that code separately from the images themselves (especially important as there isn't a strong direct benefit to the image maintainers for creating and updating these documents, so it's going to be a tough sell to convince them to do so).

[whalelines]

@LaurentGoderre is working on a template for these SPDX files to make it easier for everyone to incorporate and we can continue to work on tooling to make things easier for maintainers until the benefits you mention, e.g., proper CVE identification and exclusion, and others outweigh what should be the one-time effort to add these. That said, it's likely we will have to assist with that for some maintainers, i.e., provide PRs to the upstream Dockerfiles.

[LaurentGoderre]

Depends on docker-library/bashbrew#85

[whalelines]

LGTM