All articles
forge simple-container supply-chain 4 min read

Everyone's asking if you can trust AI-written code. Here's our answer: OpenSSF Gold.

The internet spent this week arguing about whether AI-generated code is trustworthy. The honest answer isn't a vibe — it's verifiable engineering. Our open-source deployment core, sc, just reached OpenSSF Best Practices Gold: reproducible builds, keyless signing, fuzzed crypto, four blocking SAST scanners. Click the badge.

by Dmitry Creed

On June 21, a Show HN author got ahead of the comments before they could land: their project, they wrote, isn’t “vibe-coding garbage” — it ships with “429 unit tests, 33 migrations, full CI/CD with E2E tests, stress testing, and failure injection,” plus Trivy, Grype and OpenSCAP scanning and a quarantine policy engine for anything that doesn’t pass. The same week, The Mog Programming Language hit the front page on a single premise — capability-based security for code an agent wrote, because “if you run scripts the agent wrote, those scripts don’t inherit the permissions that constrain the agent… which leads to pwnage.” And TesterArmy launched arguing the bottleneck has moved: “AI coding tools made it dramatically faster to ship code, but testing is still the bottleneck… they just want confidence that their core flows work.”

Read enough of these and the 2026 question is clear, and it isn’t “can AI write code?” It obviously can. The question is: can you trust what it wrote?

Our answer isn’t a promise or a vibe. It’s a badge you can click. The public open-source core that Forge deploys onto your cloud — sc, Simple Container — just reached OpenSSF Best Practices Gold . Every single criterion reads Met. The badge flipped to Gold on June 21.

Trust isn’t a feeling. It’s a checklist someone else grades.

The OpenSSF Best Practices badge exists precisely because “we take security seriously” is meaningless. It’s a public, independently-defined rubric run by the Open Source Security Foundation, in three tiers — Passing, Silver, and Gold — and Gold is the one almost nobody reaches, because it demands things that are genuinely hard to fake. You don’t self-certify into trust; you meet the criteria, line by line, and the grade is machine-readable so anyone can audit it.

That’s the difference between “trust me” and “verify me.” When the whole industry is nervous about provenance, a third-party rubric that says all criteria met is worth more than any amount of marketing copy — including this paragraph. So here’s what’s actually behind the badge.

1. Reproducible builds: the binary you get is the source you read

The deepest supply-chain fear is that the artifact you run isn’t the source you audited. sc closes that gap with bit-for-bit reproducible builds: release binaries are built with -trimpath, -buildvcs=false, CGO_ENABLED=0 and a pinned Go toolchain, and the tarballs are packed deterministically (fixed order, mtime, owner and mode, no embedded gzip timestamp). Two independent builds under different umasks produced identical sha256 digests, and the rebuild-and-compare recipe is published so you can verify it yourself against the released digest. You don’t have to trust our build server. You can rebuild it.

2. Keyless signing + fuzzed crypto: the parts attackers actually target

Releases are signed with Sigstore/cosign using GitHub OIDC keyless signing — no long-lived secret key to leak, with the identity verified at install time by the sc.sh bootstrap. And the security-critical code gets dynamic analysis, not just a code review: native Go fuzzing runs in CI against the HMAC integrity-cache parse path, with harnesses that assert forged or tampered input is rejected and that no resolved path can escape the cache directory. The crypto isn’t homegrown either — HMAC-SHA256, RSA-OAEP, ed25519 + ChaCha20-Poly1305, HKDF, TLS 1.3 — with zero SHA-1, MD5 or InsecureSkipVerify anywhere in production code.

3. Four blocking SAST scanners and a no-silent-suppression rule

Every pull request runs four FLOSS static analyzers — CodeQL, Semgrep, gosec and govulncheck — and each one blocks the merge on a finding. There’s no “warning, don’t fail” tier; golangci-lint runs strict, and any warning fails the build. The detail we’re proudest of is the suppression policy: you can’t quietly silence a finding with # nosemgrep, // nolint or a .trivyignore — those are banned. The only way to suppress is a documented OpenVEX not_affected entry that says, in the open, exactly why. Plus ≥90% statement coverage on a documented scope, and a SECURITY.md with acknowledgement and fix SLAs.

The takeaway

Here’s why this matters beyond a badge. Forge is a platform where AI agents write code and ship it to your cloud — so we are, very directly, in the “can you trust agent-driven software?” business. We can’t credibly answer that question for your code if we can’t answer it for our own. So we held the open-source core that does the actual deploying to the highest public bar there is, and we let a third party grade it.

The industry’s anxiety is the right anxiety. Speed without verifiable rigor is how you ship a supply-chain incident. The fix isn’t to slow the agents down — it’s to put the rigor into the pipeline so trust is a property of the artifact, not a leap of faith. Reproducible, signed, fuzzed, scanned, graded Gold.

Don’t take our word for it. Click the badge — then read the source .