-
Notifications
You must be signed in to change notification settings - Fork 375
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE: store SBOM data in rpm headers? #2389
Comments
Hard for me to comment when I don't know a single term/name mentioned here, starting with SBOM which I looked up from wikipedia 😆 A smallish practical example of what that data may look like would help. |
But but but... where have you been? Software supply chain security is the thing nowadays ;-) |
Deep in the Finnish countryside? 😅 |
I hope I get this right, because I'm no expert for that topic either. SBOM is "Software bill of materials". Basically it is a document that describes what exactly is on a product/appliance/container/... There are two standard formats, SPDX and CycloneDX, coming from different directions. SPDX comes from the license side. It is used so that customers can check the licenses of all the software used in some product. E.g. the automotive folks want to make sure that there is no GPLv3 license included. CycloneDX comes from the vulnerability side. It is used for checking if a product contains software that has a known vulnerability. Nowadays, you can use both formats for both purposes (and also convert between the two). Coming back to rpm: The "License" tag is good enough for the license use case. What's missing is information about the included software. This is important because of the modern trend to do static linking (i.e. golang) or bundling modules. As an example, the "cosign" tool is written in golang.
A SBOM generator would then convert this information into identifiers for those modules. Usually purl urls are used: https://github.com/package-url/purl-spec. The purl urls look like this: Another example is identifiers for language modules, e.g. python modules. Those can be calculated from the python egg data. The question was if it would make sense to have a place in the rpm header for those identifiers. |
Both #1532 and #607 seem to touch on the same subject. I'm not opposed at all in principle, the question is more in the details: should the info be in the header of each binary package, or would a buildinfo-style file/subpackage (with a strong identifier tying it to the same build) be enough? The latter allows more flexibility for those who don't need the stuff. |
I am interested in this as well. This does not need to be fully implemented by rpmbuild itself. The list of "components" used for the build can be gathered by the build system. E.g., Mock can already do that https://rpm-software-management.github.io/mock/Plugin-PackageState In this case, the file As I see the option:
I personally like the option to have it in the file. The SBOM audit is not an everyday operation and reading the payload is not big overhead in such situation. In such case the rpmbuild implementation can be just add another option --include-sbom-file=FILE and include the FILE in the payload. Maybe in some location defined by macro provided by the platform (Fedora, SUSE). |
@mlschroe A lot of the stuff around bundled dependencies are often expressed as |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
I'm currently looking into generating SBOMs for container, and I wonder if someone has already pondered if we want to store SBOM data in an rpm header.
Here's where I come from: SBOM generator tools like "syft" support both querying the systems package database to know what packages are installed and getting data from files present in the system. The later is needed because (at least in the container world) many files are generated by the build process.
So for example, if syft sees a go binary it will extract the buildinfo from it and generate an entry for each module dependency. Those are basically cpe and purl urls. SPDX will store them as "externalRef", CycloneDX has them directly in the component data.
Do we want to make it possible to have this for rpm packages as well? I.e. add one ore more tags to store component identifiers? We would need to store an array of "(type,locator)" tuples.
The text was updated successfully, but these errors were encountered: