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*
