DevSecOps — Fundamentals

Shift-left means moving security checks earlier in the software lifecycle — into the IDE and the pull request — instead of running them only right before a release, or worse, finding out from an external report after something's already in production. The reasoning is a cost curve: a bug caught while someone's writing the code costs minutes to fix; the same bug caught in a security audit after it's merged costs a ticket, a context-switch, and a re-review; caught in production it can mean an incident, customer notification, and possibly a compliance finding. If a team has nothing today, I wouldn't start by rolling out a full SAST/DAST suite — I'd start with secret scanning and dependency (SCA) scanning as a required PR check. Both are cheap to run, have very low false-positive rates compared to SAST, and catch two of the most common real-world breach vectors — a leaked credential or a known-vulnerable dependency — without asking developers to interpret ambiguous static-analysis findings on day one. SAST and DAST come next, once the team has a working pattern for triaging findings instead of just ignoring a noisy new gate.

"On my last team we ran Semgrep on every pull request using a pre-built ruleset plus a few custom rules we'd written for patterns we'd been burned by before, like hardcoded credentials matching our own key format. For dependencies, we ran npm audit/pip-audit in CI and had Dependabot open PRs for anything patchable automatically. The real problem wasn't picking tools, it was noise: the first time we turned on SAST as a hard CI gate, it failed on hundreds of pre-existing findings in code nobody was touching, and the team's reaction was to just add a blanket ignore rule, which defeats the point. We fixed that with a baseline-and-ratchet approach — we recorded the existing findings as an accepted baseline, gated only on new findings introduced by a PR's diff, and set a quarterly goal to burn down a slice of the baseline. DAST we ran less often — a ZAP baseline scan against staging on every deploy, and a full active scan only on a schedule, never against production, since active scanning genuinely attacks the running app. That staged approach — SCA and secrets on every PR, SAST gated on new findings only, DAST against staging on a slower cadence — is what actually got adopted instead of resented."

"Three real issues, and I'd fix all three, not just one. First, FROM node:latest is a floating tag — the exact base image changes every time it's rebuilt, so you can't reproduce what's actually running, and you have no fixed reference point to check for known CVEs against; it should be pinned to an exact version, ideally by digest. Second, and the most serious: ENV DATABASE_PASSWORD=Sup3rSecret! bakes a secret directly into the image layer history. Anyone who can pull the image — including via a registry misconfiguration or a compromised CI cache — can run docker history or inspect the image's layers and read that password in plaintext, even if a later instruction tries to overwrite or unset it; the layer with the secret is still there. That value needs to come from a runtime secret injection mechanism — a mounted secret, a Kubernetes Secret, Vault — never a build-time ENV. Third, there's no USER directive, so this container runs as root by default; if the app is ever compromised, the attacker has root inside the container, which is a much bigger blast radius than a non-root process would give them. I'd also flag that this isn't a multi-stage build — the final image ships whatever devDependencies and build tooling npm install pulled in, which is more attack surface and a bigger image than a runtime-only stage needs."

What CI platform is this — GitHub Actions, GitLab, Jenkins — since the concrete hardening controls differ by platform? Are third-party actions/plugins currently pinned to anything, or pulled by a mutable tag? Does the deploy target consume container images, raw artifacts, or both? Is there any existing requirement (customer contract, government/regulated industry) to produce an SBOM or provenance attestation, or would this be purely internal hardening?

Harden the pipeline itself first: pin every third-party action/plugin to an exact, immutable commit SHA rather than a mutable tag like v4 (a compromised or re-tagged upstream action is exactly the SolarWinds-shaped attack — the build trusts whatever that tag currently points to); require signed commits on protected branches; and default every workflow's token permissions to read-only, granting write scopes only where a specific job genuinely needs them, closing off the "pwn request" pattern where a pull-request- triggered workflow runs untrusted code with access to repo secrets. Then instrument the build to produce evidence: generate an SBOM (via Syft or Trivy, in CycloneDX or SPDX format) for every build artifact, sign the final artifact/image with Cosign using Sigstore's keyless signing (Fulcio issues a short-lived cert off an OIDC identity, Rekor logs it in a public transparency log — no long-lived private key to protect or leak), and attach an in-toto/SLSA provenance attestation proving which source commit, which pipeline, and which inputs produced that specific artifact. Finally, gate the deploy step on verification — the deploy pipeline checks the signature and provenance before pulling an image into production, and a continuous SBOM- monitoring tool (Dependency-Track) re-checks every previously-generated SBOM against newly disclosed CVEs, since a component clean at build time can become vulnerable weeks later.

Keyless signing removes the operational risk of a long-lived signing key leaking, but it shifts trust onto the OIDC identity provider issuing the short-lived certificate — that trust boundary needs its own review, since anyone who can mint a token as the expected workflow identity can sign as it. Enforcing signature/provenance verification as a hard deploy gate from day one is safer but adds real friction and will break existing pipelines that were never producing this evidence; I'd roll it out in audit/report-only mode first, fix what it flags, and only then flip it to a hard gate. Full SLSA Build Level 3 — hermetic, isolated, non-interactive build platforms — is the strongest guarantee but is genuinely expensive to reach org-wide; a sequenced rollout (start at provenance-only, then signed builds on protected infrastructure, then full isolation) gets real security value sooner than waiting to do it all at once.

"I'd start with the pipeline itself, since that's what actually got compromised in the SolarWinds-shaped attack: pin every third-party action to a commit SHA instead of a tag, and lock down workflow token permissions so a PR-triggered job can't quietly exfiltrate secrets — that closes the 'pwn request' pattern. On top of that, every build produces real evidence: an SBOM via Syft, a Cosign signature using keyless signing so there's no private key sitting in a secrets manager to leak, and an in-toto attestation tying the artifact back to the exact commit and pipeline that built it. The deploy step then verifies that signature and provenance before anything reaches production — so even if someone did manage to push a malicious build, it fails to pass verification instead of silently deploying. I'd roll the verification gate out in report-only mode first, since flipping it to a hard block on day one against pipelines that have never produced this evidence would just break everything at once."

A SOC 2 Type I report attests that your controls are designed correctly as of one specific date — an auditor reviews the control descriptions and confirms they'd work if operated as described, but doesn't verify they were actually followed. A Type II report covers a window, typically six to twelve months, and the auditor tests whether those controls were actually operating effectively the whole time — pulling evidence like actual access-review tickets, actual vulnerability-scan results, actual incident records, not just policy documents. The reason a security team pushes for Type II despite the extra cost and a much longer timeline is that a Type I report only proves you wrote a good policy, not that you followed it — a sophisticated enterprise customer's security team knows this and will often treat a Type I report as a starting point, not sufficient evidence on its own, before they'll sign a contract involving their data. Type II is what actually closes enterprise deals that have real security due-diligence review, because it's evidence of practice, not just design.