46 DevSecOps Interview Questions Real Teams Actually Ask in 2026

Shift-left means moving security checks earlier in the development lifecycle, into the IDE, the pre-commit hook, and the pull request, instead of only at a pentest before launch. The point is cost: a flaw caught in a PR review costs minutes to fix, the same flaw caught in production costs an incident.

The phrase gets misused constantly. Bolting a scanner onto CI and calling it "shift-left" without anyone triaging the output isn't shifting anything, it's just adding noise earlier. Shift-left only works if someone actually acts on what the earlier stage finds.

Secrets scanning and lint run pre-commit or on every push, cheap and fast. SAST and dependency (SCA) scanning run on the pull request, before merge, catching code-level and dependency issues while they're still cheap to fix. Container image scanning and SBOM generation happen at build time, once an artifact exists. DAST needs a running application, so it belongs against staging, not against source code that isn't deployed anywhere yet.

Order matters because running a 20-minute DAST scan on every commit is wasteful and slow, while skipping SAST until staging means you've already built and deployed a vulnerability that a five-minute PR check would've caught for free.

Signing a commit (with GPG or Sigstore's gitsign) proves who authored that specific change to the source. Signing an artifact, a container image with Cosign, for example, proves what was actually built and published wasn't tampered with somewhere between the commit and the registry. A legitimately-authored, properly-signed commit can still get built by a compromised pipeline into a tampered image, so one signature doesn't cover the other.

SAST analyzes source code without running it, looking for risky patterns like unsanitized input flowing into a query, and it runs on the pull request. DAST tests a running application from the outside, sending real requests and watching real responses, so it needs a deployed environment and runs against staging. SCA scans your dependencies, not your own code, against known vulnerability databases, and it runs continuously since new CVEs get published against libraries you already shipped.

IAST instruments the running application with an agent, combining static knowledge of the code with real runtime execution paths, catching things DAST misses because DAST has no visibility into what the code is actually doing internally. Teams skip it because it needs an agent embedded in the app runtime, adds latency, and the tooling maturity and licensing cost haven't made the case clearly enough against just running good SAST and DAST together.

Running as root, an unpinned base image tagged latest instead of a specific digest, and dev tools or a full shell baked into the final image are the usual defaults nobody set on purpose. The first thing I check is the USER line, or the lack of one, since it's a single line that tells you whether the team has thought about this at all.

If a container escape vulnerability ever gets exploited, root inside the container is a much shorter path to root on the shared host kernel than a non-root process would be. A surprising number of real container CVEs escalate through processes that assumed root access was fine, and that assumption is exactly what a non-root USER line removes.

FROM node:20-slim
RUN groupadd -r appgroup && useradd -r -g appgroup appuser
WORKDIR /app
COPY --chown=appuser:appgroup..
USER appuser
CMD ["node", "server.js"]

It's plaintext, long-lived, and easy to leak sideways: through a crash dump that captures the process environment, through a logging framework that accidentally prints env vars, or through a teammate's local.env file that ends up in a screenshot. It's not just "in git," it's sitting in more places than most people account for.

A secrets manager gives you centralized access control, an audit log of every single read, and automatic rotation. An encrypted config file is still fundamentally a static secret sitting somewhere, and the decryption key just becomes the new single point of failure, with no record of who actually read the secret or when.

DevSecOps means security work gets built into every stage of the software lifecycle instead of showing up as a single review gate right before release. In the old model, developers build and ship, then a separate security team reviews the design doc or the finished app weeks later, finds problems, and throws them back over the wall. That loop is slow, adversarial, and doesn't scale past a handful of teams.

In practice, DevSecOps looks like SAST and SCA scans running automatically on every pull request, security engineers writing reusable Terraform modules with hardened defaults so a developer gets a private S3 bucket and encrypted volumes without having to know the flags, and policy-as-code tools like OPA enforcing rules at admission time instead of a human checking a checklist. The security team's job shifts from being the last gate to being the people who build the guardrails developers use every day, and developers own the outcome of their own code instead of handing off risk to someone else.

Confidentiality, integrity, and availability. Confidentiality means only authorized people or systems can read the data. Integrity means the data hasn't been altered by someone who shouldn't have been able to touch it. Availability means the system and data are actually accessible to the people who legitimately need them, when they need them.

It matters because almost every security decision trades off between these three, and pretending you can maximize all three at once usually means you haven't thought it through. Full disk encryption protects confidentiality, but if the key management is bad you can lock yourself out of your own data and lose availability. Aggressive rate limiting protects availability against a denial-of-service attack, but set it too tight and you start blocking legitimate users. A good design decision names which of the three it's optimizing for and what it's willing to sacrifice, rather than assuming a control is free.

Authentication answers "who are you," and it's the part everyone thinks about first: passwords, API tokens, client certificates, MFA. Authorization answers "what are you allowed to do," and it's the part that gets skipped or half-built far more often. A service can have a rock-solid login flow and still be wide open if it stops at "is this token valid" and never checks whether the identity behind that token has permission for the specific resource being requested.

The classic place this goes wrong is an IDOR, an insecure direct object reference, where an endpoint like /api/invoices/1042 checks that you're logged in but never checks that invoice 1042 actually belongs to you. Change the number in the URL and you're reading someone else's invoice with a perfectly valid, perfectly authenticated session. Authentication got it right, authorization never ran at all.

CVSS, the Common Vulnerability Scoring System, produces a 0 to 10 base score built from metrics like attack vector (can it be exploited over the network or does it need local access), attack complexity, privileges required, user interaction needed, and how badly it damages confidentiality, integrity, and availability if exploited. A 9.8 gets labeled critical, a 4.0 gets labeled medium, and most vulnerability dashboards sort entirely on that number.

The disagreement happens because the base score describes the vulnerability in the abstract, not in your environment. A critical remote code execution bug in a parsing library you import but never actually call, running inside a service with no inbound network exposure, poses close to zero real risk to you even though the CVE says 9.8. CVSS has environmental and temporal scoring components meant to account for exactly this, but most scanners only surface the base score by default, which is why teams that just patch by CVSS number end up burning sprints on unreachable code while an actually exploitable medium-severity issue sits untouched.

Encryption in transit protects data while it's moving across a network, TLS between a browser and your API, mTLS between two internal services, so that anyone sitting on the wire between them sees ciphertext instead of a plaintext password or session token. Encryption at rest protects data sitting still, on a disk, in a database, in a backup snapshot, so that if someone gets physical or logical access to the storage layer itself, like a stolen laptop or a leaked S3 bucket, they still can't read it without the key.

You need both because they defend against completely different attackers. TLS does nothing to protect a database backup that gets copied off a misconfigured backup server. Disk encryption does nothing to stop someone sniffing unencrypted traffic on a shared network segment. A common gap in real setups is TLS terminating at a load balancer and traffic continuing in plaintext to the backend pods behind it, which teams often assume is encrypted end to end simply because the public-facing hop uses HTTPS.

The OWASP Top 10 is a ranked list of the most common and impactful web application security risks, built from real vulnerability data across a large sample of applications and refreshed every few years. Current entries include things like broken access control, cryptographic failures, injection, and insecure design. It's meant to give teams a shared, prioritized vocabulary for what actually causes breaches, rather than a theoretical list of everything that could go wrong.

Where teams go wrong is treating "we scanned for the OWASP Top 10, we're covered" as the end of the conversation. A scanner catches surface-level patterns like a SQL injection string reaching a query, but it can't catch something like insecure design, where the vulnerability is a missing business rule, not a broken line of code. The more useful way to use the list is as a prompt during design and code review, asking whether a new feature could introduce broken access control or an injection point before it's built, and as a baseline for what your SAST rules and PR checklist should actually be checking for.

In practice it's long-lived, over-permissioned credentials sitting in a pipeline: a static AWS access key stored as a repo secret with admin-level IAM permissions, shared across every job and every branch, that nobody rotates because rotating it would break three unrelated workflows (OWASP Top 10 CI/CD Security Risks).

The fix is federated, short-lived credentials instead of static keys. GitHub Actions and GitLab CI both support OIDC federation now, where the pipeline requests a temporary token scoped to one job, one repo, one environment, and that token expires in minutes whether or not anyone remembers to rotate it.

Almost always it's noise without triage. If a gate fires on every low-severity finding with no context on exploitability and no suggested fix, engineers learn that red means "annoying," not "dangerous," and they route around it the first chance they get.

Fix it by gating only on new findings above a real severity threshold, baselining the pre-existing debt separately, and attaching a suggested remediation to every blocking finding. A gate people trust gets respected. A gate people don't trust gets bypassed, and I'd rather have no gate than one everyone's learned to ignore.

Scope by job and by environment, not by pipeline. The build job gets read access to the registry and nothing else. The deploy-to-staging job gets a role that can only touch the staging namespace or account. The deploy-to-prod job, ideally gated behind a manual approval, gets its own narrowly-scoped role, issued fresh for that run through OIDC federation rather than a static key sitting in secrets the whole time.

A supply chain attack compromises something upstream of your own code, a build tool, a dependency, a CI plugin, so the malicious code rides along with something you trust and never triggers a code review of your own. The SolarWinds incident, disclosed in December 2020, is the reference case: attackers compromised the Orion build pipeline itself and inserted malicious code into a signed, legitimate software update that shipped to roughly 18,000 customers.

It changed the industry's thinking because the malicious code was in the build, not in a dependency version anyone could have pinned or reviewed. That's why provenance (proving what actually produced an artifact) matters as much now as scanning the artifact's contents.

Pin every third-party action to a full commit SHA, not a version tag, since tags can be moved to point at a different, malicious commit after the fact. Restrict which actions are allowed to run at all through an organization-level allowlist, and run untrusted or fork-triggered workflows on isolated runners with no access to repo secrets.

SLSA is a framework for grading how trustworthy a build's provenance actually is. The lowest level just requires that provenance metadata exists at all, describing what produced an artifact. Higher levels require that provenance to be generated automatically by a trusted build service (not something a developer can hand-edit), and eventually that the build itself runs in an isolated, hermetic environment where the inputs are fully controlled.

Most teams aren't anywhere near the top level, and that's a reasonable admission to make out loud in an interview rather than pretend otherwise.

Almost certainly no prioritization by severity or exploitability, and no distinction between new findings on this PR versus pre-existing debt nobody's touching today. 340 undifferentiated findings reads as noise, not signal, and engineers correctly learn to tune it out.

Fix it by baselining what already exists, gating only new findings above a real severity threshold, and layering in reachability analysis where it's available, so the report says "these three are new and actually exploitable" instead of "here are 340 things."

I don't think there's a single industry number everyone agrees on, but anywhere past roughly a third false positives and engineers start ignoring the tool wholesale, in my experience watching teams adopt these. You get there by tuning rulesets to your actual language and framework instead of running every default rule, and by suppressing (with a documented reason, not silently) known non-issues rather than leaving them to keep firing every scan.

SAST reasons about code paths it can see statically. It can't see a misconfigured security header, a session token that doesn't expire, or a business-logic flaw that only shows up when a real request actually exercises the running application with real state behind it. DAST catches exactly that class of issue because it's testing the deployed system, not the source.

It tells you that neither tool is a substitute for the other. SAST catches issues in code paths DAST's crawler might never reach at all; DAST catches issues that only exist once the code is actually running.

SCA parses your manifest and lockfiles, package.json, requirements.txt, go.mod, builds the full dependency tree including transitive dependencies, and cross-references every version against public vulnerability databases like the NVD or OSV. It doesn't care whether your own code is well-written, only whether a component you pulled in has a known, published CVE against the exact version you're running.

An SBOM is a formal, machine-readable inventory (usually CycloneDX or SPDX format) listing every component, library, and version that went into a shipped artifact, so anyone downstream can check it against newly-disclosed CVEs without re-scanning the binary from scratch. The push toward requiring one accelerated after a 2021 US executive order pushed federal software vendors toward producing them, and it's spread well beyond government contracts since, especially after incidents like Log4Shell showed how hard it was to even figure out who was running the affected library.

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

Severity alone isn't enough. A critical CVE in a library only reachable by an authenticated internal admin panel behind a VPN is a different risk than a medium finding on an internet-facing, unauthenticated endpoint. Block on severity combined with exploitability and exposure together; ticket, with a real SLA attached, anything where a compensating control already limits the blast radius.

PodSecurityPolicy was deprecated in Kubernetes 1.21 and removed entirely by 1.25, replaced by Pod Security Standards enforced through a built-in admission controller. Privileged allows anything, no restrictions at all. Baseline blocks known privilege-escalation paths like running privileged containers or mounting the host's process namespace. Restricted is the hardened tier: non-root required, no privilege escalation, a seccomp profile required, and capabilities dropped down to nothing by default.

This is close to the Restricted Pod Security Standard by hand. The three lines that matter most: runAsNonRoot, readOnlyRootFilesystem, and dropping all Linux capabilities instead of trusting the image's default.

securityContext:
 runAsNonRoot: true
 runAsUser: 10001
 readOnlyRootFilesystem: true
 allowPrivilegeEscalation: false
 capabilities:
  drop:
   - ALL

RBAC binds a subject, a user, group, or ServiceAccount, to a Role or ClusterRole that grants specific verbs on specific resources. Permissions accumulate over time as people add "just one more" rule to unblock something, and few teams ever go back and remove them. Tools like kubectl-who-can, or `kubectl auth can-i --list --as=system:serviceaccount:ns:name`, show you exactly what a given identity can actually do right now, which is the only reliable way to catch that creep.

Kubernetes networking is permissive by default. With no NetworkPolicy in place, any pod can reach any other pod or service in the cluster, across namespaces, not just within its own. A single compromised pod in an undefended namespace can reach your database, an internal admin API, anything else running, with nothing stopping it at the network layer.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: default-deny-all
 namespace: payments
spec:
 podSelector: {}
 policyTypes:
  - Ingress
  - Egress

A privileged container gets nearly all the capabilities of the host itself, including access to host devices and, in some cases, kernel modules, essentially erasing the isolation a container is supposed to provide. If it's compromised, you're not dealing with a container-level incident anymore, you're dealing with a straightforward host compromise, which is a much worse day.

Falco watches real syscalls as they happen, using eBPF or a kernel module, so it catches behavior that only exists once something's running: a shell spawned inside a container that never should have one, an unexpected outbound connection, a write to a sensitive path like /etc/shadow. An image scan checks what's sitting in the image at rest. An admission controller checks configuration at deploy time. Neither one is watching what the container actually does five minutes into runtime, which is exactly the gap Falco fills.

OPA Gatekeeper is an admission controller that evaluates every resource submitted to the API server against Rego policies before it's ever scheduled. A constraint requiring resource limits, or blocking privileged: true entirely, rejects a non-compliant Deployment at admission time, which is a fundamentally different guarantee than catching the same misconfiguration in a dashboard after it's already running.

violation[{"msg": msg}] {
 input.review.object.spec.containers[_].securityContext.privileged == true
 msg := "privileged containers are not allowed in this cluster"
}

Image signing protects against a tampered or unauthorized image running in your cluster even if its tag looks completely legitimate. Cosign signs an image at build time using a key (or keyless, tied to an OIDC identity), and an admission policy can require a valid signature from a trusted signer before anything schedules, so an attacker who somehow gets a malicious image into your registry still can't get it running without also compromising your signing keys.

cosign sign --yes registry.example.com/app@sha256:abc123
cosign verify --certificate-identity-regexp '.*' 
 --certificate-oidc-issuer https://token.actions.githubusercontent.com 
 registry.example.com/app@sha256:abc123

No. It's still in the git history, in reflogs, in anyone's local clone, and possibly in CI logs or cached build artifacts that already ran against it. Treat it as compromised the moment it's committed, rotate it immediately, and only then worry about rewriting history with something like git filter-repo, which is necessary but not sufficient on its own since the secret may already be cloned somewhere you don't control.

Instead of one static database password shared everywhere, Vault generates a unique, time-limited credential per request, tied to that specific lease. A leaked dynamic secret expires on its own within minutes or hours, and revocation is centralized through Vault rather than needing someone to hunt down every place a static key was ever copied to.

path "database/creds/readonly" {
 capabilities = ["read"]
}
# lease_duration and max_ttl are set on the role itself,
# e.g. 1h default, 4h max, then the credential auto-revokes

It means dropping the assumption that "inside the VPC" is a meaningful security boundary. Every request gets authenticated and authorized based on a verified identity, not its network location, typically through mTLS between services and short-lived certificates instead of long-lived network-perimeter trust. A service mesh like Istio or Linkerd is the common way teams actually enforce this at scale rather than hand-rolling it per service.

A public S3 bucket, a security group open to 0.0.0.0/0, an unencrypted volume, missing access logging, the kind of misconfiguration that looks syntactically identical to a safe line in a 300-line diff. A human skimming a pull request is checking whether the change does what it's supposed to; a scanner checks it against a specific ruleset every single time, without getting tired on line 280.

terraform plan -out=tfplan
checkov -f tfplan --compact

A security control is one specific safeguard, MFA required on admin accounts, for example. SOC 2 is an audit framework that checks a defined set of controls both exist and operate consistently over a period of time, evidenced by actual artifacts, not just a policy document. Tools like Vanta or Drata continuously pull that evidence, screenshots, API checks, log samples, instead of someone manually gathering it by hand once a quarter, which is why audit prep has shrunk from weeks to days at companies that adopt them.

Threat modeling is a structured exercise, STRIDE is the common framework, for identifying what could realistically go wrong in a system's design before or while it's built, and mapping each threat to a specific mitigation. It stops being useful the instant it's treated as a one-time deliverable for a design review sign-off, because a threat model describing a system that no longer matches what's actually deployed creates false confidence, which is arguably worse than having no threat model at all.

A tag is just a pointer, and the maintainer, or an attacker who's compromised the maintainer's account, can move that tag to point at a different commit without your pipeline noticing anything changed. That's roughly what happened with the tj-actions/changed-files compromise in March 2025: an attacker gained write access and modified the action to dump CI secrets into workflow logs, and every pipeline still referencing the tag by version rather than SHA pulled the malicious code automatically on its next run.

Pinning to a commit SHA means the exact code you audited is the exact code that runs, full stop, until you deliberately choose to update it.

Rotate every credential the pipeline touched, not just the one that was obviously compromised, since lateral movement from a build system is common. Revoke and reissue any signing keys used during the compromise window, and treat every artifact built in that window as untrusted until re-scanned and rebuilt from a known-good state.

Structurally, the real fix is usually adding mandatory signature verification at the admission layer so a future compromised build can push an image, but nothing will actually schedule it without a valid signature from a trusted key. Passing every gate and still shipping malicious code means the gates were checking the wrong thing.

Reachability analysis (modern tools like Snyk or OSV-Scanner do call-graph analysis to check this) tells you whether the vulnerable code path is actually invoked today, which is genuinely useful for triage priority. My honest opinion: patch it on your normal cadence anyway, because refactors can make an unreachable path reachable next quarter without anyone noticing, and an auditor asking about a critical CVE in your dependency tree usually doesn't care about reachability nuance. Deprioritize it relative to a reachable critical, don't ignore it.

Before assuming it's a scanning gap, check where in the process the 21 days is actually going. Usually it's not detection, scanners find things fast, it's triage and ownership: nobody's clearly assigned to a given dependency, or the fix requires a version bump that breaks something else and gets deprioritized behind feature work. It's also worth checking whether deploy cadence itself is the bottleneck, a patch sitting ready for a week because it's waiting for the next scheduled release train rather than shipping independently.

Isolate first, don't kill immediately: cordon the node or apply a NetworkPolicy that cuts off the pod's egress so it can't exfiltrate anything further, while preserving the running container for forensics rather than destroying the evidence by deleting it outright. Pull the process tree and check what actually spawned the shell, check the outbound IP against any threat intel available, and check what secrets or credentials were mounted into that pod, since they need rotating regardless of what the investigation eventually concludes.

Only after isolating and capturing forensics do you redeploy from a known-good image. Killing the pod first and asking questions later destroys the exact evidence you needed to figure out how it got in.

The cloud provider patches and secures etcd, the API server, and the scheduler. You're still responsible for worker node OS patching (unless you're on fully managed nodes like Fargate or GKE Autopilot), every workload-level configuration, RBAC, network policies, Pod Security Standards, secrets management, and the IAM integration between the cluster and the rest of your cloud account. A managed control plane doesn't mean a managed workload.

This is a classic credential-theft path through the instance metadata service at 169.254.169.254, and it usually means pods are inheriting the node's own IAM role rather than getting scoped credentials of their own. Enforce IMDSv2 (session-oriented, much harder to reach through basic SSRF) at the node level, and move to workload identity, IRSA on EKS or Workload Identity on GKE, so a pod gets a scoped, dedicated set of credentials instead of whatever the underlying node happens to have.

Most rulesets check specific, known misconfiguration patterns, bucket ACLs, the public access block settings, but a bucket policy statement granting access to Principal: "*" through a different mechanism can slip past a check written for the more common pattern. It's also worth checking whether the exposure is coming from a layer above storage entirely, a public API sitting in front of it, rather than the bucket configuration itself.

It has to come from a system of record set up in advance, the secrets manager's own rotation and access log, or a scheduled rotation job's execution history. If nobody set up logging for it before the audit, you genuinely can't manufacture that evidence retroactively. That's exactly why teams that take compliance seriously wire up rotation logging as infrastructure from day one, not as a scramble the week before an auditor asks.

Secrets scan and SAST run on every pull request, blocking merge on anything above medium severity. On merge to main, build a single artifact, generate an SBOM, run SCA against it, then sign the image with Cosign before pushing to the registry by digest, never by mutable tag. Deploy that exact signed artifact to staging, run DAST and integration tests there, then require a manual approval gate before production, with an admission controller verifying the signature before anything schedules.

jobs:
 build-scan-sign:
  runs-on: ubuntu-latest
  permissions:
   id-token: write
   contents: read
  steps:
   - uses: actions/checkout@v4
   - run: npm ci && npm audit --audit-level=high
   - run: docker build -t registry.example.com/payments-svc@${{ github.sha }}.
   - name: generate SBOM
    run: syft registry.example.com/payments-svc -o cyclonedx-json > sbom.json
   - name: sign image (OIDC keyless)
    run: cosign sign --yes registry.example.com/payments-svc@${{ github.sha }}
   - run: docker push registry.example.com/payments-svc@${{ github.sha }}

The detail interviewers listen for is deploying by digest with a verified signature, not a tag. A tag can move. A digest and a signature can't be quietly swapped out from under you.

Start from default-deny-all for the namespace, then add one explicit allow rule permitting ingress only from pods carrying the specific label of the one service that's supposed to connect, on exactly the database's port, nothing broader. Restrict egress from the database pod too, since a compromised database pod shouldn't be able to freely reach out to the internet to exfiltrate data even if the ingress side is locked down correctly.