Over the last few months I've spent a lot of time with the CycloneDX Maven Plugin, trying to prove it is suitable for us to use as part of securing the Software Supply Chain. I've discovered and fixed a number of issues, related to the generation of an SBOM for each project using the makeBom goal, and have now turned my focus to aggregates and the makeAggregateBom goal.

When we sign an artifact, like a blob, the signature proves that we were in possesion of the private key. When we verify, we use the signature, the public key, and the blob, and we are verifying that this was in fact the case. But it does not say anything else about the artifact, we don't know what was actually signed.

Trying to figure out what went into a binary can be a tricky thing. And once you figured it out, how do you transport this information? True, it all starts simple: Java, NodeJS, Go, or Rust, all languages¹ bring their dependency management, which defines what the final command line tool you create is made of. Or, does it?

My investigation into the CycloneDX Maven Plugin began back in November/December 2022 with the intent of integrating the plugin into the Quarkus build process to generate Software Bill of Materials (SBOMs) for the project. I quickly discovered issues in the plugin and raised these with the maintainer early in December, writing a blog post (An Adventure with the CycloneDX Maven Plugin) to help clarify each issue. I finally opened a pull request in early January to move the conversation forward and this is where our story continues .....

TUF seems to pop again and again when learning about Secure Supply-Chain Security (SSCS). The goal of this post is to get some hands-on experience with TUF, showing examples that will hopefully clarify TUF concepts, and the reason for using it in projects like Sigstore.

Yes, it is. Really? Then what format is it in and how can I tell?

I've found myself in this situation a number of times and this post tries to provide some guidelines for figuring out the type and format of keys without having to go off and read some project's documentation.

This post takes a look at Sigstore's bundle format which is the format of Sigstore's offline verification data.

Offline verification is described like this in busting-5-sigstore-myths:

As someone who was completly new to secure supply chain security (sscs) there were a lot of new projects that I learned the names of but did not really understand exactly what they did or how they complement each other. This post hopes to clarify a few of these projects, and others will be addressed in future posts.

The CycloneDX Maven Plugin can be used to generate CycloneDX Software Bill of Materials (SBOM) for your maven projects as part of your build process. The plugin is easy to integrate, however does have some issues due mostly to idiosyncrasies and shortcomings with the maven resolution mechanism. In this post I attempt to provide some background, examples and explanations for the issues I've discovered as well as context for the solutions I'm proposing.

This post contains the steps for setting up gitsign-credential-cache. which is useful if one has to perform multiple commits in short succession, or when doing a rebase.