Security & DevSecOps

DevSecOps means security is everyone's job and it "shifts left" — built into the pipeline from the first commit, not bolted on before release. The goal is to catch problems automatically, early, and cheaply.

The practices you'll add to a pipeline:

• Secrets management: never commit passwords or keys. Store them in a vault (HashiCorp Vault, cloud secret managers) and inject at run time. Scan the repo for accidental leaks.
• Scanning: SAST analyses your source, DAST tests the running app, and dependency/image scanners (Trivy, Snyk) find known vulnerabilities (CVEs) in your libraries and containers.
• Policy as code: tools like OPA let you write rules ("no public S3 buckets", "images must be signed") that the pipeline enforces automatically.
• Supply-chain security: generate an SBOM (a bill of materials of everything in your build) and sign artifacts (Sigstore) so you can prove what you shipped. SLSA is the framework here.

Underneath it all is least privilege — the same principle from IAM, applied everywhere.

A secret in Git is a breach. Once committed it's in the history, on every clone, and bots scan public repos for keys within seconds of a push. Secrets management is the discipline of never being in that position.

The rules:

• Never commit secrets. Enforce it mechanically with pre-commit hooks and scanners (gitleaks, trufflehog) in CI — humans will forget.
• Inject at runtime, via environment variables or mounted files, never baked into an image or a config file.
• Rotate regularly, and automatically if you can. A secret that can't be rotated quickly is a secret you can't respond to.
• Scope tightly. A staging credential must not open production.

The tools:

• HashiCorp Vault — the heavyweight. Central storage, fine-grained policies, full audit log, and its killer feature: dynamic secrets — Vault generates a unique, short-lived database credential per application on demand and revokes it after use. A leaked credential expires by itself.
• Cloud secret managers — AWS Secrets Manager, GCP Secret Manager, Azure Key Vault. Simpler, and integrate directly with IAM roles.
• Kubernetes: a plain Secret is only base64-encoded — not encrypted. Enable encryption at rest, and use the External Secrets Operator to sync from a real vault, or Sealed Secrets if you must store an encrypted secret in Git safely.

If a secret leaks: rotate it first, investigate second. Deleting the commit does not help — assume it's already harvested.

You didn't write most of the code you ship. A typical application is a thin layer of your logic on top of hundreds of third-party dependencies and a base image you didn't build. The software supply chain is your attack surface.

The threats are real and recent: typosquatting (a malicious package named one character off a popular one), dependency confusion (a public package shadowing your internal one), compromised maintainers pushing a backdoored update, and build system compromise (SolarWinds — the source was clean, the build was poisoned).

The defences, in order of value:

• SBOM (Software Bill of Materials) — a machine-readable inventory of every component in your artifact (SPDX/CycloneDX; generate with Syft or Trivy). When the next Log4Shell lands, an SBOM answers "are we affected, and where?" in minutes instead of a frantic week.
• Pin and verify dependencies. Use lockfiles; pin base images by digest (@sha256:…), not a mutable tag.
• Sign your artifacts. Sigstore/cosign signs images and generates provenance — a verifiable statement of what was built, from which commit, by which pipeline. Then have your cluster refuse to run unsigned images (admission policy).
• Harden the build. The build system holds the keys to everything; treat it as production. SLSA is the framework that grades exactly this.

At some point a customer, auditor, or regulator asks: prove your systems are secure. If that proof is a person manually collecting screenshots for six weeks, you've lost. Compliance as code turns it into an artifact of how you already work.

The frameworks you'll hear named: SOC 2 (the common one for SaaS — security, availability, confidentiality), ISO 27001 (international infosec standard), GDPR (EU personal data), HIPAA (US health data), PCI-DSS (card payments). They differ in detail but demand the same underlying things.

Nearly every control reduces to evidence you can already produce automatically:

• Access control — least-privilege IAM, MFA, reviewed regularly.
• Change management — every production change is a reviewed, approved, traceable commit. (Your Git history + PR approvals is this evidence — which is why GitOps makes auditors happy.)
• Audit logging — CloudTrail and friends, retained and tamper-resistant.
• Encryption — in transit (TLS) and at rest.
• Backups and DR — proven by actual restore tests.
• Vulnerability management — scanning in CI, with documented remediation SLAs.

Enforce it continuously with policy as code (OPA, cloud config rules) so a non-compliant resource is blocked at creation, and use drift detection so the environment can't silently fall out of compliance between audits.