CoursesSoftware supply chain securitySecuring source & dependencies

Securing the source

Branch protection, signed commits, least privilege.

Advanced12 min · lesson 4 of 18

The supply chain starts at the source repository, so that is where trust starts too. The foundation is branch protection: the default branch cannot be pushed to directly, every change arrives through a reviewed merge request, and code owners must approve changes to sensitive paths (the pipeline, the deploy config, the Dockerfile). If anyone can push to main, then the entire rest of this course is built on sand — the reviewed-source assumption every later control depends on is broken at the root.

branch protection (settings)
# main branch:
# - no direct pushes; changes only via merge request
# - require >= 1 approval; require Code Owner review for /ci, /deploy, Dockerfile
# - require status checks (scans) to pass before merge
# - require signed commits
# - dismiss stale approvals on new commits

Signed commits: prove who wrote it

A Git commit’s author field is just text — anyone can set your name and email. Commit signing (with GPG, SSH, or Sigstore’s gitsign) attaches a cryptographic signature proving the commit really came from the claimed identity, and the platform shows a "verified" badge. Requiring signed commits on protected branches stops an attacker with write access from impersonating a trusted developer, and gives you an authenticated history — the first verifiable link in the chain.

terminal
# keyless commit signing with gitsign (Sigstore) — no GPG key to manage
$ git config commit.gpgsign true
$ git config gpg.format x509
$ git config gpg.x509.program gitsign
$ git commit -m "fix auth check" # signed via OIDC identity, logged in Rekor

Least privilege on the SCM itself

The source platform is part of the attack surface. Enforce MFA on every account (a phished developer login is a supply-chain compromise), scope automation tokens and deploy keys to the minimum and rotate them, review who has admin and write access regularly, and disable or restrict the CI features that let a pipeline weaken its own protections. The repository is production infrastructure; treat access to it with the same rigor as access to the servers.

Protect the pipeline files hardest of all
The CI configuration, deploy manifests, and Dockerfile are the highest-value files in the repo — a change to them alters how everything is built and shipped. Require code-owner review specifically for those paths, so a change to the pipeline gets more scrutiny than a change to a README. An attacker who can quietly edit .gitlab-ci.yml or the Dockerfile owns your build without touching the application code.