| Summary: | spdx 3.0.1: Missing internal dependencies: example Go blindspot for CVE scanner | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Robert Berger <pokylinux> | ||||
| Component: | oe-core other | Assignee: | Joshua Watt <JPEWhacker> | ||||
| Status: | NEW --- | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium+ | CC: | ccasciato, randy.macleod, romain.naour | ||||
| Version: | 6.1 | ||||||
| Target Milestone: | 6.2 M2 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | Don't know | |||||
| Attachments: |
|
||||||
|
Description
Robert Berger
2026-09-26 09:26:21 UTC
The dependent go modules should be present in the SPDX output as input packages to the build. I believe the thing that is missing is: 1) I'm not sure if these go modules have PURLs assigned to them. I don't know if this is possible to do, but we can investigate that further 2) The PURLs from things in SRC_URI do not automatically propagate down the the packages that are built using those SRC_URIs. We might be able to improve that also bitbake virtual/robertberger-go-hello -c sbom_cve_check_recipe
returns this:
WARNING: github.com-robertberger-go-hello-vuln-git-r0 do_sbom_cve_check_recipe: binutils-cross-aarch64-2.47: Found unpatched CVEs: CVE-2026-3441, CVE-2026-3442, CVE-2026-6844, CVE-2026-6845, CVE-2026-90801, CVE-2026-90802, CVE-2026-90803, CVE-2026-90804, CVE-2026-90828, CVE-2026-90829, CVE-2026-90830, CVE-2026-90831, CVE-2026-91779, CVE-2026-91780, CVE-2026-91781, CVE-2026-91782
WARNING: github.com-robertberger-go-hello-vuln-git-r0 do_sbom_cve_check_recipe: bison-native-3.8.2: Found unpatched CVEs: CVE-2026-56390
WARNING: github.com-robertberger-go-hello-vuln-git-r0 do_sbom_cve_check_recipe: glibc-2.44+git: Found unpatched CVEs: CVE-2026-18374, CVE-2026-19499, CVE-2026-19542, CVE-2026-77117, CVE-2026-80489, CVE-2026-8674, CVE-2026-86805, CVE-2026-89092, CVE-2026-95818, CVE-2026-97399
WARNING: github.com-robertberger-go-hello-vuln-git-r0 do_sbom_cve_check_recipe: popt-native-1.19: Found unpatched CVEs: CVE-2026-18739, CVE-2026-18743, CVE-2026-18839
WARNING: github.com-robertberger-go-hello-vuln-git-r0 do_sbom_cve_check_recipe: zlib-native-1.3.2: Found unpatched CVEs: CVE-2026-76844, CVE-2026-85091
which means it does not care about the go version used.
trivy scan returns a lot of CVEs due to the go version and the go stdlib.
tree github.com-robertberger-go-hello-vuln
github.com-robertberger-go-hello-vuln
├── aarch64
│ ├── builds
│ │ └── build-github.com-robertberger-go-hello-vuln.spdx.json
│ ├── common-package
│ │ └── github.com-robertberger-go-hello-vuln-package-common.spdx.json
│ ├── packages
│ │ ├── package-github.com-robertberger-go-hello-vuln-dbg.spdx.json
│ │ ├── package-github.com-robertberger-go-hello-vuln-dev.spdx.json
│ │ └── package-github.com-robertberger-go-hello-vuln.spdx.json
│ ├── packages-staging
│ │ ├── package-github.com-robertberger-go-hello-vuln-dbg.spdx.json
│ │ ├── package-github.com-robertberger-go-hello-vuln-dev.spdx.json
│ │ └── package-github.com-robertberger-go-hello-vuln.spdx.json
│ └── static
│ └── static-github.com-robertberger-go-hello-vuln.spdx.json
├── src
│ ├── go.mod
│ ├── main.go
│ └── readme.txt
└── trivy-scan
└── github.com-robertberger-go-hello-vuln-src-vuln.json
under aarch64: our generated spdx
under src: what trivy uses for scanning
under trivy-scan: the output of the scan
I'll attach a tarball with this info.
Created attachment 5251 [details]
spdx, try vuln report, sources
Maybe this helps?
Hello, Thanks for the detailed report! I noticed a similar issue for a custom npm package using a npm-shrinkwrap.json (npmsw fetcher). The generated SPDX 3.0.1 sbom doesn't list any dependencies listed in the npm-shrinkwrap.json while external sbom tool (cdxgen) list several vulnerabilities. The sbom only contains the "software_packageUrl": "pkg:npm/<custom_pkg>" for the main custom package. But there is no `pkg:npm/...` entries related to the "sub-module" list of npm packages from npm-shrinkwrap.json. I'm agree with the analysis: "It also applies to many more use cases like go, rust, npm, python where dependencies are pulled in by the recipe." Also, when a vulnerability for such "sub-module" is added to the SBOM, the sbom-cve-check should be able to know if it has been fixed or not. How to distinguish a patch fixing a CVE for a "sub-module" or the main package? Best regards, Romain @Romain Naour: I think npm shrinkwrap is disabled in recent Yocto versions due to security concerns. Nevertheless you can still use the standard fetcher to use npm packages with "internal dependencies" which are not seen by the current design of OE/YP. One solution I am playing with is to use use a 3rd party scanner like trivy and let it run over parts of the sources (lock files,...). It looks like this can detect such issues. If you want to play with my bbclass I can send it over. It's not yet in my public layers. It will eventually be here[1] [1] https://gitlab.com/meta-layers/meta-resy/-/tree/master/classes?ref_type=heads |