Lesson 05 — Security Scanning & Image Signing

Trivy, SBOMs, cosign, and branch protection — turning the green check into a contract.

Cloud & DevOps Module 2

What L04 did NOT cover

• The build is green — but is the image safe?
• Does your image ship known CVEs (Common Vulnerabilities and Exposures)?
• Can someone tamper with the image between build and pull?
• A green check only tells you: code compiles and tests pass.
• It says nothing about what ended up inside the image.
• Supply-chain attacks are real and increasing — SolarWinds, XZ Utils, Log4Shell.

The supply-chain threat model

Each touch point is a possible compromise vector — even if your code is clean.

Vulnerability scanning with Trivy

- name: Trivy scan
  uses: aquasecurity/trivy-action@0.24.0
  with:
    image-ref: api:ci-${{ github.sha }}
    severity: HIGH,CRITICAL
    exit-code: 1
    ignore-unfixed: true

• Scans OS packages (distro CVE DB) and language packages (GHSA, PyPI, npm advisory DBs)
• exit-code: 1 makes the job fail when findings are found
• ignore-unfixed: true skips CVEs with no upstream fix — avoids alert fatigue
• Severity floor HIGH,CRITICAL cuts noise from LOW/MEDIUM

Trivy vs Grype

Either works. Pick one and stick to it — mixing tools leads to inconsistent severity noise. We use Trivy in this sample.

SBOM: what and why

A Software Bill of Materials (SBOM) lists every package that ended up in your image — the full dependency tree, not just your direct deps.

• Standard formats: SPDX (Linux Foundation), CycloneDX (OWASP)
• Regulatory: US Executive Order 14028 requires SBOMs for federal contractors
• Operational: when Log4Shell (CVE-2021-44228) dropped, teams without SBOMs spent days inventorying exposure; teams with SBOMs knew in minutes
• Attach to registry: cosign can store the SBOM as a signed attestation alongside the image

Generating an SBOM with Syft

- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    image: api:ci-${{ github.sha }}
    format: spdx-json
    output-file: sbom-api.spdx.json
- uses: actions/upload-artifact@v4
  with: { name: sbom-api, path: sbom-api.spdx.json }

• Syft (by Anchore) generates the SBOM from the live image in the local daemon
• spdx-json is machine-readable and widely supported
• Upload as an artifact so auditors can download it from the Actions run

Image signing with cosign

cosign signs an image (or any OCI artifact) with a key. The signature lives in the registry next to the image. Verifiers check the signature before deploying.

Two signing modes:

• Static keypair — generate a key, store the private key in a CI secret. Works, but you now manage a long-lived secret.
• Keyless (OIDC) — cosign uses GitHub’s OIDC token to authenticate to Sigstore’s Fulcio CA. No private key to manage. The canonical pattern for 2024+.

The signature attests: “this image was produced by the expected pipeline at the expected commit.”

Keyless signing in GitHub Actions

- uses: sigstore/cosign-installer@v3
- name: Sign image (keyless)
  env:
    COSIGN_EXPERIMENTAL: "true"
  run: |
    cosign sign --yes \
      ghcr.io/${{ github.repository }}/api@${{ steps.build.outputs.digest }}

• Keyless = no private key to store in secrets
• The signature attests: “image X was built by GitHub Actions workflow Y on commit Z”
• Requires permissions: id-token: write on the workflow
• --yes skips the interactive prompt — required in CI

Verifying signatures at deploy time

cosign verify \
  --certificate-identity-regexp "https://github.com/$ORG/$REPO/.*" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/$ORG/$REPO/api@$DIGEST

Deploy-side verification checks that the image came from the expected pipeline — not just that it has a valid signature, but that the cert identity pins it to your workflow.

Run this in a Kubernetes admission webhook or a deploy job to prevent unsigned images from reaching production.

Branch protection

GitHub UI: Settings → Branches → Add branch protection rule → pattern main

• ☑ Require status checks to pass before merging: lint, test (3.11), test (3.12), build (api), build (worker), trivy-api, trivy-worker
• ☑ Require pull request reviews: 1 approval
• Optional: require linear history, require signed commits

The green check is now a contract: merging without it is impossible.

What we’ll add in the lab

• Trivy scan job on each image (HIGH/CRITICAL, ignore-unfixed)
• SBOM generation and artifact upload (Syft, spdx-json)
• cosign install + keyless sign on merge to main
• SBOM attached as a signed attestation via cosign
• Branch protection configured (manual GitHub UI step)

By the end: CVE gates on PRs, signed images on main, verified trust chain.

Common gotchas

• ignore-unfixed: true is your friend — without it, you fail on CVEs that have no upstream patch and the team goes numb to the noise
• cosign --yes skips the interactive confirmation; in a non-TTY runner, omitting it hangs the job forever
• Signing fails on PR builds from forks — fork PRs don’t get id-token: write permission; gate signing on github.event_name != 'pull_request' (or use the separate security.yml pattern)
• Place .trivyignore in the working directory where Trivy runs, not next to the Dockerfile

Recap & what’s next

• Scan images for CVEs with Trivy; generate SBOMs with Syft — both run inside the existing CI build job
• Branch protection makes the required checks a hard gate: no merge without green
• The cosign-signed image is the trust anchor for L06’s deploy — you can verify provenance at the point of deployment