Independently-published VEX documents?

[raboof]

Great to see you're also experimenting with VEX!

At Apache, we see downstream users use trivy to scan for vulnerabilities - which we encourage, as it's important for them to know when it is urgent to update or investigate potential security issues. However, such scans often produce many false positives, where dependencies are used in a way that does not surface the problems for which advisories may have been published.

VEX appears to be a promising approach to share (non)exploitability of dependency vulnerabilities in a machine-readable way, improving the accuracy of scan results. We would like to be able to publish this information in a way that doesn't just work with our own SBOMs, but also when using scanners like trivy.

CycloneDX appears difficult to use for this: the affects.[].ref fields can be a bom-ref (which I think needs to be in the same file) or BOM-Link (which references the SBOM's unique id, which we of course cannot predict).

SPDX and OpenVEX seem a little more flexible, using purl, but there purl's ambiguity could be a challenge: if the sbom refers to a dependency as pkg:deb/debian/[email protected]?arch=amd64&distro=debian-11.7, it would be nice if a more generic pointer in the VEX such as pkg:deb/debian/[email protected] or perhaps even pkg:deb/debian/apt would also be picked up. Even more tricky, essentially 'the same' software could be known under multiple purl types, for example both under github and under maven.

I'm curious about your thoughts on this use case!

[knqyf263]

We're glad you contacted us because we were thinking of working with software maintainers to reduce the noise. And yes, VEX is a promising approach. However, PURL in VEX is unclear now, as we are discussing here. I feel like VEX needs to be coupled with SBOM to reduce ambiguity.

Two considerations:

1. What identifiers should be used in the VEX?
   • PURL? How to compare?
   • Trivy now assumes BOM-Ref in VEX.
2. How should VEX be distributed?

If it is a container image, there is a standardized way, OCI references, to get SBOM/VEX associated with the image.
https://www.youtube.com/watch?v=fV5q2a0a1yY

Trivy is also experimenting with the ability to upload attestations to Rekor for search. It is possible to find SBOM and VEX from binary digests.
https://blog.aquasec.com/trivy-scans-unpackaged-binary-files

We are open to any suggestions you or Apache have.

[raboof]

The following diagram is what you mean, right? Let's say you are a maintainer of spring-boot-starter-web and generate VEX with SBOM. The VEX cannot be used with SBOM generated at my-project.

Exactly!

Applying the spring-boot-starter-web VEX to my-project is challenging because log4j-api could be used by other dependencies of my-project. (...) Scanners need to build the dependency graph and confirm all paths are green.

Yes, that sounds right to me. Does trivy build that dependency graph?

at present, it may be better to use only VEX issued for the target to be scanned. if users scan spring-boot-starter-web, it is easy to say the vulnerability doesn't affect spring-boot-starter-web according to the VEX document.

I agree that's where we seem to be today - but that means scanning my-project will produce a lot of false positives for dependencies that only occur in spring-boot-starter-web. It would be interesting to plot a path forward for improving that.

[raboof]

Scanners need to build the dependency graph and confirm all paths are green.

Yes, that sounds right to me. Does trivy build that dependency graph?

Ah, that might be what #3864 is about? (at least for Maven projects)

[knqyf263]

Yes, that sounds right to me. Does trivy build that dependency graph?

Yes, Trivy builds dependency graphs for most languages. Maven is not yet supported as it is a bit complicated.

but that means scanning my-project will produce a lot of false positives for dependencies that only occur in spring-boot-starter-web

BTW, how are complaints coming to you? Let's say you're a maintainer of activemq-osgi in my above example. A downstream project depends on log4j-api through activemq-osgi. Trivy shows a vulnerability of log4j-api in this case. Do they check log4j-api comes from activemq-osgi somehow, such as https://deps.dev/, and then come to you? Trivy doesn't support dependency graphs for Maven projects as of today. activemq-osgi is not shown in the result.
Or is the case you are having trouble with scanning JAR files? If activemq-osgi.jar contains log4j-api.jar, then Trivy shows the vulnerability on activemq-osgi.jar. This case should be easy to handle with VEX. If the VEX document is issued against activemq-osgi.jar like SBOM here (you can see CycloneDX), Trivy can consume it and suppress vulnerabilities.

[raboof]

how are complaints coming to you?

Right now, typically they scan an image such as apache/airflow:latest or solr:latest, so when a dependency with a vulnerability is found it's fairly likely that it's only a dependency of airflow or solr, respectively.

Of course we could publish SBOM's and associated VEX documents for those specific images (and that's definitely something that's on our roadmap), but we'd like to also accommodate users and creators of 3rd-party images that contain our projects.

[knqyf263]

Could you give me an example?

• Which vulnerability? (CVE-ID, etc.)
• Which package? (OS packages, language-specific packages)
• How is the package installed (via apt, dnf, pip, mvn, etc.)
• Which target? ( apache/airflow:latest, solr:latest, etc. )
• Why false positive?

VEX cannot address all issues for now. We need to narrow down the scope. I'd like to fully understand your case.

[raboof]

VEX cannot address all issues for now. We need to narrow down the scope. I'd like to fully understand your case.

Sure - I don't expect a quick fix, but would like to chart a longer-term plan.

Could you give me an example?

Sure! For example, scanning the solr docker image at solr:9.0.0 reports the CRITICAL CVE-2022-33980 because commons-configuration2-2.7.jar is found in /opt/solr-9.0.0/modules/hadoop-auth/lib/commons-configuration2-2.7.jar. This is a false positive in this case, because the vulnerability is triggered by loading untrusted configuration files, and Solr only uses commons-configuration2 to load trusted configuration files. This file is installed by unpacking https://archive.apache.org/dist/solr/solr/9.0.0/solr-9.0.0.tgz to /opt/solr-9.0.0.

As another example, the airflow docker image at apache/[email protected] reports CVE-2023-26302 because it found the markdown-it-py python package in /home/airflow/.local/lib/python3.7/site-packages/markdown_it_py-2.1.0.dist-info. This is a false positive in this case, since Airflow does not use the CLI interface (but the MarkdownIt Python API). I'm not too familiar with the way Airflow images are built but I imagine they are installed via npm - I can look that up if you want.

[knqyf263]

Thanks for the examples! It helped my understanding.

This file is installed by unpacking https://archive.apache.org/dist/solr/solr/9.0.0/solr-9.0.0.tgz to /opt/solr-9.0.0

Is there any way to identify /opt/solr-9.0.0/modules/hadoop-auth/lib/commons-configuration2-2.7.jar is only for org.apache.solr:solr:9.0.0? From the scanner's perspective, it must confirm two things.

1. /opt/solr-9.0.0/modules/hadoop-auth/lib/commons-configuration2-2.7.jar is originated from solr-9.0.0.
2. /opt/solr-9.0.0/modules/hadoop-auth/lib/commons-configuration2-2.7.jar is not used by anything other than solr-9.0.0.

If there is a way, you can issue VEX against org.apache.solr:solr:9.0.0 to mark CVE-2022-33980 on commons-configuration2 as a false positive, then Trivy can consume it regardless of container images.

1. Find commons-configuration2-2.7.jar in container images
2. Detect commons-configuration2-2.7.jar is installed for org.apache.solr:solr:9.0.0
3. Download VEX for org.apache.solr:solr:9.0.0 from somewhere
4. Suppress CVE-2022-33980

1,2, and 4 are easy. We need to find out the approach for 2.

[raboof]

1. /opt/solr-9.0.0/modules/hadoop-auth/lib/commons-configuration2-2.7.jar is originated from solr-9.0.0
2. /opt/solr-9.0.0/modules/hadoop-auth/lib/commons-configuration2-2.7.jar is not used by anything other than solr-9.0.0.

Is there anything we can do at image/package creation time that could help with this? In this case given the conventions around /opt (e.g. https://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES), it is a fairly safe assumption that anything under /opt/foo will be part of foo and not used by anything else.

Do you already detect /opt/solr-9.0.0 would correspond to cpe:2.3:a:apache:solr? How?

[knqyf263]

Do you already detect /opt/solr-9.0.0 would correspond to cpe:2.3:a:apache:solr? How?

Unfortunately, no. We could know /opt/solr-9.0.0/server/solr-webapp/webapp/WEB-INF/lib/solr-core-9.0.0.jar is org.apache.solr:solr-core:9.0.0, but we don't know about /opt/solr-9.0.0.

Is there anything we can do at image/package creation time that could help with this?

What if putting SBOM under /opt/solr-9.0.0? For example, Bitnami container images store SBOM under /opt/bitnami (like /opt/bitnami/elasticsearch/.spdx-elasticsearch.spdx), and Trivy can detect the elasticsearch version and relevant JAR files.
#4210

If we could determine the following hierarchy, we can easily apply VEX.

• /opt/solr-9.0.0 => org.apache.solr:solr:9.0.0
  • /opt/solr-9.0.0/modules/hadoop-auth/lib/commons-configuration2-2.7.jar => org.apache.commons:commons-configuration2:2.7

[raboof]

Is there anything we can do at image/package creation time that could help with this?

What if putting SBOM under /opt/solr-9.0.0?

That sounds like a great option, I'll look into what that'd entail. Thanks for the references!

[itaysk]

Hi @raboof , we are close to releasing "VEX Hub" which is a central repository of VEX attestations. It will allow maintainers like you to easily publish VEX statements. It will be intergrated into Trivy for automatic discovery of relevant VEX Documents. This is pre-release but we will be happy to share with you details and get feedback, and also help you (or anyone else you recomment) help getting started. If it's relevant, please reach out to me at [email protected]