Building a Signed Software Supply Chain for a One-Person SaaS

Every commit to my SaaS is now signed by a short-lived certificate, every release is signed by the CI workflow's own identity, and production refuses to run anything it cannot verify. Here is how I built it on a small budget, and what it found when I pointed security scanners at my own code.

Why build this

Stokum.NET is a multi-tenant inventory platform I develop alone. A one-person team has the same supply-chain risks as a large one: a stolen laptop, a leaked token, a poisoned dependency or a compromised CI runner can each put malicious code in front of customers. What a solo developer lacks is the second reviewer, the security team and the budget.

So I set five goals:

1. Integrity: know exactly what runs in production, who wrote it and who built it, from commit to deploy.
2. Shift left: find vulnerabilities in the pull request, not in production.
3. Containment: a compromise of one part, such as the CI runner, must not reach the signing services or production.
4. Auditability: every security-relevant event lands in one central log, with alerts.
5. Enterprise controls on a small budget: run the same controls a large AppSec program would, on self-hosted open-source tools.

Before adding any scanner, I audited my own infrastructure. That story is in Configuration isn’t proof: five findings from auditing my own infrastructure.

Architecture

Four physical machines carry the platform: a developer laptop, a small cloud server at the edge, a home hypervisor split into isolated zones, and a production host. Everything talks over a private WireGuard network; only two names are public.

The zones matter more than the boxes: the build zone can push images and request signatures through the front door, but it cannot reach the signing services' internals, the source zone's admin side or production.

From commit to production

Trust is tied to identities and a public log, never to a signing key someone could copy. The numbers match the diagram.

1. Commit (1–3). gitsign opens a browser login through the OIDC provider. Fulcio issues a certificate valid for about ten minutes, bound to my email, and the commit is signed with a key that exists only for that moment. The signature goes into Rekor, an append-only transparency log, and the timestamp authority proves when it was made. There is no long-lived signing key on the laptop to steal.
2. Pull request (4–6). main is protected: nothing merges without a pull request, and five checks must pass: signature verification of every commit, build and tests, secrets scanning, SAST and SCA. Administrators are not exempt.
3. Release (7–8). A signed tag, created only after a guard confirms the merged commit is on main, starts the release workflow. CI builds the container image and signs it keylessly with the workflow's own OIDC identity, not mine, attaches an SPDX SBOM as a signed attestation, and pushes it to the registry.
4. Deploy (9–10). The production host pulls by digest only and runs cosign verify against the exact identity release.yml@refs/tags/vX.Y.Z plus verify-attestation for the SBOM. Deployment configuration is itself a signed release of an infrastructure repository; the deploy script compares the new configuration with the running one and proceeds only if the difference is exactly the expected image line. Rollback is one command.

A trust root ties it together: the root CA lives offline on two encrypted USB drives, and a TUF repository distributes the trust root (which CA, log and timestamp authority to trust) so it can be rotated safely. A witness on a separate server checks that the transparency log is never rewritten.

The tools and what each one does

Everything is open source and self-hosted.

Adding AppSec gates

With the signed pipeline in place, I added a security workflow to both repositories: secrets scanning (blocking from day one), SAST and SCA (advisory until the backlog was triaged, then required). Every tool is pinned by SHA-256 or the Go checksum database, and reports are written as SARIF.

Backend. All 32 reachable findings were in the Go standard library, so a toolchain upgrade cleared them. Code review of the SAST findings closed an ORDER BY injection risk: sort columns now pass an allowlist at the database layer, with unit tests. Session cookies are always Secure, and raw database errors no longer reach clients.

Frontend. About 115 of the 130 Semgrep findings were noise: translation-style rules and an audit rule that flags every React useRef. I limited the rule set to the security and correctness folders and wrote the reason into the workflow, while the rules for real sinks (innerHTML, dangerouslySetInnerHTML, eval, postMessage) stay active. The findings that remained were real: prototype pollution and a regular expression built from keys in API data, inside the translation helper. Lookups now accept own properties only, and one fixed {{name}} pattern replaced the dynamic regex. I also removed a test page that had shipped to production and an inline script that would have blocked a strict Content Security Policy.

On the dependency side, the biggest win was a deletion: a secrets-management SDK was listed as a frontend dependency but imported nowhere. Removing it took out about 85 advisories, including the AWS SDK, axios and an XML parser with a Critical. Upgrading Next.js fixed its own Criticals. The remaining dev-tooling advisories were fixed with npm update --before, which enforces my 14-day release cooldown at the package-manager level.

The triage rule I follow: fix it, suppress it on that line with a written reason, or accept it with an expiry date. Never a global ignore. The one open advisory sits in osv-scanner.toml with an ignoreUntil date; if nobody fixes it in time, the gate turns red again by itself.

Design decisions and trade-offs

Known gaps I accept for now, and track: all zones share one physical host, signing keys are file-based until an HSM arrives, and there is no second human reviewer, so automated checks and signatures carry more weight.

Lessons learned

1. Clocks are part of your trust model. CI signatures sometimes failed verification because the certificate's start time was "now" and a verifier with a slightly different clock saw it as not yet valid. Back-dating the start by 30 seconds in Fulcio, built from source, fixed it.
2. Triage beats volume. 130 SAST findings looked alarming; about 15 mattered. A noisy gate gets ignored, a trusted one gets used.
3. Your dependency list is attack surface. The cheapest vulnerability fix was deleting a package nobody used.
4. Guards beat good intentions. One release tag was once created before its pull request merged, so it pointed at the old code. Now a script refuses to tag unless the merged commit is on main, and refuses to deploy unless the change is exactly the expected line.
5. A platform includes its host. The hypervisor once froze when an automatic package refresh triggered a bug in its system manager. Recovery, a root cause and a new alert followed, and the host now runs nothing it does not need.
6. AI as a pair engineer, under the same rules. I used an AI assistant to draft scripts and review changes. Every change still went through a signed pull request and the same gates. That is the posture I want for AI in a security pipeline: helpful, never trusted to merge or sign.

What's next

The signed pipeline (milestone 1) and the first AppSec slice are done. The rest of milestone 2, in order:

1. STRIDE threat model of the application: short-lived JWTs and refresh-token rotation, tenant isolation by subdomain, CORS, CSP, rate limiting and abuse cases.
2. DAST with OWASP ZAP, including an API scan, against a staging copy.
3. One view of all findings in DefectDojo, fed by the SARIF reports.
4. Guarded AI triage: a local model drafts triage notes, read-only and advisory, unable to merge or sign.
5. SLSA provenance as signed attestations, aiming at SLSA Build Level 3.

After that: Kubernetes with an admission policy that rejects unsigned images, infrastructure as code with nightly drift detection, and signing keys in a hardware security module.

If you are building something similar, start with one rule: production should refuse what it cannot verify. Everything else in this post grows from it.