Re: SBOM for Ant

Hello Stefan,

On 11/11/25 11:09 am, Stefan Bodewig wrote:
> Hi all
>
> I'd like to publish SBOMs[1] for our releases and looked around a
> bit.

I believe having a SBOM for the Ant distribution is a good thing, I'm 
glad to see this work.


> Since we don't use any proper kind of dependency management for our
> own build, the options I've looked at are all, erm, unsatisfying.
>
> ## Use Maven Plugin
>
> An option that would get us pretty far without too much work could be to
> add the CycloneDX Maven Plugin[2] to src/etc/poms - the aggregateBom it
> would generate for the parent POM might be a good starting point for a
> CycloneDX file for our traditional tar/zip distribution (and maybe the
> snap as well, haven't looked into that, yet).
>
> Apart from making mvn required as part of the release process (which I
> absolutely could live with)

Requiring Maven as part of the release process is fine with me too.


> the main problem seems to be the checksums
> for the Ant jars that become part of the SBOM. These checksums are
> generated from the jars built by Maven, which are not identical to the
> ones generated by Ant.

Do you know what those differences are? Perhaps Maven generates 
different content in the JAR file's MANIFEST.MF, which is 
understandable. Do you know if this Maven plugin can be instructed to 
use the Ant built JAR files?


> ## Use Maven Plugin for templates and filter magic
>
> So if the hashes were the main problem, one option could be to generate
> CycloneDX template files we'd commit to git with placeholders for Ant's
> version and checksum hashes. Our release process already copies the POMs
> and replaces the version number, it could also copy SBOM templates and
> replace version numbers and hashes.
>
> This would require us to re-generate the templates whenever we update
> dependencies, but that doesn't happen often.
>
> We'd also have to check the jars in lib/optional we build against
> actually are the ones we claim to have used (i.e. verify their hashes, I
> guess). This probably is true anyway, no matter which option we'd use.

I haven't checked what these templates are, so I will have to read up a 
bit on that.


> ## Write an ad-hoc Ant task that generates SBOMs
>
> It doesn't seem to be extremely difficult to use cyclonedx-core-java[3]
> to generate the files, but would require some ad-hoc model of
> dependencies - and metadata for dependencies we currently don't track at
> all.

Given what we are doing in context of SBOMs, the dependency management 
is a crucial part of it. Trying to do that in Ant and continuing to 
maintain that model of dependencies, I think, is going to be difficult 
as well as wasted efforts (and likely error prone).


> ## Write an Ant task that generates SBOMs based on ivy.xml
>
> Again, seems doable, but I'm not really convinced I want to do this. I'm
> not sure how well Ivy is suited as a library (I never tried).
>
> Our current ivy.xml is only used for publishing and doesn't declare any
> dependencies at all.

I would avoid this approach too.


> ## Other options I haven't thought of
>
> input more than welcome

I think using the Maven plugin would be the best path forward. If it 
means having to adjust our release process (maybe let Maven generate the 
JAR files for the SBOM generation as well as our final release 
distributions?), then I think that can be considered too, depending on 
how involved it becomes.

-Jaikiran