DevSecOps & supply-chain security interview questions

It's moving security earlier into design and development — threat modeling, linting, and CI scanning — so issues are cheap to fix, instead of waiting for a late pen-test or a production incident.

design → threat model
code   → SAST / secret scan / lint
CI     → SCA, image scan, IaC, sign
prod   → admission, runtime, monitor

SAST looks at source or bytecode without running it. DAST attacks a running app from the outside. SCA finds known CVEs in third-party deps. IAST instruments the running app to watch real code paths. They catch complementary classes of bugs — I wouldn't pick just one.

SAST  → Semgrep, CodeQL (your code)
SCA   → npm audit, pip-audit, Trivy fs
DAST  → ZAP / Burp against a URL
IAST  → agent inside the app runtime

A CVE IDs a public vulnerability; CVSS scores it 0–10 on exploitability and impact. I wouldn't prioritize on score alone — I'd weigh reachability, exposure, and exploit signals like EPSS and CISA KEV. An unreachable 9.8 can wait longer than a reachable 6.5 on a public login path.

1) in CISA KEV or high EPSS?
2) reachable from your code / internet-facing?
3) fixable version available?
4) then CVSS as a tie-breaker

Every identity — human, service, pipeline — gets only the permissions it needs for the shortest time. That limits blast radius when something is compromised, and it's the foundation under zero-trust and supply-chain defense.

# Prefer OIDC short-lived cloud roles scoped to repo+branch
# over long-lived access keys stored as CI secrets

It's systematically asking what can go wrong before you build: draw trust boundaries and data flows, brainstorm threats (e.g. STRIDE), and decide mitigations. It catches design flaws scanners will never see.

# 60-minute PRD review:
# - what's sensitive? who can call what?
# - spoofing / tampering / repudiation / info disclosure / DoS / elevation
# - ticket mitigations before coding starts

I'd say DevSecOps embeds automated controls and shared ownership into the delivery path so security is continuous feedback, not a release-week veto. Security still sets the bar; engineering owns fixing inside the sprint.

golden pipeline template:
  secret-scan → sast → sca → build → image-scan → sign → deploy

I'd run Trivy/Grype against the built image (and continuously in the registry), failing on fixable high/criticals. Rescan matters — new CVEs appear for images that have not changed.

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

I'd use lockfile-aware scanners in CI (pip-audit, npm audit, Trivy fs, Grype) so vulnerable transitive deps fail the build. The hard part is a failure policy the team keeps enabled — not installing another tool.

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

I'd run static scanners — Checkov, tfsec, KICS — and Conftest on Terraform plans and K8s YAML so public buckets, open security groups, and privileged Pods fail in the pipeline before apply.

checkov -d . --compact
tfsec .
terraform show -json plan.out | conftest test -

I'd block merges with pre-commit plus CI scanners like gitleaks or trufflehog. On a hit, rotate the credential immediately — rewriting history isn't enough — and move secrets into a manager.

gitleaks detect --source . --redact
# HIT → rotate in IdP/cloud NOW → revoke old → store in Vault/SM

I'd narrow to high-confidence rules, fail only on actionable findings with clear remediations, add suppressions with expiry and owner, and measure reopen/disable rates. A quieter gate that stays on beats a loud one that's bypassed.

Noise kills shift-left. Start with curated rule packs (OWASP top classes you actually see), exclude generated code, and require every suppression to have reason + expiry in Git. Separate “break build” from “report only” severities. Publish mean-time-to-fix and false-positive rate as team metrics. Pair SAST with codeowners so the right people see findings. Re-enable gradually: one rule family at a time. What I want them to hear is you optimize for sustained adoption, not scanner marketing counts.

# .semgrepignore / inline nosemgrep with ticket + expiry
# CI fails only on rules tagged confidence:high severity:ERROR

Interviewer often follows with: How would you prove the gate still catches real bugs after quieting it?

I'd fail on fixable, reachable, high-confidence criticals; route the rest to dashboards; require expiring justified exceptions; and give fast local/CI feedback. Then ratchet severity up as noise drops.

Policy design is basically product management — SLOs for scan duration, clear ownership of CVE backlog, and exception workflows that security can audit. Prefer deny-lists of known-bad packages and KEV-driven emergency fails. For containers, ignore-unfixed avoids impossible work while you track base-image refresh. I never make 'critical CVSS' alone the only gate without reachability/KEV context or you train people to ignore red builds.

# week 1: fail KEV + critical fixable in direct deps
# week 4: add transitive highs with available patches
# exceptions.yaml: cve, owner, expiresOn, compensating_control

Interviewer often follows with: What compensating controls make a temporary CVE exception acceptable?

An SBOM is a Software Bill of Materials — components and versions in an artifact, usually SPDX or CycloneDX. I generate it from the built image so when the next Log4Shell drops I can answer 'are we affected?' in minutes.

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

I'd sign in CI with cosign (preferably keyless OIDC identity), store signatures/attestations in the registry, verify again in the deploy pipeline, and enforce at admission so unsigned images can't schedule even if someone bypasses CI.

Keyless signing ties the signature to the workflow identity (repo, ref, actor) via a short-lived cert — no long-lived cosign keys to leak. Pin `certificate-identity` / OIDC issuer in verify policies. Attest SBOMs and provenance (SLSA) alongside the image. Admission (Kyverno verifyImages, Sigstore policy-controller) is the hard gate; CI verify is the fast feedback. Rotate trust by updating policy allowlists, not by hoping old keys disappear. Mutable tags undermine signing — promote digests.

cosign sign app@sha256:abc…     # keyless in GitHub Actions OIDC
cosign verify app@sha256:abc… \
  --certificate-identity-regexp '.*@example.com' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Interviewer often follows with: How would you handle emergency hotfixes when the signing pipeline is down?

Provenance is signed metadata about how, from what source, and by which builder an artifact was produced. SLSA tiers raise integrity requirements so consumers can trust origin — higher levels need hardened builders that can't forge their own provenance.

Provenance answers “was this built from commit X by builder Y I trust?” SLSA level progression: documented process → scripted builds → hardened isolated builder that signs provenance the build step can't forge. That defeats a class of compromised CI steps that produce “clean” looking artifacts. Verification belongs in admission/CD: reject missing or mismatched provenance. Pair with hermetic builds and locked dependencies so the provenance is meaningful.

cosign verify-attestation --type slsaprovenance app@sha256:abc…
# policy: builder identity must match org's GitHub Actions workflow

Interviewer often follows with: What stops a malicious workflow in a forked PR from producing “valid” keyless signatures?

Attackers target build systems and maintainer trust, not only your application code. I'd defend with hermetic, verifiable builds, signed provenance, least-privilege CI, and scrutiny of dependency maintainership — not just CVE scanning.

SolarWinds showed a poisoned pipeline can ship trusted updates; xz showed social engineering of maintainership. Scanners wouldn't have saved you if the malicious code was the intended release. Controls: isolated builders, two-party review on release workflows, pin actions by SHA, disable privileged fork workflows, reproducible builds where feasible, and monitor for anomalous maintainer changes on critical deps. SBOMs help response; provenance + identity help prevention.

pin actions to SHA
OIDC to cloud (no long-lived keys)
no secrets on pull_request from forks
sign + attest + admit-time verify

Interviewer often follows with: How would you detect a malicious GitHub Action behaving like a clean build?

I'd pin versions and hashes via lockfiles, use a private proxy with allow-lists so internal names can't be hijacked from the public registry, vet new packages, and prefer few well-maintained dependencies.

# internal scope @acme/* only from private registry
# public packages via pull-through with firewall rules
# lockfile + npm ci / pip hash checking in CI

I'd expect runtime detection like Falco (eBPF syscall rules) to alert on shell spawn / unexpected egress, plus NetworkPolicy egress defaults, read-only rootfs, and dropped capabilities so the blast radius is small while humans respond.

Build-time scanning can't see post-exploit behavior. Falco/eBPF watches syscalls: shell in container, write to /etc, unexpected outbound DNS. Tune rules to reduce noise; route high-severity to page, rest to SIEM. Pair with PSS restricted, no privilege escalation, and egress NetworkPolicies. Response: isolate the Pod/node, snapshot for forensics, rotate credentials the workload could reach, and patch the entry point. Admission and signing still matter — runtime is the last layer, not the first.

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

Interviewer often follows with: How would you distinguish a legit kubectl exec debug session from an attacker shell?

Rank by real risk: KEV/EPSS, reachability, internet exposure, asset criticality, and fix availability — not raw CVSS order. Fix reachable exploited issues on crown-jewel services first; accept or defer the rest with recorded rationale.

Backlogs explode when every scanner finding is equal. Build a risk queue: (1) KEV present (2) public-facing + high EPSS (3) reachable in your call graph (4) privileged context (5) everything else. Automate reachability where tools allow; otherwise sample by service tier. Time-box “fix all criticals” mandates — they create exception theater. Report MTTR for KEV items as the executive metric. Risk acceptance is explicit, owned, and expired — not silent ignore.

priority=P0: KEV or known wormable + exposed
P1: reachable high on tier-0 services
P2: fixable highs with patch, scheduled
P3: accepted with owner + review date

Interviewer often follows with: How would you handle a critical CVE in a base image you don't control yet?

A deliberate, time-bounded decision to run with a known risk, documented with owner, rationale, compensating controls, and expiry — reviewed, not ignored. It's a governance artifact, not a way to silence scanners forever.

Good acceptance tickets include: asset, vulnerability, business justification, compensating controls (WAF, disable feature, network isolate), residual risk, expiry, and approving authority. CI suppressions should link to that ticket and fail when expired. Security aggregates acceptances for audit. Bad permanent `.trivyignore` without owners. Expert interview answer ties acceptance to error budgets / product risk, not just security theater.

cve: CVE-2026-1234
service: billing-api
owner: billing-oncall
compensating: not reachable; egress denied
expiresOn: 2026-10-01
ticket: SEC-4412

Interviewer often follows with: Who should be allowed to approve production risk acceptance in your org?

Champions are engineers in each team with extra training and a direct line to security — they review designs, triage scanner noise, and spread paved-road patterns. Scale comes from multipliers and golden paths, not central ticket bottlenecks.

Champions need time allocation, a community (office hours, Slack), and authority to block clearly dangerous patterns. Feed them threat-model templates, secure defaults (hardened base images, pipeline templates), and recognition. Measure champion-led fixes and reduction in repeated finding classes. Avoid making champions unpaid gatekeepers for every PR — focus on high-risk changes and mentoring. Pair with platform guardrails so the default path is already secure.

monthly: top CVE classes + one threat-model demo
per team: own suppressions + secure pipeline template
security: office hours + escalate path for P0

Interviewer often follows with: How would you keep champions from burning out or becoming shadow security reviewers for everything?

No trust from network location alone — every request and every pipeline step is authenticated, authorized, and least-privilege. Identity (workload + human) is the control plane; mTLS, short-lived creds, and continuous verification replace flat VPN trust.

Concretely for delivery: OIDC from CI to cloud (no static keys), signed artifacts verified at admission, SPIFFE/mTLS between services, per-request authz (OPA), and segmented networks as a backstop not the only control. Developers access prod through audited break-glass, not standing admin kubeconfig. Zero trust is a program of identities and policies — buying a vendor alone doesn't implement it. Tie to DevSecOps by making the paved road issue identities and verify signatures automatically.

CI OIDC → cloud role (repo/branch conditioned)
cosign sign → registry
admission verifyImages → schedule
runtime mTLS + Falco → detect

Interviewer often follows with: Where do people fake zero trust while still using long-lived cluster-admin kubeconfigs?

Layer controls so one failure isn't fatal: hardened non-root image, SBOM+scan+sign in CI, PSS/admission policy, least-privilege RBAC and NetworkPolicy, secrets from a manager, runtime detection, and monitored SLOs — assume any single layer can fail.

Map layers to kill chain stages: prevent bad code (SAST/SCA), prevent bad artifacts (sign/provenance), prevent bad schedules (admission/PSS), limit blast radius (RBAC, NetPol, mTLS), detect escape (Falco), respond (runbooks, revoke). GitOps keeps the desired hardened state honest. Interviewers want explicit layers and what each stops — not a buzzword list. Call out etcd encryption and backup as part of the secrets/data layer.

image (non-root, minimal)
CI (SCA/SAST/scan/sign)
admit (PSS + verifyImages)
identity (SA RBAC + NetPol)
runtime (Falco) + respond

Interviewer often follows with: Which layer do you invest in first for a greenfield team with three engineers?

I'd run lightweight smoke DAST on every deploy to staging; run deeper authenticated scans on a schedule or pre-release. Fail the release on high-confidence findings with known exploit paths; don't block every PR on a 40-minute crawl.

PR: Semgrep + SCA (minutes)
staging deploy: ZAP baseline against /health and login
nightly: full authenticated ZAP/Burp suite → tickets

I'd put secret scan, SAST, SCA, build, image scan, sign, and deploy gates in a reusable template every team inherits — so the secure path is the default path, not a wiki they skip.

secret-scan → sast → sca → test → build → image-scan → sbom → sign → deploy

EPSS estimates the probability a CVE will be exploited in the wild soon. I use it with CVSS and KEV — a medium CVSS with high EPSS on a reachable path often jumps the queue ahead of an unreachable critical.

# Priority bump if:
# - CISA KEV listed, OR
# - EPSS above your threshold (e.g. 0.5) AND reachable

I'd treat runners as production: ephemeral VMs/containers, no long-lived cloud keys, isolated networks, patched images, restricted who can run privileged workflows, and never reuse the same runner pool for untrusted fork PRs and prod deploys.

Poisoned pipeline execution thrives on shared, over-privileged runners. Separate trust tiers: untrusted PR runners without secrets; trusted release runners with OIDC and signing. Disable `pull_request_target` anti-patterns, pin actions by SHA, and monitor runner egress. Hardened runners are as important as app SAST — a compromised runner can mint signed “trusted” artifacts if signing keys/OIDC roles are reachable.

fork PR jobs: no secrets, network-limited runner
main release: OIDC role + cosign, no fork code execution

Interviewer often follows with: What is a pwn request / poisoned pipeline execution?

New CVEs land against unchanged images. I'd rescan the registry continuously and rebuild or rebase when fixable criticals appear — a one-shot CI scan isn't enough.

trivy image --exit-code 1 registry/app@sha256:abc
# cron / registry scanner over all prod tags

Cap open exceptions, require expiry and compensating controls, report exception age to leadership, and auto-fail expired waivers in CI. Measure KEV MTTR, not waiver count.

Unlimited waivers recreate the pre-DevSecOps status quo. Governance: max active waivers per service tier, monthly review board, and dashboards of waiver debt. Pair with investment in base-image maintenance so teams aren't forced to waive unfixable noise. Cultural The fix: praise closed KEVs and reduced mean age of criticals. In an expert interview I want metrics + incentives, not another scanner.

# parser fails build if exceptions.yaml expiresOn < today
# report: P95 age of open critical exceptions

Interviewer often follows with: How would you handle a vendor dependency with no patch for 180 days?

Scanning looks for known vulns in the contents. Signing proves who built it and that it hasn't been tampered with. I'd do both — a signed image can still be full of CVEs, and a clean scan doesn't prove provenance.

trivy image app@sha256:abc   # content risk
cosign verify app@sha256:abc # origin/integrity

It's embedding security into how you build and ship — automated controls, shared ownership — so you don't bolt it on as a release-week gate.

code → SAST/secrets scan → build → SCA/SBOM → sign → deploy policy → runtime detect

A CVE is a public vulnerability ID. Severity — usually CVSS — is a starting score, not a priority by itself. In practice I triage with reachability, exposure, and exploitability signals.

# 1) Known Exploited (KEV) + internet-facing
# 2) critical/high with exploit + sensitive data
# 3) the rest by SLA

SAST analyzes your code without running it, DAST probes a running app from outside, SCA finds known vulns in dependencies. They're complementary — I wouldn't treat them as interchangeable.

SAST: pull request (Semgrep)
SCA:  lockfile + image (Trivy/Grype)
DAST: staging URL (ZAP) after deploy

Query stored SBOMs/attestations for the affected package/version, page owners of hits on internet-facing tiers, patch or mitigate, and verify with a fresh SBOM after rebuild — hours, not days of grepping repos.

Prerequisite is generating and indexing SBOMs at build (Syft/Trivy) and retaining them beside digests. Response playbook: identify CPE/PURL, search inventory, classify exposure, ship fixes via golden base images where possible, and communicate customer impact. Without SBOMs you rediscover ownership manually. Pair with admission that prefers digests you have SBOMs for. This is a classic senior supply-chain question after Log4Shell.

grype sbom:sbom.json --fail-on critical
# or central inventory: SELECT service WHERE pkg=log4j AND ver < fixed

Interviewer often follows with: Where do you store SBOMs so incident responders can find them at 2am?

Patch with parameterized queries, add a regression test or scanner regression case, deploy behind staging DAST smoke, and consider a WAF rule as compensating control while you harden related queries.

Legacy constraints tempt “just suppress.” Prefer fix + minimal characterization test. If a full rewrite is impossible, mitigate with input validation at the edge, least-privilege DB creds, and monitoring for SQLi patterns. Track as risk acceptance only if fix is truly deferred with expiry. Interviewers want layered mitigation and a path to delete the waiver.

# bad: query = "SELECT * FROM u WHERE id=" + userInput
# good: parameterized statement / ORM binder
# add Semgrep regression + staging ZAP smoke on the route

Interviewer often follows with: When is a WAF rule an acceptable long-term control versus a bridge?

I scope exceptions to break-glass identities/namespaces with expiry, require ticketed ephemeral debug (ephemeral containers), and keep exec-into-prod noisy by design for everyone else.

Runtime rules that allow kubectl exec everywhere teach teams to ignore Falco. deny/alert on shell in prod app namespaces; allow only in a debug Namespace or via audited break-glass role; prefer ephemeral containers with short TTL. Tune rules for known sidecars. Measure alert precision weekly. exceptions as products with owners, not silenced rules.

# alert: spawned shell in container (prod)
# exception: role=incident-commander AND ns=debug-* OR annotation allow-exec=true (TTL)

Interviewer often follows with: Why are ephemeral containers preferable to docker exec on the node?

I patch the golden base once, rebuild dependents in waves by exposure tier, block new deploys of vulnerable digests at admission, and track KEV MTTR as the KPI.

Rebuilding 200 repos ad-hoc fails. Platform move: rebuild and resign the golden base, auto-PRs or image automation for consumers, prioritize internet-facing and data-tier services, and use admission/cosign policies to refuse old bases after a deadline. Communicate freeze windows. Offer a short exception with expiry for non-exposed internal tools. golden image + admission deadline + tiered waves.

# after T+72h: verifyImages / policy denies bases older than patched digest
# dashboard: % services on patched base

Interviewer often follows with: How would you handle a service that can't rebuild because of a broken upstream?

Signature proves who signed with a key/identity, not that the build was hermetic — I require provenance/SLSA attestations bound to a trusted builder identity and verify those before deploy.

Keyful signing on a shared mutable runner is weak: malware in the builder signs malware. Mitigations: hermetic/reproducible builds, isolated builders, provenance attestations (SLSA), and policy that checks builder identity ( Fulcio/GitHub workflow identity ), not only “sig exists.” Compare SBOM to source. Rotate if builder compromise suspected. separate integrity (signature) from build trustworthiness (provenance).

cosign verify-attestation --type slsaprovenance registry/app@$DIGEST
# policy: builder identity must be repo/workflow allow-list

Interviewer often follows with: What changes between SLSA L2 and L3 that matters here?

I refuse silent merge: require a time-boxed risk acceptance with owner, compensating controls, monitoring, and a tracked removal ticket — or offer a safer alternative (custom CA, mTLS) that unblocks the feature.

DevSecOps is escalation and design, not only scanners. Document blast radius (MITM, credential theft), insist on expiry, and add detection (traffic to insecure endpoints). Prefer fixing trust stores. If leadership accepts risk, record it in the risk register. In an expert interview I want persuasion + alternatives + expiry, not pure veto theater.

risk: disable TLS verify to legacy vendor
owner: svc-team lead
expires: 2026-08-24
compensating: private network + allowlist + alert on dest
exit: vendor cert fix / custom CA

Interviewer often follows with: What compensating control is insufficient for disabling TLS verify on the public internet?

I isolate the node/workload (cordon/drain, network deny), preserve forensic evidence, rotate secrets the pod could reach, and patch the escape path — not reboot-wipe before capture if evidence matters.

Order: detect (Falco/runtime), contain (cordon, NetworkPolicy/cloud SG, pause scheduling), eradicate (kill malicious pods, patch CVE/misconfig like privileged+hostPath), recover (replace node), lessons. Assume cloud credentials and SA tokens are burned. Snapshot disks if legal/forensics require. containment before curiosity; evidence before rebuild when needed.

kubectl cordon <node>
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
# revoke IRSA/role sessions the pods used; rotate Vault leases

Interviewer often follows with: Which Kubernetes privileges most often enable escape to the host?

I measure precision, suppress with evidence (not vibes), fix noisy rules, publish MTTR/KEV dashboards that matter, and co-own backlog with teams until signal is credible again.

Noise destroys DevSecOps. Program: baseline false-positive rate, require every suppression to have reason+expiry, tune SAST rules on your stack, prefer SCA reachability when available, and celebrate closed real issues publicly. Stop vanity metrics (vulns closed by waiver). socio-technical fix — tooling quality + shared KPIs.

# weekly: true_positive / (true_positive + false_positive)
# target: >80% on SAST high before enforcing gate

Interviewer often follows with: When is a finding “false positive” versus “true positive, accepted risk”?

I triage by reachability, exposure, and KEV/EPSS — then either mitigate (WAF, remove package, alternate base), accept risk with expiry, or rebuild when a fix exists — never “ignore forever because unscored.”

No-fix criticals are common. is the package loaded/reachable? Internet-facing? In CISA KEV? Can you drop the component or switch distros? Compensating controls buy time; admission can still block if exploitability is high. Document owner, expiry, and re-scan trigger when a fixed version appears. Communicate product risk clearly — CVSS alone isn't the answer.

CVE-2026-XXXX  critical  no-fix
reachable: yes (httpd module loaded)
KEV/EPSS: elevated
action: migrate to distroless/alternate base OR risk-accept until T+14
ticket: SEC-9921 expires 2026-08-07

Interviewer often follows with: What changes if the same CVE is in an unreachable build-time-only tool deleted from the final image?

I switch to lockfile-aware SBOM generation that walks the full graph (Syft/Trivy/cdxgen on the built artifact), fail CI when the SBOM is incomplete, and scan that SBOM — not a hand-written package list.

Shallow SBOMs create false confidence. Generate from the built image or language lockfiles after resolve, emit CycloneDX/SPDX with transitive nodes, and feed the same document to SCA and admission. Attest the SBOM beside the image digest. Periodically diff “SBOM packages” vs “scanner findings” to catch generator gaps. SBOM quality is a control, not a checkbox file.

syft packages registry/app@$DIGEST -o cyclonedx-json > sbom.json
grype sbom:sbom.json --fail-on critical
cosign attest --predicate sbom.json --type cyclonedx ...

Interviewer often follows with: Why is generating an SBOM only from package.json without the lockfile dangerous?

Tags are mutable — verify must pin digest (image@sha256:…) or an immutable digest reference from the deploy manifest, never a floating tag alone.

cosign verify on a tag only checks whatever digest the tag currently points to at pull time; tag move = different bits under the same name. The fix: CI writes digest into GitOps, admission verifies that digest + signature/identity, and registry tag immutability where supported. Prefer keyless identities bound to repo/workflow. Pair with verify-images policies that reject tag-only refs.

# BAD
image: registry/app:prod
# GOOD
image: registry/app@sha256:abc123...
cosign verify registry/app@sha256:abc123...

Interviewer often follows with: How does an attestation (provenance) still help if someone can move tags?

I cut noise first — severity+fixability+reachability filters, suppressions with expiry, baseline existing debt — then re-enable blocking only on new high/criticals until precision is trustworthy.

A gate that always fails teaches people to skip checks. Program: measure false-positive rate, tune rules for your stack, fail only on new issues vs main (differential scanning), and time-box waivers. Publish a paved-road fixed set of rules. Reintroduce full backlog burn as a tracked epic, not a merge blocker. Culture: security owns scanner quality jointly with platform.

# block PR if NEW high/critical vs main
# backlog: weekly burn-down, not merge gate
# suppression: reason + owner + expires

Interviewer often follows with: When is “fail on any medium” appropriate versus harmful?

I tune rules and scopes — suppress known-good builder namespaces, keep prod shell-spawn hot, add exceptions with owners — then measure precision before touching paging thresholds.

Alert storms destroy runtime detection. Split environments: noisy rules in build namespaces become metrics-only; prod app namespaces stay high-signal (shell, sensitive mounts, unexpected network). Use allowlists for platform DaemonSets. Capacity: sidekick/queue so Falco itself stays healthy. Review top rules weekly. Deleting the sensor is the failure mode — retuning is the job.

# rule: Spawned shell in container
# priority: WARNING in ns=build-* (metrics only)
# priority: CRITICAL in ns=prod-* (page)
# exception: sa=incident-debug TTL=2h

Interviewer often follows with: What is the risk of a global Falco silence during an incident?

I revoke/rotate trust immediately, block admission of signatures from the bad key/identity, re-sign or rebuild from trusted builders, and hunt for images signed during the exposure window.

Compromise means signatures no longer prove integrity. Steps: revoke key in KMS/Cosign trust root or remove Fulcio/GitHub identity from policy allow-lists; fail closed on verify; invalidate suspicious digests; rotate any secrets that builders held; rebuild critical services on clean runners; forensics on CI logs. Prefer short-lived keyless identities to reduce blast radius next time. treat signing trust like production credentials — revoke first, explain later.

# policy: remove compromised key/identity from verifyImages allow-list
# admission: deny images signed only by revoked key
# CI: new keyless identity / rotated KMS key
# inventory: images signed between T0 and T_revoke

Interviewer often follows with: Why is “just generate a new key and keep accepting the old one” dangerous?

I tier controls: secrets and critical reachable CVEs stay merge-blocking; medium/low and docs paths become warn/async; trunk gets continuous scanning with SLO-bound debt.

One severity for all paths is why teams mutiny. Design: path filters (docs/, *.md skip SCA), differential vs full scans, severity×reachability matrix, and async tickets for non-blocking debt with age SLAs. Champions help teams fix real issues fast. Leadership dashboard shows blocked-PR time vs true-positive rate. DevSecOps optimizes for risk-reduced throughput, not maximum red X's.

block merge: secret scan hit OR reachable critical CVE
warn + ticket: medium SCA, style SAST
skip: docs/**, *.md (except secret scan)
nightly: full fleet rescan → backlog SLO

Interviewer often follows with: How would you stop warn-only findings from rotting forever?

Yes for the build supply chain — I scan and harden builders separately, use ephemeral runners, and make sure build tools can't reach production credentials.

Final-image green doesn't mean CI is safe. Compromised build agents sign and push trusted malware. Controls: patched AMIs/images for runners, SCA on builder images, network egress allowlists, OIDC short-lived cloud roles, no long-lived deploy keys. Separate build and runtime SBOMs. expand the trust boundary to the pipeline.

trivy image ci-runner:2026.07
# runner: ephemeral, no prod kubeconfig
# deploy via OIDC federated role from trusted workflow only

Interviewer often follows with: What attestation helps prove which builder produced a digest?

I correlate process tree, network destinations, binary hash, and node/pod timeline — confirm or dismiss with evidence, then tune the rule if it was noisy — never silence on vibes alone.

CPU can look “normal” on multi-core nodes while a small miner runs. Check Falco fields (proc, exe, connection), compare image layers to known binaries, inspect DNS/egress, and see if the pod was unexpected. If true: isolate, rotate, replace node if escape suspected. If false: refine rule (known sidecar paths). Feed outcomes back into precision metrics. detection quality is a loop, not a one-shot page.

# Falco: proc.name, fd.sip, container.image.repository
kubectl get po -o wide; kubectl describe po
# egress: DNS to mining pools? unexpected listen ports?
# hash exe vs image layer

Interviewer often follows with: When would you cordon the node even if CPU graphs look flat?

I rotate every exposed secret immediately, rebuild without secrets using BuildKit secret mounts or runtime injection, scrub/republish digests, and add a secret-scan gate that blocks this class of PR.

Layer history keeps secrets even after a later DELETE. Assume compromise: rotate cloud keys, tokens, and DB passwords; deny old digests at admission; force redeploy. Prevention-wise, secret scanning (gitleaks/trufflehog) on PR + image history checks, educative paved-road Dockerfile. Never “it was only staging.”

# 1) rotate credentials in Vault/IdP
# 2) rebuild with --secret id=npm,src=... (BuildKit)
# 3) cosign sign new digest; admit only new digest
# 4) gitleaks protect on every PR

Interviewer often follows with: Why is docker history evidence even after a multi-stage final scratch image?

I enforce verify-images fail-closed with HA webhooks, digest-pinned GitOps, and a ticketed break-glass Namespace or annotation with short TTL and audit — hotfixes still sign via a break-glass signer path.

Availability vs integrity: unsigned emergency images are a conscious exception. normal path keyless sign in CI; break-glass signer in a hardware-backed or tightly controlled identity; PolicyException TTL; alert on every exempt admit. Webhook HA so verify outage ≠ silent fail-open. write the break-glass runbook before the SEV-1.

# Kyverno verifyImages / policy controller: deny unsigned
# break-glass: annotation secops.io/unsigned-ok=ticket:INC-1 expires=2h
# alert: any admit with that annotation
# hotfix: sign with break-glass identity, still prefer signed

Interviewer often follows with: What secondary control still helps if someone bypasses verify during break-glass?

I usually warn rather than hard-block when reachability is high-confidence negative, still track upgrade, and reserve hard-block for KEV/internet-facing or uncertain reachability — and I document the reasoning.

Reachability reduces noise but isn't perfect (reflection, native code, future call paths). Policy: auto-waive only with tool confidence + human override for KEV; require upgrade within an SLO; re-open if code paths change. Prefer upgrading anyway when cost is low. nuanced risk > binary “all criticals fail.”

if KEV or public-facing: block
else if reachability=not-callable (high confidence): warn + 30d upgrade SLO
else: block critical / high-fixable

Interviewer often follows with: What makes reachability analysis wrong in polyglot or heavily reflective apps?