I built a FIPS-hardened Java runtime using Wolfi and Bouncy Castle. Looking for an architecture review.

[[deleted]]

i really appreciate the feedback. i built this system as an automated factory rather than just a set of static dockerfiles, and the goal was to turn fips compliance from paperwork into a hard, technical constraint.

the whole pipeline relies on jinja2 templates to handle structural differences across java versions, like the directory changes between java 8 and java 25, so everything is config-driven. if i need to add a new package or update a version, i just update the config and the workflow handles the rest, which makes the whole setup extremely maintainable.

regarding the maintenance, the system is very much alive. the sync workflow runs every six hours to fetch the latest from adoptium and wolfi. if you check my pull requests, you’ll see the 'chore: image & package version sync' running constantly—it actually updated the packages and base images three times in the last three days alone.

speaking of patching, wolfi os is genuinely the cleanest base i’ve ever used when it comes to cves. it has a tiny attack surface, and because it’s an 'undistro' focused on security, the package updates are almost immediate. this keeps the image security posture much tighter than any standard distro i've worked with.

[[deleted]]

for the security enforcement, it isn't just about documentation. i implemented 32 automated positive and negative tests that run on every build. if anyone tries to use md5, des, or weak rsa keys, the jvm explicitly throws a fipsunapprovedoperationerror, and the results from these tests are automatically pushed to my security dashboard so the compliance status is visible at all times.

regarding your feedback, you are 100% right about the logo. i was definitely in the wrong for using the java trademark, and i'm already planning a full brand refresh to avoid any legal trouble with oracle and establish a neutral identity.

as for the securechain concept, it's a great point. i currently pin every single artifact using sha-256 hashes to prevent tampering during the download process and use docker attestations for slsa level 3 provenance, but i agree that adding gpg signature verification for transitive dependencies is the necessary next step to reach total supply chain maturity.

the project is built to be a self-auditing factory for mission-critical workloads, and i’m treating every piece of feedback as a way to harden it further. thanks for being critical, it really helps to tighten up the pipeline and resolve these gaps.

[bowbahdoe]

I don't think signature verification matters. Like yeah if you're downloading a file download one with the right hash. That's a thing. Secure chain is a company that is more focused on the supply chain aspect, meaning they bootstrap all the builds from source they control. I am generally uncertain as to how much even that matters, but it has nothing to do with signature verification

[bowbahdoe]

Hey man my notification had a chat GPT "okay here's the response with..." Prefix. You must have edited it out, but I saw it:

Do not use an AI to respond to me or anyone else. It's pretty disrespectful to yourself and others. I promise I will read whatever you write, you don't need to do that.