Web Security and WAF · Defense in Depth: Headers, WAF, Edge and SDLC
Secrets Management and Supply-Chain Security
Keep credentials out of code and trust what you build and deploy.
Store secrets in a manager (Vault, AWS Secrets Manager, GCP Secret Manager), inject them at runtime, prefer short-lived credentials (OIDC federation, workload identity), rotate regularly, and scan repositories for leaks. For the supply chain: lock dependencies, scan for vulnerabilities (SCA) and malicious packages, pin CI actions to SHAs, use least-privilege CI tokens, generate SBOMs, sign artifacts (Sigstore/cosign) and verify signatures at deploy time (SLSA provenance).
# GitHub Actions: OIDC to AWS (no stored keys), pinned actions
permissions:
id-token: write
contents: read
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # pinned SHA
- uses: aws-actions/configure-aws-credentials@<pinned-sha>
with:
role-to-assume: arn:aws:iam::123456789012:role/ci-deploy
aws-region: eu-west-1
- run: syft packages dir:. -o spdx-json > sbom.json
- run: cosign sign --yes registry.example.com/api@${DIGEST}
Common pitfalls
- Long-lived cloud keys in CI secrets.
- Secrets in Docker image layers or logs.
- Auto-merging dependency updates without tests and review.
Key points
- Secret managers + short-lived credentials
- Scan, lock and pin dependencies
- SBOMs, signing and provenance
Further reading: SLSA framework
Practice questions
Why prefer OIDC federation for CI over stored cloud access keys?
Answer
CI obtains short-lived credentials per job scoped to a role; there's no long-lived secret to leak or rotate.
What is an SBOM used for?
Answer
A software bill of materials lists all components and versions in an artifact, letting you quickly find affected systems when a vulnerability is disclosed.
Open in the app to mark lessons complete, take notes and track your progress.