{{ message }}
Repository navigation
Add vulnerability scanning in CI #825
Description
Add vulnerability scanning to the CI pipeline based on the generated SBOM.
Scope
- Scan SBOM build artefact for known vulnerabilities (CVE / CVSS)
- Use OSS tooling (e.g. grype, trivy, osv-scanner)
- Initial setup is report-only (no CI gating)
- Bonus: add CI gating for issues with a CVSS of 9 or higher.
tool recommendations are welcome.
Expected outcome
- CI job that performs vulnerability scanning
- Machine-readable scan output published as a CI artifact
- Short documentation describing:
- which tool is used
- what is (and is not) covered
Activity
Adarsh-Me commentedon Sep 2, 2026
Hi! I'd like to take this issue. Could a committer please assign it to me? My plan is to add a dependency/SCA scanning job (e.g. Trivy or OSV-Scanner) to the CI pipeline and triage the initial findings. Thanks!
pnoltes commentedon Sep 3, 2026
@Adarsh-Me Thanks for proposing to pick this up.
Please note that there is currently already some development for the SBOM generation. Ideally the work done for this issues, combines with that.
See SBOM PR for more details.
For the triage, any plans how?
I am still learning the SCA landspace, but I expect a first low threshold solution could be to configure a VEX (cyclonedx or open vex) file in our SCM. This should work for triage on the main development branch, but to be honest I am not yet sure how this could work for already released Apache Celix versions. But maybe we can start small, and if needed create additional issues to improve the solution.
I also expect we can learn this from other ASF projects.
Adarsh-Me commentedon Sep 29, 2026
@pnoltes sorry for the silence. Plan: a report-only
vulnerability-scan.ymlthat downloads yourcelix-conan-safe-defaultsartifact and scanssbom/sbom-cyclonedx-1.6.jsonwith Trivy, publishing JSON + SARIF as CI artifacts and no gating; CVSS≥9 gating as a follow-up once the first findings are triaged in-repo. Question: should I base the PR on #845, since it needs that artifact, or wait until #845 merges?Adarsh-Me commentedon Oct 2, 2026
@pnoltes triage plan: keep the decisions in-repo as a CycloneDX VEX file with
not_affected+ justification per CVE, so each scan is diffed against it instead of re-triaged by hand. And a correction to my own plan: Trivy can scan the checkout directly (trivy fs), so #825 need not wait on #845's SBOM artifact. Report-only plus SARIF to code scanning first, gating later.mcc0nnell commentedon Oct 2, 2026
I think the VEX/report-only approach makes sense, and #825 probably should not have to wait for #845.
One thought: once #845 is available, I would still use its SBOM as the canonical Conan input.
trivy fsis useful in the meantime and probably worth keeping as an additional check, but it is not quite the same thing as scanning the exact graph resolved byconan/safe-defaults.lock.So something like:
#845 Conan baseline -> SBOM -> #825 scan -> VEX triageThat lets #825 move now without creating a second definition of the Conan security baseline.
apacheGH-825: use Trivy's documented --skip-dirs flag
apacheGH-825: print a coverage digest so scan coverage is measurable
apacheGH-825: drop a log file committed by mistake
apacheGH-825: drop second stray log file
Adarsh-Me commentedon Oct 2, 2026
@pnoltes @mcc0nnell measurement against my own claim:
trivy fsonmasterfinds nothing to scan. I ran the scheduled job on a fork with Trivy 0.75.0 — results=0, findings=0, no targets; there is noconan.lockin-tree, so no resolved graph to scan. #825 does depend on #845; your ordering is the workable one. Correcting my 09:54Z comment.pnoltes commentedon Oct 4, 2026
@Adarsh-Me: There is some discussion going on with #845, but if that PR goes through, I agree it would be the logical starting point.
I did not realize SARIF could also be used for dependency vulnerability findings. My understanding was that SARIF is mainly associated with SAST/code analysis, but apparently Trivy supports SARIF output (
--format sarif). I am not sure how well this works in practice, but I think it is worth testing.I had a quick search on GitHub, but could not yet find a working example that uploads a Trivy-generated SARIF file. If anybody knows one, I would appreciate a link.
For VEX, I am also not sure yet which format would be best (CycloneDX VEX or OpenVEX), or where we should store it. Keeping it in Git seems reasonable, but then we should think about how VEX information on main relates to already released Celix versions.
If needed, work on this issue can already start using a dummy CycloneDX SBOM as input. Once #845 is merged, that dummy input can be removed.
Adarsh-Me commentedon Oct 7, 2026
@pnoltes yes - SARIF is not code-only: it is a generic findings envelope, and Trivy's
--format sarifcovers vulnerability results (its docs matrix lists vuln/misconfig/secret/license). One caveat from SECURITY.md: I would keep output artifact-only rather than upload to the security tab, since an undisclosed flaw must not be published. Agreed that #845 is the input here.