Supply Chain Security

The SolarWinds, Log4Shell, and XZ Utils incidents made supply chain security a board-level conversation. Before investing in tooling, it's worth understanding the distinct attack classes you're defending against — they require different mitigations.

CodeQL is GitHub's semantic code analysis engine. Unlike grep-based scanners, CodeQL builds a queryable database of your code's structure — it understands data flow, taint tracking, and call graphs. This lets it find vulnerabilities that span multiple files and function calls.

Setting up the default CodeQL scan

Query packs — choosing depth vs speed

Custom CodeQL queries

You can write your own queries in CodeQL's query language (QL) and add them to the scan:

Reviewing code scanning results

Results appear in Security → Code scanning alerts. Each alert shows:

• The vulnerable code path with highlighted source and sink
• The data flow path (how untrusted input reaches the vulnerable point)
• Rule ID, CWE category, and severity
• Inline annotation in the PR diff for new alerts

Dismiss alerts with a reason (false positive, used in tests, risk accepted) — all dismissals are audited. Never silently dismiss a real finding.

Alert severity levels and what to do

Blocking PRs on new high-severity alerts

Make code scanning a required status check in your branch protection rules. New Critical/High findings on a PR will block merge:

Copilot Autofix for code scanning

GitHub Copilot Autofix (available with GHAS) analyzes a code scanning alert and suggests a fix inline in the PR diff. The suggestion is a pull-request suggestion that the author can accept with one click. It understands the alert's data flow path and generates context-aware patches rather than generic template fixes.

SARIF (Static Analysis Results Interchange Format) is a JSON standard for security tool output. Any tool that produces SARIF can upload results to GitHub's Security tab — giving you a unified view of findings across CodeQL, Semgrep, Snyk, Trivy, and others.

Semgrep

Trivy (container image and filesystem scanning)

An artifact attestation is a signed statement that a specific artifact (binary, container image, npm package) was produced by a specific GitHub Actions workflow, from a specific commit, at a specific time. It answers "did this artifact really come from our official build pipeline, or was it tampered with?"

GitHub's attestation system uses Sigstore under the hood — the attestation is signed with a short-lived certificate tied to the GitHub OIDC token, and the signature is published to Sigstore's public transparency log.

Generating build provenance attestation

Verifying an attestation

Container image attestation

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component, library, and dependency in your software — like a nutrition label for code. SBOMs are increasingly required for software sold to government agencies and regulated industries, and useful for rapid vulnerability assessment when a new CVE drops.

GitHub's built-in SBOM export

For repos with dependency graph enabled, GitHub can generate a basic SPDX SBOM directly from the UI or API:

CycloneDX via GitHub Actions (richer, more tooling support)

SBOM formats comparison

Sigstore is a set of open-source tools (cosign, fulcio, rekor) for signing software artifacts. The key innovation is keyless signing — instead of managing a GPG key pair, you use your OIDC identity (GitHub Actions token) to get a short-lived signing certificate. The signature is anchored to Sigstore's public transparency log (Rekor), making tampering detectable.

Signing a container image with cosign (keyless)

Verifying a signed image

Verifying at deploy time (Kubernetes admission)

Tools like Sigstore Policy Controller and Kyverno can enforce that only signed images from trusted workflows are allowed to run in your Kubernetes cluster — the verification happens at pod admission, before the container starts. This closes the gap between "image was built correctly" and "only signed images run in production."

We covered SHA pinning in Phase 6.12. Here we focus on the operational workflow — how to keep hundreds of SHA-pinned actions across dozens of repos updated without manual effort.

Dependabot for GitHub Actions

When an action author pushes a new release, Dependabot opens a PR that updates the SHA in your workflow file from the old commit to the new one — with the new version tag in a comment. You review the action's changelog, approve, and merge.

Auditing un-pinned actions across your org

The OpenSSF Scorecard is an automated tool that evaluates a repository against a set of supply chain security checks and produces a score from 0–10. It gives you an objective, auditable measure of your security posture — and a concrete to-do list for improvement.

Running Scorecard in CI

Scorecard checks and what they measure

Scorecard improvement roadmap

The three checks with the highest ROI for most teams:

1. Pinned-Dependencies — add dependabot.yml with github-actions ecosystem, start SHA-pinning actions. Dependabot keeps the SHAs current.
2. Token-Permissions — add permissions: contents: read at the top of every workflow. Add more specific permissions per job as needed. This single change often jumps the score by 3+ points.
3. Signed-Releases — add actions/attest-build-provenance to your release workflow. Combined with cosign for container images, this satisfies the check.