Replies: 1 comment 5 replies
-
Do you mean SBOM? |
Beta Was this translation helpful? Give feedback.
-
|
Oops, yes sorry, I got that mixed up. I will fix the verbiage in this issue. |
Beta Was this translation helpful? Give feedback.
-
|
Trivy is unable to identify the binary path from the Bitnami SBOM. It has @juan131 Is there any reliable way to extract the file path? I'm sorry for tagging you. Please feel free to forward me to the appropriate person. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @knqyf263 I'm afraid the person with more background about this structure is on sick leave, I'll try to give you an update once he's back |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! We'll wait for that. |
Beta Was this translation helpful? Give feedback.
-
|
Just to make sure.. I think there are 2 different issues I lumped into this 1 discussion - the first is the missing target information on the package discovered from the SBOM doc. This seems straight forward and possibly something that can easily be addressed within trivy. In this example I would would think the target could be reported as something like The second issue is the one you're currently discussing and I see now that this is more complex (and may involve changes on both consumer and producer). There are (at least) 3 levels of things being reported in the Bitnami SBOM:
My original discussion centered around the double reporting on 1 & 2, and you have brought up an example of level 3. Rather than attempting to use the I am looking through the specification, and the spec has a Files block, which is potentially being the better way to express what we're talking about in item 2, having first-class support for file locations. The File Information is specified in Section 8. They have some examples showing a package which contains files. Confusingly, the example shows this relationship through a This example could then look something like: |
Beta Was this translation helpful? Give feedback.
-
Description
If I scan a Bitnami image that contains an SBOM (SPDX) file, I see a vulnerability discovered by the SPDX document, and the same vulnerability discovered by the gobinary scanning.
The vulnerability from SBOM scanning does not have a target reported (in either the table or JSON output).
Desired Behavior
I would expect 2 things:
Actual Behavior
The 2 expectations above are not met.
Reproduction Steps
docker.io/bitnami/grafana@sha256:5950f7be27595bccc83b70998bc44f85518a0c40c2c9bdeeaf6b29a15e6105f9{ "packages": [ { "SPDXID": "SPDXRef-grafana", "name": "grafana", "versionInfo": "11.3.0-2", "downloadLocation": "git+https://github.com/grafana/grafana#refs/tags/v11.3.0", "licenseConcluded": "AGPL-3.0-only", "licenseDeclared": "AGPL-3.0-only", "filesAnalyzed": false, "externalRefs": [ { "referenceCategory": "SECURITY", "referenceType": "cpe23Type", "referenceLocator": "cpe:2.3:*:grafana:grafana:11.3.0:*:*:*:*:*:*:*" }, { "referenceCategory": "PACKAGE-MANAGER", "referenceType": "purl", "referenceLocator": "pkg:bitnami/[email protected]?arch=amd64&distro=debian-12" } ], "copyrightText": "NOASSERTION" }, { "name": "opt/bitnami/grafana/bin/grafana", "SPDXID": "SPDXRef-Application-5a701a91b6724cbb-grafana", "downloadLocation": "NONE", "filesAnalyzed": false, "primaryPackagePurpose": "APPLICATION", "copyrightText": "NOASSERTION", "licenseConcluded": "NOASSERTION", "licenseDeclared": "NOASSERTION" } ], "relationships": [ { "spdxElementId": "SPDXRef-grafana", "relationshipType": "CONTAINS", "relatedSpdxElement": "SPDXRef-Application-5a701a91b6724cbb-grafana" } ] }Target
Container Image
Scanner
Vulnerability
Output Format
Table
Mode
Standalone
Debug Output
Operating System
RHEL 8
Version
Checklist
trivy clean --allBeta Was this translation helpful? Give feedback.
All reactions