oscerd opened a new pull request, #3050: URL: https://github.com/apache/camel-kamelets/pull/3050
Addresses the half of #558 that belongs in this repository. ## Splitting the issue The report fused two questions. **Container scanning** of a Camel K image is not something this catalog can own — a Kamelet runs under JBang, Quarkus, Spring Boot or Camel K, so there is no single image, and Trivy or Clair already cover whatever image an operator builds. **"Scanning the dependencies directly from the Kamelet without building the container"** is the other question in the report, and it is the one @oscerd redirected towards in 2022: *"it's not only within containers, but in multiple runtimes"*. That is runtime-agnostic and it is in scope here. ## What the catalog actually controls 864 dependency entries across 262 Kamelets: - **809 `camel:<component>`** over 115 components. The runtime picks their version, so an advisory against one belongs to the Camel release in use. - **55 `mvn:` entries → 17 distinct coordinates, version-pinned by the catalog itself**, e.g. `snowflake-jdbc`, `redshift-jdbc42`, `artemis-jakarta-client-all`, `postgresql`, `apicurio-registry-serdes-avro-serde`. **Nothing watches those 17.** `dependabot.yml` configures the `maven` ecosystem at the root, which parses poms; these versions live inside YAML strings. I checked every historical change to an `mvn:` line — all hand-made by a committer, never a bot. And the existing SBOM does not cover them: `cyclonedx-maven-plugin` aggregates the Maven reactor, so its 125 components are `io.fabric8` (27), `io.sundr` (12), `org.apache.maven` (11), `org.codehaus.plexus` (7) — what builds the catalog, not what a Kamelet pulls in. It also carries no `vulnerabilities` section. ## What this adds **`generate-catalog-sbom`**, a third goal on the existing plugin, writes `camel-kamelets-sbom/camel-kamelets-catalog-sbom.json`: a CycloneDX 1.6 document listing the 17 pinned artifacts, each with a `camel.apache.org/declared-by` property naming the Kamelets that declare it. Separate file from the existing SBOM so the weekly job does not fight it. No timestamp and no serial number, deliberately — the file is committed, so it should change only when the dependencies do. Verified byte-stable across consecutive builds. **`script/security/scan_catalog_dependencies.py`** reads that document and asks OSV about each exact version. No API key, no build, no container. **`Catalog Dependency Scan`** runs it Mondays, away from the Sunday SBOM cron, and files or comments on a *single* issue so a finding that persists across weeks does not open a new issue every Monday. `camel:` dependencies are excluded from both by design, so advisories against a Camel release are not attributed to this catalog. ## Checks ``` mvn clean install BUILD SUCCESS, KameletsCatalogTest 18/18 catalog validation 262 kamelets, no errors catalog sbom 17 pinned artifacts, byte-stable across runs scanner, no-findings input exit 0 scanner, real catalog exit 1, report rendered ``` The scanner's exit contract is what the workflow branches on: `0` nothing found, `1` findings, `2` OSV unreachable — the last fails the run rather than reporting a false all-clear. I also checked the labels it applies (`dependencies`, `automated pr`) actually exist in this repository, since a missing label would fail the step. ## Still open, for a maintainer The security model says transitive-dependency CVEs "not caused by the template" are out of scope. A stale `mvn:` pin is arguably *caused by* the template, since the catalog chose that version. A sentence either way would settle whether a report about one of these 17 is triaged here or redirected. --- _Claude Code on behalf of Andrea Cosentino_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
