Sefism is free for learners. We are here to help you grow, one step at a time.Join for free
Sefism.
Security

Signed Build Provenance Gate for a Company's Internal Packages and Container Images

Build a gate that lets a small company prove every internal package and container image was built by its own CI from a reviewed commit, and blocks anything that was not. It uses keyless signing from the Sigstore project and SLSA-style provenance, wrapped into a setup a team can adopt in an afternoon. Deployments and installs check the signature and the build record before they proceed.

Topics
Difficulty

Intermediate

A small team, or one strong student willing to learn something new.
Effort

1 to 2 semesters · 2 students

Deliverables

7 to ship

4 optional extras

Suggested stack

Go or PythonSigstore (cosign, Fulcio, Rekor)GitHub Actions OIDCKubernetes admission webhook or DockerVerdaccio or a private npm registry
A suggestion, not a requirement. Swap anything for what you already know.

What you should ship

  • A reusable CI workflow that builds, signs and attaches provenance to images and npm packages
  • A policy file per team: which repositories, branches and workflows may produce trusted artifacts
  • A verifier library and command-line tool that checks signature, identity and provenance against the policy
  • A Kubernetes admission webhook that refuses unsigned or off-policy images
  • A registry-side check for internal npm packages before they are installed
  • An attack demo: a tampered image and a package published from a laptop, both blocked with clear reasons
  • Setup documentation and a measured setup time with a team that has never used Sigstore

If you have time left

  • Monitoring the public transparency log for any signature made with the company's identity
  • Python package support
  • A dashboard of artifacts in production and their provenance
  • Break-glass mode for emergencies with a mandatory audit record

The problem: nobody can say where a running image came from

In many small and medium companies, a container image or internal package can reach production in more than one way: built by CI, pushed from a developer's laptop "just this once", or rebuilt by hand during an incident. When something goes wrong, nobody can prove which commit an artifact was built from, or that it was built by CI at all. An attacker who steals a registry token can push a tampered image with the same tag, and nothing downstream will notice.

Large companies solve this with signed builds and admission control. Small teams in Lahore, Karachi or anywhere else usually skip it because the setup looks complicated and key management is scary.

What already exists and the gap

  • Sigstore offers keyless signing: cosign signs with a short-lived certificate tied to an identity such as a GitHub Actions workflow, and the Rekor transparency log records it.
  • SLSA defines levels of build provenance, and GitHub can generate provenance attestations for builds.
  • Kyverno and the Sigstore policy controller can verify image signatures in Kubernetes.
  • npm supports provenance for packages on the public registry.

The parts exist, but putting them together is the hard bit. Teams must decide what identity counts as trusted, write policies, cover both images and private packages, and handle the day CI is down. The gap is a small, opinionated kit that does this end to end for a typical small company, with honest documentation of what it does and does not protect against.

Inspiration

"Sigstore: Software Signing for Everybody" by Zachary Newman, John Speed Meyers and Santiago Torres-Arias (ACM CCS 2022) describes the design: binding signatures to identities from existing login providers instead of long-lived keys, and recording everything in a public log so misuse can be detected. This project applies it to private artifacts in a small company, which the paper names as a harder adoption case.

What you build

  • Developers change nothing about how they work; the shared CI workflow signs and records provenance.
  • Platform owners write a short policy: images for payments must come from the payments-api repository, main branch, release workflow.
  • The cluster and the registry refuse anything that does not match, with a clear reason in the error.

The technically interesting part

  • Identity, not keys. The trust decision is "signed by this workflow in this repository on this branch". Get the claims in the certificate right, including forks and pull request builds, which must never be trusted.
  • Nothing to rotate. Because certificates live for minutes, there is no long-lived signing key to leak or rotate. Explain clearly what replaces key management: the CI identity and the branch protection rules, which now become the things an attacker must defeat.
  • Provenance checks. A valid signature is not enough. Check that the provenance names a reviewed commit on a protected branch, and that the digest matches what is being deployed.
  • Two kinds of artifact. Images and npm packages are stored and verified differently. Design one policy format that covers both.
  • Failure modes. What happens when the transparency log is unreachable, or production is on fire? Design a break-glass path that is logged and noisy, rather than a silent bypass.
  • Threat model. Write down which attacks the gate stops (stolen registry token, laptop push, tag swap) and which it does not (a malicious commit that passes review).

How to evaluate it

  • Attack scenarios: run each scenario in the threat model and record whether it is blocked and how clear the error is.
  • Overhead: added CI time per build and added deploy latency per admission check.
  • Adoption: time for a team new to Sigstore to set it up from your documentation, observed directly.
  • Coverage: share of a sample company's artifacts that end up signed and verified.

Suggested plan

  • Weeks 1 to 3: sign and verify an image by hand with cosign; read the SLSA levels.
  • Weeks 4 to 7: shared CI workflow for images and packages; policy format.
  • Weeks 8 to 11: verifier, admission webhook and registry check.
  • Weeks 12 to 15: attack demos, adoption test, documentation and report.

Path to a product

Supply chain rules are spreading through customer security questionnaires and regulation, and small vendors are increasingly asked to show where their software comes from. A packaged kit with support, or a hosted policy service, could serve them. It is also strong portfolio work for DevSecOps roles.

Scope warning

Do not run your own certificate authority or transparency log; use the public Sigstore services or their official containers. Cover images first, then packages. Keep the policy language small.

Learn what you need on Sefism

Get help with this idea

The risk is a gate that is either easy to bypass or so strict that teams switch it off. Tauseef can help you write the threat model, design the policy format and plan the adoption test. If you are new here, create a free account first.

Ideas and guidance, not finished projects

These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.

Not sure this one fits you?

I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.

Discuss this idea
Work with me

Stuck on something specific?

Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.

Book a free sessionSee all services

Follow along

New writing, resources and project ideas land here first.