SPDX output format and vuln scanner

[goneall]

Question

I noticed that when I try to run trivy with --output spdx-json and --scanners vuln I get the following message:

"--format spdx" and "--format spdx-json" disable security scanning

A couple of questions:

• Is vuln scanning actually disabled as the message suggests?
• What is the reason for disabling vuln scanning when outputting to SPDX?

I'm relatively new to Trivy and haven't had much experience with the vuln scanner, but I was thinking vulnerabilities could be reported as external references per the how to use annex.

I can move this over to the new feature discussion if it is more appropriate.

I'm not a Go programmer, so I can't help much with the implementation, but I can provide help on the SPDX format.

Target

None

Scanner

Vulnerability

Output Format

SPDX

Mode

Standalone

Operating System

Docker image

Version

Version: 0.49.1
Vulnerability DB:
  Version: 2
  UpdatedAt: 2024-03-12 18:11:44.883502428 +0000 UTC
  NextUpdate: 2024-03-13 00:11:44.883502148 +0000 UTC
  DownloadedAt: 2024-03-12 19:09:55.2745624 +0000 UTC

[DmitriyLewen]

Hello @goneall
Thanks for your interest to Trivy!

Is vuln scanning actually disabled as the message suggests?

You are right. Trivy only detects packages and inserts them into SPDX format (without vulnerability checking).

What is the reason for disabling vuln scanning when outputting to SPDX?

In version 2.2 there were no instructions for inserting advisories into the SPDX format.
And it looks like we missed Annex K after updating to 2.3

externalRefs doesn't support parts of information (e.g. we can't insert fixed version, severity).
But it is better than nothing.
@knqyf263 wdhy? I think we can think about using externalRefs for advisories (as docs say - https://spdx.github.io/spdx-spec/v2.3/how-to-use/#k11-linking-to-an-advisory)

[knqyf263]

@goneall I was looking into this repository, but didn't find so much examples for SPDX 3.0 other than this one, which doesn't contain vulnerabilities. Can we find any examples somewhere else?

[DmitriyLewen]

If v3.0 is easy to migrate, I'd go with option 2.

scheme has been greatly changed.
Also github.com/spdx/tools-golang team is still thinking about a better 3.0 implementation - spdx/tools-golang#240.

Looks like migration to 3.0 will take quite some time
So I think we are forced to choose option 1.

[goneall]

@knqyf263 We're actively working on adding SPDX 3.0 examples to the examples repo, in the interim, you can find examples in the spec itself for vulnerabilities - there have been some recent updates for the upcoming 3.0.1 patch release, so I would suggest looking at the in development SPDX Spec 3 model security profile

[knqyf263]

OK. SPDX 3.0 seems to be too cutting-edge. Let's add vulnerabilities to v2.3.
@DmitriyLewen Can you please convert it to an issue?

[DmitriyLewen]

#7211

[goneall]

Agree with @DmitriyLewen - SPDX 3 is a significant change and the golang tools are still being updated. For the Linux Foundation project, we're targeting SPDX 2.3 in the short term then updating to 3.0 after the 3.0.1 patch release.

[knqyf263]

Thanks for your input. We'd go for SPDX 2.3 for now.

[goneall]

Thanks @knqyf263 and @DmitriyLewen for the quick responses and follow-up questions :)

[DmitriyLewen]

Track #7211