[I] Catalog dependency scan: advisories against pinned artifacts [camel-kamelets]

["github-actions[bot] (via GitHub)" <gi...@apache.org>]

github-actions[bot] opened a new issue, #3054:
URL: https://github.com/apache/camel-kamelets/issues/3054

   ## Artifacts the catalog pins (17)
   
   Each version below is pinned in `spec.dependencies` of the Kamelets named, so bumping one is a change to this repository.
   
   | artifact | version | advisory | severity | declared by |
   |---|---|---|---|---|
   | `net.snowflake:snowflake-jdbc` | `3.24.2` | [GHSA-gx6c-pv62-9mcf](https://osv.dev/vulnerability/GHSA-gx6c-pv62-9mcf) (CVE-2026-3293) | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L | snowflake-sink,snowflake-source |
   
   ## Camel components (115), scanned at 4.22.1
   
   No known advisories.
   
   
   Raised by the `Catalog Dependency Scan` workflow, which reads
   `camel-kamelets-sbom/camel-kamelets-catalog-sbom.json` and queries https://osv.dev.
   Artifacts the catalog pins are fixed by editing the Kamelet. Camel components are
   versioned by the runtime, so they are scanned at the newest Camel release and an
   advisory there is addressed by moving Camel rather than by changing this catalog.
   


-- 
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: commits-unsubscribe@camel.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Catalog dependency scan: advisories against pinned artifacts [camel-kamelets]

["oscerd (via GitHub)" <gi...@apache.org>]

oscerd commented on issue #3054:
URL: https://github.com/apache/camel-kamelets/issues/3054#issuecomment-5756981135

   Looked into what fixing this would take. **It is not a version bump, and I would not apply one blind.**
   
   ## No 3.x is clean
   
   The advisory lists 189 affected versions. The highest affected is `4.0.1`, and `4.1.0` onwards are clean:
   
   ```
   3.24.2  -> GHSA-gx6c-pv62-9mcf     (what we pin)
   3.28.0  -> GHSA-gx6c-pv62-9mcf     (newest 3.x on Central)
   4.0.1   -> GHSA-gx6c-pv62-9mcf
   4.1.0   -> clean
   4.3.4   -> clean                   (current release)
   ```
   
   So staying on 3.x is not an option; the fix is a major version move.
   
   ## 4.x moves the class both Kamelets depend on
   
   `snowflake-sink` and `snowflake-source` create their DataSource bean like this:
   
   ```yaml
   - name: dsBean
     type: "#class:net.snowflake.client.jdbc.SnowflakeBasicDataSource"
     properties:
       user: '{{username}}'
       password: '{{password}}'
       url: 'jdbc:snowflake://{{instanceUrl}}'
       databaseName: '{{?databaseName}}'
   ```
   
   In 4.3.4 that class **is not there**. The 4.x line is a deliberate API restructuring:
   
   - `net/snowflake/client/jdbc/` now contains exactly one public class, `SnowflakeDriver`
   - the public DataSource is `net.snowflake.client.api.datasource.SnowflakeDataSource`, and it is an **interface**, so `#class:` cannot instantiate it
   - instances come from `net.snowflake.client.api.datasource.SnowflakeDataSourceFactory`
   - the old `SnowflakeBasicDataSource` still exists, but as `net.snowflake.client.internal.api.implementation.datasource.SnowflakeBasicDataSource`, which is explicitly internal
   
   The setters the templates rely on (`setUser`, `setPassword`, `setUrl`, `setDatabaseName`) do survive on the new interface, so the shape of the configuration is unchanged. What changes is how the bean is obtained, and no Kamelet in this catalog currently creates a bean through a factory method.
   
   The Java baseline is not a problem: 4.3.4 still ships Java 8 bytecode.
   
   ## Why I stopped rather than pushing a change
   
   A bump to 4.x would need the bean block reworked in two Kamelets, and **there are no Citrus tests for snowflake** — verifying it needs a real Snowflake account, which is not something CI has. Shipping an untested rewrite of both Kamelets to chase this particular advisory looks like a poor trade:
   
   `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L` — local, no confidentiality or integrity impact, availability only, and it goes through `SdkProxyRoutePlanner`, so it is reachable only where a proxy is configured.
   
   ## Options, for someone who can test this
   
   1. Rework both Kamelets onto `SnowflakeDataSourceFactory` and bump to 4.3.4. Correct, and needs an account to verify.
   2. Leave the pin and record the decision, given the severity and the reachability. The scanner will keep reporting it, which is arguably the right outcome for a known-and-accepted risk.
   3. Add the advisory to `camel-kamelets-sbom.vex.json` as not-affected-with-justification, if the proxy path is genuinely unreachable for these Kamelets. That is what the VEX file next to the SBOM is for, and it would stop the weekly noise without hiding anything.
   
   I have not assigned this to myself; option 1 wants hands that can run against Snowflake.
   
   ---
   _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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Catalog dependency scan: advisories against pinned artifacts [camel-kamelets]

["oscerd (via GitHub)" <gi...@apache.org>]

oscerd closed issue #3054: Catalog dependency scan: advisories against pinned artifacts
URL: https://github.com/apache/camel-kamelets/issues/3054


-- 
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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org