Skip to content
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

Embedding SPDX into binaries #739

Open
tofay opened this issue Jul 8, 2022 · 3 comments
Open

Embedding SPDX into binaries #739

tofay opened this issue Jul 8, 2022 · 3 comments
Labels
serialization Something about the representation of data in bytes
Milestone

Comments

@tofay
Copy link

tofay commented Jul 8, 2022

Embedding package information into binaries can enable SCA tools and scanners to detect dependencies and check them for vulnerabilities, without needing a separate mechanism to transfer an SBOM.

  1. golang binaries embed dependency information in them by default, and scanners like trivy and syft can detect those dependencies.
  2. Embed CPE names into binaries ossf/wg-vulnerability-disclosures#76 seeks a solution to enable scanners to detect software in self-compiled (i.e non-distro packaged) software, as is commonly the case in container images
  3. A prototype for embedding Rust dependency information into Rust binares: https://github.com/Shnatsel/rust-audit/. This currently embeds a Rust specific, compressed JSON section into binaries. The Rust Secure Code Working Group is exploring whether an existing, language-agnostic format could be used instead.

SPDX, or SPDX Lite, documents could seemingly be embedded into a binary by a producer and detected by scanning tools. Some possible drawbacks:

  1. SPDX documents must contain the date of creation of the document. For this to co-exist with reproducible builds creators of tools to embed SPDX into binaries would need to consider options at reproducible-builds.org/de/docs/timestamps/
  2. The SPDX document couldn't meaningfully contain a checksum of the binary itself
  3. Increase in binary size. rust-audit compresses dependency info using zlib, which SPDX could also allow

Are there any reasons that would make SPDX/SPDX Lite an unsuitable format for this use case?

@swinslow
Copy link
Member

Hi @tofay, good thoughts and good questions. I think this is interesting, and tend to agree that items 1 and particularly 2 from your list are likely to be the major drawbacks to an approach of embedding the document directly in the binary itself.

This may not be directly on point, but two prior discussions that might be of interest to you is at #439 and #502. These were about the idea of having a sort of proto-manifest (and in the case of #502 at least, something lighter than SPDX-Lite) in a project or code repo, which could then in theory be auto-generated into a full SPDX document for a recipient of the code.

I don't think this directly answers the question you're thinking about, but the discussions in those threads might be relevant as you're thinking about this (even though I believe both of those were idea threads that haven't yet been agreed-upon or fully baked).

@tofay
Copy link
Author

tofay commented Jul 12, 2022

Those linked issues are interesting, thanks. #439 overlaps in particular points desire to standardize the attachment of an SPDX document to a "package" (in that case a directory). I don't think this use case needs a new sub-format though.

Could the spdx-spec have a new appendix for attaching/embedding scenarios? That would enable scanning tools to look in specific locations.

Relatedly, I also saw that some IANA types are registered for SPDX which can be used to attach SBOMs to OCI artifacts.


### Sample appendix

SPDX Documents may be embedded into or attached to artifacts.

ELF files and Portable Executables: Embed SBOM document into a section named one of:
- `.spdx`
- `.spdx.yaml`
- `.spdx.json`
depending on the format of the document.

<discuss caveats like reproducibility/checksum of binary itself>

OCI artifacts: When SBOMs are attached as ORAS Artifacts to an OCI artifact, the following [artifact type](https://github.com/oras-project/artifacts-spec/blob/main/artifact-manifest.md#oras-artifact-manifest-properties)) should be used

- [application/spdx+json](https://www.iana.org/assignments/media-types/application/spdx+json) for SPDX documents in JSON format
- [text/spdx](https://www.iana.org/assignments/media-types/text/spdx) for SPDX documents in key value format

Some other concerns:

  • PE section names can be maximum 8 characters in length
  • compression data (native compression could be used for ELF)

@goneall
Copy link
Member

goneall commented Apr 4, 2024

Moving to SPDX 3.1 for consideration.

@goneall goneall modified the milestones: 3.0, 3.1 Apr 4, 2024
@bact bact added the serialization Something about the representation of data in bytes label Dec 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
serialization Something about the representation of data in bytes
Projects
None yet
Development

No branches or pull requests

5 participants