Catalog ELF metadata

[wagoodman]

This topic has come up in a few different places, in the community meeting and in conversations with @nurmi and @westonsteimel ... so I wanted to capture some of those conversations here.

It is possible to add metadata directly into ELF binaries via linker flags . This is beginning to be leveraged by distros to encode OS and packaging level information directly into the binaries delivered.

Adding a new cataloger that can read this metadata and capture it for all files that store data in this approach would be ideal.

For reference, there is existing tooling to read metadata from an ELF: https://github.com/systemd/package-notes/

To try this out in the go ecosystem:

# in the root of the syft repo
CGO_ENABLED=0 go build -o .bin/ -ldflags "-a -s -linkmode external -extld gcc -extldflags '-static -v -Xlinker --package-metadata={\"type\":\"go\",\"name\":\"syft\",\"version\":\"v0.60.0\"}'" -a ./cmd/syft

[westonsteimel]

I think it would be useful to discuss which other keys might be useful to capture to try and drive some standards around use for non os package manager binaries

The ones I can think of would be something like:

• purl(s)
• cpe(s)
• sourceRepository
• commit

Also what might make sense for the type? It could just follow the type from the purl spec, or could be something more generic likestatic-binary or dynamic-binary or something else entirely.

[westonsteimel]

Also, in the case of APK type packages it would be useful to capture the upstream information. For instance, if the APK package is something like python3-flask it would be useful to understand what the purl and/or cpe are for the flask pypi package since both should be used when trying to match to vulnerabilities based on how the alpine security fix feed is intended to be used

[westonsteimel]

As an example I have updated my personal container build of curl to include ELF package metadata information: https://github.com/westonsteimel/container-library-curl/blob/f80180dd91998524f26c363e2d8b924af91d14ac/stable/Dockerfile#L53

readelf -n /usr/local/bin/curl

Displaying notes found in: .note.package
  Owner                Data size 	Description
  FDO                  0x00000154	FDO_PACKAGING_METADATA
    Packaging Metadata: {"type":"static-binary","name":"curl","version":"8.1.1","architecture":"x86_64","sourceRepository":"https://github.com/curl/curl","commit":"1561d0675208854b39066877b140780a965702fa","purls":["pkg:generic/[email protected]?arch=x86_64","pkg:github/curl/curl@1561d0675208854b39066877b140780a965702fa"],"cpes":["cpe:2.3:a:haxx:curl:8.1.1:*:*:*:*:*:x86_64:*"]}

{
  "type": "static-binary",
  "name": "curl",
  "version": "8.1.1",
  "architecture": "x86_64",
  "sourceRepository": "https://github.com/curl/curl",
  "commit": "1561d0675208854b39066877b140780a965702fa",
  "purls": [
    "pkg:generic/[email protected]?arch=x86_64",
    "pkg:github/curl/curl@1561d0675208854b39066877b140780a965702fa"
  ],
  "cpes": [
    "cpe:2.3:a:haxx:curl:8.1.1:*:*:*:*:*:x86_64:*"
  ]
}

[brian-ebarb]

Hello gentlemen, I'm an engineer with a company that trusts Syfts approach to building SBOM, and we are facing pretty much this exact situation.. we have a cpp based backend application that is built using a custom build manager, not Conan, so we've had no way to generate SBOM from that side of our stack. I've been working on a fork of Syft to add a cataloger that does exactly this, reads a custom .note.package section written into the elf binary. I intend on pushing up a PR for this, but I know it isn't ready to be merged into Syft yet. To be totally honest, I am brand new to Golang in general, but I am definitely familiar with working with large codebases like Syft.. I'm hoping to just start the ball rolling on some conversations on this, so when I do push up the code, its useful to more than just my company, in the spirit of open source contribution.

[wagoodman]

Thanks in advance for the PR @brian-ebarb ! Happy to help with reviewing or chatting through design approaches. Feel free to reach out here or in our slack workspace.

[wagoodman]

I think there are two different interpretations of this issue:

• capture ELF metadata found and denote this on the file objects for transparency
• raise up groups of files with matching ELF package information as logical packages

These are not mutually exclusive -- I think codifying a working "package" definition from ELF metadata will be the hardest part since there is no common convention here, but ultimately I think both of these should be implemented.

#2396 leans towards the latter approach.

[spiffcs]

Closed as of https://github.com/anchore/syft/pull/2715

[wagoodman]

Adding a changelog-ignore to prune this from the release notes -- the last PR was specifically added to the last release. This was closed after that.