What does it mean to 'shift security left' in a CI/CD pipeline, and what kinds of automated checks would you add to a build?

technical-conceptual · Junior level · cloud-devops-security

What the interviewer is really asking

Assess whether the candidate understands that DevSecOps moves security earlier in the lifecycle so issues are caught cheaply, and can name the concrete gates (SAST, SCA, secret scanning, IaC and container scanning, DAST) and where each runs.

What to say

• Define it plainly: shifting left means running security checks early and automatically — on every commit or pull request — instead of waiting for a manual review or a pen test right before release, because a flaw is far cheaper to fix when it's caught in the editor or the build than in production.
• Name the gates and what each catches: SAST scans your own source for code-level flaws, SCA (dependency scanning) flags known-vulnerable libraries you pulled in, secret scanning blocks committed credentials, IaC and container-image scanning catch misconfigurations and vulnerable base images, and DAST exercises the running app.
• Place them in the flow: SAST, SCA, secret scanning and IaC scanning run fast on every merge request to give developers immediate feedback; DAST runs later against a deployed staging environment because it needs the app actually running.

What to avoid

• Treating 'shift left' as just a buzzword or saying security is the security team's job at the end — the whole point is that the checks are automated and owned by the developers writing the code.
• Listing tools you've never used by name without knowing what category they belong to, or claiming a single scanner catches everything — SAST, DAST and SCA find different classes of problem and are complementary.
• Making every finding a hard build-breaker on day one with no severity tuning — that floods developers with noise, they start ignoring or bypassing the gate, and you lose the signal.

Example answers

Strong: On a service I worked on we added two gates to the pull-request build: SCA to flag dependencies with known CVEs and secret scanning to block committed keys. SAST ran on the same trigger for code flaws, and we kept DAST on a nightly run against staging since it needs the app deployed. Catching a leaked token at the PR meant we never had to rotate it in production.

Weak: Shift left just means doing security earlier. I'd add a security scan to the pipeline and fail the build if it finds anything.