DevSecOps & supply-chain security interview questions

Moving security earlier into design and development — threat modeling, linting, scanning in CI — so issues are caught when they are cheap to fix, rather than in a late pen-test or in production.

A bug caught in code costs minutes; the same bug in prod costs an incident.

SAST analyzes source/bytecode statically; DAST tests the running app from outside; SCA scans third-party dependencies for known CVEs; IAST instruments the running app to observe real code paths. They find different, complementary classes of issues.

SAST finds your code bugs (SQLi patterns) with false positives; DAST finds real runtime issues but only on paths it exercises; SCA covers the 80%+ of your app that is dependencies; IAST watches instrumented code for real vulnerable paths. You layer them — none alone is enough.

A CVE is a unique ID for a public vulnerability; CVSS is a 0-10 severity score from exploitability and impact. Score alone is a poor priority: pair it with reachability (do you call the vulnerable code?), exposure, and exploit signals like EPSS/KEV.

A CVSS 9.8 in a dependency you never call at runtime may be lower risk than a 6.5 on your public login path. Modern triage weighs EPSS (probability of exploitation) and CISA KEV (known exploited) so you fix what attackers actually use, not the biggest number.

Systematically asking what can go wrong before you build: enumerate assets, entry points, and trust boundaries, then brainstorm threats (STRIDE) and decide mitigations. A lightweight data-flow diagram plus STRIDE per boundary catches design flaws scanners never will.

Every identity — user, service, pipeline — gets only the permissions it needs, for as short a time as possible. It limits blast radius: a compromised component can do little, which underpins zero-trust and supply-chain defense.

Run a scanner like Trivy or Grype in CI and at the registry against the image’s packages and OS layers, failing the build on fixable criticals. Rescan continuously since new CVEs appear for images that have not changed.

trivy image --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 app:1

Run a lockfile-aware scanner in CI (Trivy fs, pip-audit, npm audit, Grype) so a known-vulnerable transitive dependency fails the build. The hard part is a failure policy the team keeps enabled, not the tooling.

pip-audit -r requirements.txt
npm audit --audit-level=high
trivy fs --scanners vuln .

Static IaC scanners (tfsec, checkov, KICS) analyze Terraform/CloudFormation/K8s manifests for insecure defaults — public buckets, open security groups, privileged Pods — in the pipeline before apply.

tfsec .
checkov -d . --compact
# also on the plan: conftest test plan.json

Pre-commit hooks and CI secret scanners (gitleaks, trufflehog) catch committed credentials; on a hit you rotate the secret immediately (history rewrite is not enough) and move it to a secrets manager. Prevention beats detection.

gitleaks detect --source . --redact
# on a hit: ROTATE the secret now; scrubbing git history is not enough

Fail only on high-confidence, fixable, reachable criticals; allow-list with expiry and justification for the rest; and give developers fast, actionable output. A gate that floods false positives gets disabled — tuning is the real work.

The failure mode is not missing a CVE — it is the team disabling a noisy gate. Start by failing on a narrow, high-signal set (fixable + critical + reachable), route the rest to a report, and require an expiring, justified exception to suppress anything. Ratchet up as noise drops.

A Software Bill of Materials lists every component and version in an artifact (SPDX or CycloneDX). It lets you answer "am I affected?" instantly when a new CVE like Log4Shell drops, instead of guessing.

Generate the SBOM at build time (from the actual image, not the source) and store it with the artifact. When the next Log4Shell lands, you query SBOMs across every service in minutes instead of grepping repos for days.

syft app:1 -o cyclonedx-json > sbom.json
grype sbom:sbom.json --fail-on high

Signing produces a verifiable cryptographic attestation that an artifact came from your build and was not tampered with. Cosign (Sigstore) signs container images/artifacts — with keyless signing tied to OIDC identity — and verifies them before deploy.

cosign sign app:1                      # keyless, uses OIDC identity
cosign verify app:1 --certificate-identity-regexp '.*@example.com' --certificate-oidc-issuer https://token.actions.githubusercontent.com

Enforce it at admission: a policy engine (Kyverno verifyImages, Sigstore policy-controller, or Gatekeeper) rejects any image without a valid signature from a trusted identity, so an unsigned or tampered image simply cannot run.

# in the cluster: policy blocks unsigned images
# in CI, as a hard gate before rollout:
cosign verify registry/app:1 --certificate-identity ... || exit 1

Provenance is signed metadata describing how, from what sources, and by which builder an artifact was produced. SLSA is a tiered framework of build-integrity requirements; higher tiers make provenance non-falsifiable so consumers can trust origin.

Provenance answers "was this built from the commit I think, by a builder I trust?" SLSA levels raise the bar: scripted builds, then a hardened isolated builder that signs provenance the build itself cannot forge — which is what defeats a compromised build step.

Attackers target the build system and maintainer trust, not just your code: SolarWinds injected malware in the build pipeline; xz was a backdoor slipped in by a trusted maintainer. The lessons are hermetic/verifiable builds, signed provenance, and scrutiny of dependency maintainership.

Pin dependencies by version and hash (lockfiles), vet new packages, use private proxies/allow-lists to blunt typosquatting and dependency confusion, verify signatures, and monitor advisories — the dependency tree is your largest attack surface.

Dependency confusion works by publishing a public package with your internal name at a higher version; a private proxy/registry with an allow-list defeats it. Pin by hash so a re-published bad version cannot slip in, and prefer few, well-maintained dependencies.

Detecting malicious behavior in running workloads — unexpected syscalls, shells in containers, file/network anomalies. Falco (eBPF/kernel) watches syscalls against rules and alerts, catching attacks that static scanning at build time cannot.

Build-time scanning cannot see a container that is compromised at runtime. Falco taps the kernel via eBPF and matches syscalls against rules — a shell spawned in a container, an unexpected outbound connection, a write to /etc — and alerts or triggers response.

- rule: Shell in a container
  condition: spawned_process and container and proc.name in (bash, sh)
  output: "shell in container (pod=%k8s.pod.name user=%user.name)"
  priority: WARNING

Rank by real risk, not raw severity: is the vulnerable code reachable, is the asset exposed to the internet, is there a known exploit (KEV/EPSS), and what is the blast radius? Fix a reachable, exploited, internet-facing issue before an unreachable 9.8.

No implicit trust from network location — every request is authenticated, authorized, and encrypted (mTLS), with least privilege and continuous verification. Identity, not the perimeter, becomes the control plane.

Concretely: workloads get cryptographic identities (SPIFFE/mTLS via a mesh), every call is authorized per-request against policy, and access is short-lived and least-privilege. A breach of one service does not grant lateral movement because the network itself trusts nothing.

Security champions in each team, guardrails and paved roads that make the secure path the easy path, self-service scanning with fast feedback, and threat modeling as a habit — so security is shared ownership, not a gate at the end.

The lever is making secure the default: golden pipelines with scanning built in, hardened base images teams inherit, and platform guardrails, so a developer does the right thing without being a security expert. Champions scale the security team; blocking gates alone breed resentment and workarounds.

Layered controls so no single failure is fatal: hardened images, least-privilege IAM/RBAC, network policy and mTLS, admission and runtime policy, secrets management, scanning and signing in CI, and monitoring/response. Assume any one layer can fail.