Skip to main content
The Binarly Transparency Platform surfaces two distinct kinds of origin data:
  • Extracted component metadata - the installed-package record (name, version, vendor, and so on) a scanned binary came from, read directly from the package manager’s own records inside the image.
  • Dependency provenance - the vendor, product, version, and (when derivable) CPE/PURL identifiers for a specific identified dependency, used to query and attribute vulnerabilities.
Both are derived from data the platform builds during analysis, not from an external attestation. The last section of this page explains this in-depth.

​
Extracted component metadata

When the Binarly Transparency Platform analyzes an OCI image, including Docker images, or a disk image, it reads the package manager’s own installed-package records to attribute each binary component to the package that installed it. This works directly from the RPM, dpkg, or Alpine apk database found inside the image, so no vendor-supplied manifest is required. Component-level attribution is one of the inputs to the transitive dependency classification.

​
Package manager coverage

Support differs by image type. OCI image scans read all three package databases; disk image scans currently read RPM only.

​
Extracted metadata

For each package a component is attributed to, the platform extracts the following from the package manager’s own records: This metadata does not itself carry a Package URL or CPE identifier. Those are generated separately, as dependency provenance, described next. Extracted component metadata feeds the component records in SBOM export and the dependency attribution shown for a scanned image, giving you the actual package origin of a component based on what’s installed in the image rather than what a vendor claims is present.

​
Dependency provenance

When the platform identifies a specific software dependency inside a component, whether embedded or referenced, it attaches a provenance record carrying the vendor, product, and version of that dependency, along with a CPE and Package URL identifier when one can be derived. This is generated from Binarly’s vulnerability data sources and version-identification rules, independent of the package manager metadata described above. A single identified dependency can carry more than one vendor/product pair, because vulnerability data sources have historically used different vendor names for the same software. For example, util-linux maps to multiple vendor/product pairs, including kernel/util-linux and andries_brouwer/util-linux; the platform queries vulnerabilities against every listed pair so a record filed under an older or alternate vendor name isn’t missed. This is why the same dependency can appear with more than one Package URL, such as pkg:deb/kernel/util-linux@2.31.1 and pkg:deb/andries_brouwer/util-linux@2.31.1. Which identity the platform queries vulnerabilities against depends on whether package metadata confirms the dependency and whether the ecosystem has advisory coverage. That decision, and what happens when either condition fails, is covered in When package data takes precedence. The attribution itself does not change with the outcome: a dependency carries the same vendor, product, CPE, and Package URL whether the finding came from package data or from an identified version. Dependency provenance is surfaced in finding details when applicable and in SBOM export.

​
What provenance isn’t, and what stands in for it

Extracted component metadata and dependency provenance are package and vulnerability identification, not cryptographic proof. The platform does not generate, ingest, or verify build attestations: no SLSA provenance, no in-toto attestation, no Sigstore/cosign signature, no GPG signature verification. A package’s presence and version are established by reading the image’s own package manager records, not by validating a signed claim about how it was built. Instead of a signed attestation, rule-based findings carry evidence: the decompiled code and instruction-level annotations showing exactly where the vulnerable pattern was matched in the compiled binary, described in Debugging Symbols. This proves the vulnerable pattern exists in the binary as analyzed. It doesn’t prove anything about how that binary was built or signed, which is a separate concern from provenance as documented here.