The Engineering Codex/Application Security Engineering
DAY 6
08 / 09

Secure SDLC & Supply Chain

schedule5 minsignal_cellular_altIntermediate1,170 words
Shift-left in practice — SAST, DAST, IAST, dependency and secret scanning, SBOM and SLSA, plus a code-review checklist you can run on any PR today.

What you will learn

01The Three Scanner Families
02Dependency & Secret Scanning
03SBOM and SLSA — Knowing What You Ship
04Threat Modeling in Code Review
05Secrets Management
06Wiring It All Into CI

Security as a separate phase at the end of the project is a 1990s habit. Modern engineering folds it into every step — design, code, build, deploy, operate. The goal is not to find every bug; it is to reduce the cost of finding them from "weeks during pen-test" to "minutes in CI."

Cost of fixing a defect grows with stage Design$1 Code$5 CI / build$50 QA / staging$500 Production$5,000+ cost
Bug-fix cost rises ~10× per stage. Shift-left tooling moves discovery toward the cheap left side.

The Three Scanner Families

SAST · Static
  • Reads source / bytecode
  • Finds: SQLi, XSS sinks, hardcoded secrets, taint flows
  • Pros: early, runs on every PR
  • Cons: false-positive heavy without tuning
  • Tools: Semgrep, CodeQL, SonarQube
DAST · Dynamic
  • Hits a running app with payloads
  • Finds: real reflective XSS, SQLi, auth flaws
  • Pros: framework-agnostic, real proof
  • Cons: needs an environment, slow, low coverage
  • Tools: ZAP, Burp, Nuclei

And IAST — instruments the app at runtime to combine the two: it watches real requests with source-level context. Useful in QA; not yet a CI default.

Make SAST Useful, Not Noisy

  • Run on diff, not the whole tree, on PRs.
  • Block merge only on high-confidence, high-severity findings; track the rest.
  • Maintain an allow-list with reasons (not silenced silently).
  • Add custom rules for project-specific patterns ("never call exec()," "all SQL via the orm helper").

Dependency & Secret Scanning

Two of the highest-leverage controls in the SDLC, both close to free.

  • Dependency scanning — Dependabot/Renovate for updates, Snyk/Trivy/npm audit/pip-audit/govulncheck for CVEs. Set SLAs (Critical: 24h, High: 7d).
  • Secret scanning — pre-commit hooks (gitleaks, talisman, trufflehog) and GitHub's push-protection. The cost of one leaked AWS key on the open internet is measured in minutes before crypto miners hit it.
  • License compliance — block GPL drift into closed-source products if that's your model; FOSSA / Snyk / OSS Review Toolkit.

SBOM and SLSA — Knowing What You Ship

You cannot defend what you do not inventory. SBOM (Software Bill of Materials) is the inventory; SLSA (Supply-chain Levels for Software Artifacts) is the maturity ladder for build provenance.

SLSA build levels L1scripted buildprovenance exists L2hosted CI signs ittamper-evident L3hardened buildisolated, reproducible L4two-party reviewhermetic, audited Most teams should target L2 first: GitHub Actions / GitLab CI signed provenance.
SLSA's four levels of build assurance. The big jump in defensive value is L1 → L2.

Concrete Steps

  1. Generate an SBOM at build (CycloneDX or SPDX). Store it with the artifact.
  2. Sign the artifact (Sigstore / cosign). Verify on deploy.
  3. Pin all base images by digest, not tag. Reproducible enough for L2.
  4. Run vulnerability scans against the SBOM continuously — CVEs land after release.
  5. Track and minimise build-time secrets; rotate the rest with a vault.

Threat Modeling in Code Review

The cheapest threat model is one you do during code review. The questions to ask on every non-trivial PR:

📋 PR Security Checklist
1
Is there a new trust boundary? Any new endpoint, queue consumer, file uploader. If yes — STRIDE the boundary.
2
Is user input parsed as code anywhere? SQL, shell, template, regex, deserialisation, LLM tool call. Look for string concatenation.
3
Are AuthN and AuthZ both checked? Specifically the per-resource ownership filter, not just a logged-in middleware.
4
Is sensitive data in error messages, logs, or URLs? Tokens in query strings end up in proxy logs forever.
5
Are external HTTP calls protected from SSRF? URL allow-list, IP filter, IMDSv2 if AWS.
6
Are crypto primitives picked from the approved list? No SHA-1 for new code, no plain AES-CBC, no rolled-your-own.
7
Are new dependencies justified? Maintainer activity, size of transitive tree, license fit.
8
Is the change observable? Logs, metrics, alerts on the new failure modes.

Secrets Management

Secrets do not belong in code, env files, container images, ticket comments, or Slack DMs. They live in a vault. Every consumer fetches by identity at runtime.

  • Vaults: AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, 1Password Service Accounts.
  • Workload identity over static credentials: IAM Roles for Service Accounts (k8s), Workload Identity Federation (GCP), IRSA (AWS), Managed Identities (Azure).
  • Short TTLs on whatever cannot be eliminated.
  • Rotation automation — a secret you can't rotate quickly will not be rotated when leaked.
  • Pre-commit gitleaks; push-protection on GitHub; branch-protection requires review on any file matching **/secrets**.
Quick check
A developer commits an AWS access key, then deletes the file in a follow-up commit. Why is rotating the key still necessary?
Show answer
Git history is forever — the deleted file is still in older commits, and on every fork, mirror, and CI cache. Force-pushing rewrites your branch but cannot reach forks or the GitHub event log. Assume the secret has already been harvested by automated scrapers (which run within minutes of pushes to public repos). Rotate immediately, then clean history if you must.

Wiring It All Into CI

A pragmatic baseline pipeline (each step is a different team, each gate is meaningful):

.github/workflows/ci.yml (excerpt)
jobs:
  lint-and-test:      # the existing fast feedback
  sast:               # semgrep --config p/owasp-top-ten
  deps:               # trivy fs / npm audit / pip-audit
  secrets:            # gitleaks detect --redact
  build:              # reproducible image, pinned digests
  sbom-and-sign:      # cosign sign + cyclonedx-bom
  image-scan:         # trivy image — block on Critical
  deploy-staging:     # cosign verify before pull
  dast-smoke:         # nuclei + zap baseline against staging
Flashcard
Why does "shift-left" not eliminate the need for DAST or production runtime monitoring?
Click to flip ↻
Answer
SAST sees code, not behaviour. It cannot detect: misconfigurations introduced at deploy time, broken access control on a route that exists due to a config flag, third-party services that change behaviour, runtime-only data flows. DAST plus production telemetry catches these. Shift-left makes detection cheap, not complete.
Mnemonic — the SDLC stack
"Plan it, lint it, build it, sign it, scan it, deploy it, watch it."
  • Plan — threat model in design doc
  • Lint — SAST + secrets in CI
  • Build — reproducible, pinned, hermetic
  • Sign — sigstore / cosign
  • Scan — SBOM + CVE feed continuously
  • Deploy — verify signature, least-privilege
  • Watch — DAST, runtime, anomaly alerts
🔑
Key takeaways
1) Bug-fix cost rises ~10× per stage; the cheapest finding is one a SAST rule catches in CI. 2) Tune scanners aggressively — noise is the reason teams ignore them. 3) Generate SBOMs, sign artifacts (sigstore), pin digests; aim for SLSA L2 first. 4) Secrets live in a vault, not in code; rotate fast and assume committed secrets are already harvested. 5) Ship the security checklist into PR templates so the right questions get asked every time.
📚 Further reading

Finished reading?