I agree that if the CVE scan is a requirement for publishing, we should incorporate it into the CI/release process.
However, I've run into situations in the past where CVE scanners flags things that do not apply and create friction during release. How do we ensure that this doesn't become a problem for CI (looks like it's report only right now, so a new CVE doesn't start failing all builds) and how do we prevent releasing with CVEs that would then block publishing the artifacts. Is this all manual at this point (release manager needs to validate CVEs)? I'm just trying to understand what this workflow will look like in practice. -Dan On Tue, Feb 24, 2026 at 6:45 AM Robin Moffatt via dev < [email protected]> wrote: > I've raised a second PR [1] that adds a trivy step to the existing Kafka > Connect workflow [2]. > This would flag CVEs both during PR CI (catching vulnerabilities in > current dependencies) and when a release candidate tag is created (catching > newly-disclosed CVEs against previously merged code). > > This PR and the previous one [3] are related but not dependent on each > other. > > thanks, Robin. > > [1]: https://github.com/apache/iceberg/pull/15430 > [2]: > https://github.com/apache/iceberg/blob/main/.github/workflows/kafka-connect-ci.yml > [3]: https://github.com/apache/iceberg/pull/15212 > > On Fri, 20 Feb 2026 at 15:02, Kevin Liu <[email protected]> wrote: > >> Sounds like a good idea to incorporate trivy. There are other apache >> projects using trivy as part of their build/publish step for docker >> containers. Heres one from apache/superset, >> https://github.com/apache/superset/blob/9f8b212ccc75308d019338fab642489bda00af3d/.github/workflows/docker.yml#L104-L119 >> >> We can emulate that in our pipeline >> >> On Fri, Feb 20, 2026 at 2:29 AM Robin Moffatt via dev < >> [email protected]> wrote: >> >>> Hi Dan, >>> Thanks for the review on the PR. >>> >>> One thing that's come up internally is that the Confluent team use trivy >>> [1] to scan for CVEs as a mandatory step before listing a connector. This >>> has flagged CVEs previously (e.g. [2]) that needed patching. >>> >>> Can you suggest what the best way to incorporate this into the release >>> workflow might be? >>> As it stands, it's only the finalised release that's sent to Confluent >>> and then scanned; should the trivy step be further upstream in the release >>> process so that CVEs are patched before the final release is made? >>> >>> thanks, Robin. >>> >>> [1] https://trivy.dev/ >>> [2] https://github.com/apache/iceberg/pull/14985 >>> >>> On Thu, 19 Feb 2026 at 01:07, Daniel Weeks <[email protected]> wrote: >>> >>>> I'll take a look tomorrow. This would be great to land and validate >>>> with the 1.11 release. >>>> >>>> -Dan >>>> >>>> On Mon, Feb 16, 2026, 4:24 AM Robin Moffatt <[email protected]> wrote: >>>> >>>>> Hi Dan, >>>>> I've addressed your comments on the PR, could you take another look >>>>> please? >>>>> >>>>> Thanks, Robin >>>>> >>>>> On Fri, 6 Feb 2026 at 19:29, Daniel Weeks <[email protected]> wrote: >>>>> >>>>>> Hey Robin, >>>>>> >>>>>> Sorry for not responding to the last email, but this looks like the >>>>>> right approach. A couple small comments on the PR, but other than that >>>>>> this looks good. >>>>>> >>>>>> -Dan >>>>>> >>>>>> On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> I've reworked the process based on the feedback into: >>>>>>> 1. Add the Kafka Connect artifact to maven as part of gradle release >>>>>>> 2. The version from Maven is what gets sent to Confluent Hub >>>>>>> >>>>>>> Please take a look: https://github.com/apache/iceberg/pull/15212 >>>>>>> >>>>>>> thanks, Robin. >>>>>>> >>>>>>> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Daniel, >>>>>>>> >>>>>>>> I appreciate your input and guidance. I'd definitely missed the >>>>>>>> released artifacts and provenance angle here. >>>>>>>> >>>>>>>> So would the right direction here be to include the Kafka Connect >>>>>>>> artifact as part of the gradle release command? >>>>>>>> Then once the release has passed, the artifact on maven can be >>>>>>>> submitted to Confluent Hub directly by the release manager. >>>>>>>> >>>>>>>> If this sounds right I'm happy to put together a PR for it. >>>>>>>> >>>>>>>> thanks, Robin >>>>>>>> >>>>>>>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I added some comments to this effect in the PR, but it's probably >>>>>>>>> good to highlight this here. >>>>>>>>> >>>>>>>>> I don't think we should be generating new artifacts to upload to >>>>>>>>> connect/hub, but rather referencing the voted and released artifacts >>>>>>>>> that >>>>>>>>> are part of the release process. >>>>>>>>> >>>>>>>>> It might be good to include the instructions on how this fits into >>>>>>>>> the release process <https://iceberg.apache.org/how-to-release/> >>>>>>>>> so we understand the full workflow along with the script. >>>>>>>>> >>>>>>>>> -Dan >>>>>>>>> >>>>>>>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Could I ask for input on this please, or a review of the PR[1]? >>>>>>>>>> >>>>>>>>>> thanks, Robin. >>>>>>>>>> >>>>>>>>>> [1] https://github.com/apache/iceberg/pull/15113 >>>>>>>>>> >>>>>>>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Currently, the version of the Iceberg connector for Kafka >>>>>>>>>>> Connect on Confluent Hub is outdated (1.9.2). Confluent staff >>>>>>>>>>> manually >>>>>>>>>>> uploaded it through an ad-hoc process, which we would like to help >>>>>>>>>>> the Apache Iceberg community formalise. >>>>>>>>>>> Previously, Tabular owned the connector, and its inclusion >>>>>>>>>>> in Confluent Hub was managed through the commercial partnership >>>>>>>>>>> between the >>>>>>>>>>> two companies. >>>>>>>>>>> >>>>>>>>>>> I've put together a draft PR [1] with a script that builds and >>>>>>>>>>> packages the connector for submission to Confluent Hub [2] (now >>>>>>>>>>> called >>>>>>>>>>> Confluent Marketplace). >>>>>>>>>>> >>>>>>>>>>> Please review the PR's proposed process, and let me know what >>>>>>>>>>> you think. I'm happy to liaise between the community and the >>>>>>>>>>> Confluent team >>>>>>>>>>> here to find a process that works for everyone. >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> Robin >>>>>>>>>>> >>>>>>>>>>> 1: https://github.com/apache/iceberg/pull/15113 >>>>>>>>>>> 2: https://hub.confluent.io >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> > > -- > *Robin Moffatt* > *Sr. Principal Advisor, Streaming Data Technologies* >
