← back to servbg.com

DevSecOps 2026 Reference

Comprehensive cheatsheet covering the modern DevSecOps stack as of mid-2026. Designed for senior engineers as a working reference and self-test.
Author: Paradox (servbg.com) Updated: May 2026 Audience: Senior engineers Time to read: ~45 min Print-friendly: yes

Contents

  1. What DevSecOps Actually Is
  2. Cloud-Native Security (CNAPP / CSPM / CWPP)
  3. Kubernetes Security
  4. Supply Chain Security
  5. Shift-Left Security (SAST/DAST/SCA/IaC)
  6. GitOps & CI/CD Security
  7. Secrets Management
  8. Identity & Zero Trust
  9. SIEM, Observability, SOC
  10. Compliance Automation
  11. AI Security (the 2026 wildcard)
  12. Interview Notes
  13. Quick-Reference Cheatsheet

1. What DevSecOps Actually Is

The category exists because security-after-the-fact stopped working.

DevSecOps is the practice of integrating security at every stage of the software delivery lifecycle, automated wherever possible, owned by the engineers building the system rather than bolted on by a separate team afterwards.

The category exists because two things happened simultaneously around 2015–2020:

  1. Software started shipping faster (CI/CD, multiple deploys per day) - too fast for periodic security reviews to keep up.
  2. Cloud and container infrastructure made the security perimeter a moving target - there is no longer a stable network boundary to defend.

The classic security model - review at gate, sign off, deploy - broke under those conditions. DevSecOps is the answer: shift security left (earlier in the SDLC), make it automatable, give engineers tools they can use themselves, and continuously monitor running systems for drift.

Core principles you should be ready to articulate

2. Cloud-Native Security (CNAPP / CSPM / CWPP / CIEM)

The hottest category in 2026. Tools that scan your cloud accounts continuously.

The acronym soup

The market is consolidating around CNAPP. If you're asked about modern cloud security, the right framing is: "We use a CNAPP that combines posture management, workload protection, and entitlement management against a unified asset graph."

Tools you should know by name

WizCurrent market leader. Agentless. Builds a security graph of your cloud. Most enterprise interviewers mention it.
LaceworkStrong CNAPP, anomaly-based runtime detection. Acquired by Fortinet in 2024.
Prisma CloudPalo Alto's CNAPP. Strong for shops already using Palo Alto stack.
Orca SecurityAgentless, side-scanning approach. Innovative architecture.
CrowdStrike Falcon CloudNatural extension if you already run Falcon EDR.
Microsoft Defender for CloudNative Azure option, multi-cloud support.
AWS Security Hub + GuardDuty + InspectorAWS-native option. Multiple services rather than one platform.
Sonrai / ErmeticCIEM specialists. Focused on identity and entitlements.
Self-test: questions & answers
  1. What's the difference between CSPM and CWPP?
    CSPM is pre-runtime: it scans cloud account configuration and flags misconfigurations like open S3 buckets or over-permissioned IAM roles before they're exploited. CWPP is runtime: it monitors the running workload itself - watching process behavior, file system changes, and network calls on the live VM or container. Both are necessary because a correctly configured host can still run compromised workloads, and a misconfigured environment is dangerous even when quiet.
  2. You inherit an AWS environment with 200+ accounts. How do you assess its current security posture?
    Enable AWS Security Hub with the AWS Foundational Security Best Practices standard across all accounts via AWS Organizations, so you get a centralized findings view immediately with no agent deployment. Layer GuardDuty for threat detection and Inspector for vulnerability scanning. Alongside that, run a CNAPP like Wiz or Orca in agentless mode against the account set to get a security graph showing lateral-movement paths and identity risks that AWS-native tooling misses. Triage by attack surface first: internet-facing resources, admin IAM roles, unencrypted data stores.
  3. How would you choose between agent-based and agentless cloud security?
    Agentless scanning (Wiz, Orca) gives fast, broad coverage with no operational overhead and no performance impact - critical for initial visibility in large environments or where deploying agents across 200 accounts is impractical. Agent-based approaches (Falco, CrowdStrike) give real-time runtime visibility that agentless snapshots cannot: you see the shell spawn as it happens, not in the next scan cycle. In practice, senior teams run both: agentless for posture and discovery, agents on production workloads where runtime detection latency matters.
  4. What's a "security graph" and why does it matter?
    A security graph is a data model that represents cloud assets as nodes and their relationships - network paths, IAM trust, data access - as edges. It matters because individual findings without context are low-signal: a public-facing EC2 with a vulnerable package is only critical if it has a path to your production database. The graph lets you ask "show me all attack paths from the internet to crown jewel data" and answer it in seconds. Wiz's core differentiator in 2026 is the quality of this graph and its query interface.
  5. How do you handle drift detection in an Infrastructure-as-Code-managed environment?
    Drift occurs when someone modifies infrastructure outside of IaC - a console click, an ad-hoc CLI command. Detection approaches: run terraform plan on a schedule and alert on non-empty plans; use AWS Config rules or CSPM continuous scanning to flag resources not tagged with a Terraform state origin; implement SCPs in AWS Organizations to block console changes on production accounts entirely. The real fix is preventing drift rather than detecting it: lock down direct access and force all changes through pull requests against the IaC repo.

3. Kubernetes Security

If the company runs k8s, this gets asked. Probably twice.

The four areas you must cover

3.1 Image security (build time)

3.2 Admission control (deploy time)

3.3 Runtime detection

3.4 Network policy & service mesh

Pod-level hardening checklist

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Pod Security Standards (replacement for the deprecated PodSecurityPolicy) define three levels: privileged, baseline, restricted. Production should be restricted.

Self-test: questions & answers
  1. Walk me through how a malicious image gets blocked in a hardened k8s pipeline - every checkpoint.
    First checkpoint: Trivy runs in CI and fails the build if the image has critical/high CVEs or embedded secrets. Second: cosign signs the image post-scan; the signature is the proof of policy passage. Third: at deploy time, an admission webhook (Gatekeeper or Kyverno) verifies the cosign signature and checks the pod spec against policies - rejects it if unsigned, privileged, missing resource limits, or using a disallowed registry. Fourth: at runtime, Falco watches syscalls and fires if the container spawns an unexpected shell or reads sensitive paths. Each layer is independent, so a bypass of one hits the next.
  2. OPA/Gatekeeper vs Kyverno - when would you pick which?
    Gatekeeper with Rego is the mature choice for organizations that need complex cross-resource policy logic, external data lookups, or already have OPA investment elsewhere in the stack (service meshes, Terraform). Rego has a learning curve but is genuinely more expressive. Kyverno in YAML is faster to adopt - a security-focused platform team can ship meaningful policies in hours, not days, and YAML is readable by developers who need to understand why their deployment was rejected. If your team is small or the policies are straightforward admission checks, Kyverno wins on operational simplicity.
  3. How does Falco actually detect suspicious behavior? What's the underlying mechanism?
    Falco uses an eBPF probe (or kernel module on older kernels) to hook into Linux syscalls at the kernel level without modifying the kernel itself. Every syscall the container makes is inspected against a rule engine; rules match on fields like process name, file path, network address, and container metadata. When a rule fires - for example, a shell spawns inside a container that should only run nginx - Falco emits an alert with full context: container ID, image, pod name, namespace, syscall arguments. The key insight is that eBPF runs in the kernel address space but in a sandboxed verifier, so it can observe everything without the overhead or risk of a kernel patch.
  4. You see a pod making unexpected outbound connections. Walk me through the investigation.
    Start with Falco or your network observability tool (Hubble if running Cilium) to confirm the destination IP, port, and which process inside the container initiated it. Check whether a NetworkPolicy should have blocked this path - if it did, the connection indicates a policy gap or a misconfigured egress rule. Pull the container image and run Trivy to check for known-malicious packages. Check if the pod's service account has unusual IAM bindings that could have been used for credential theft. Isolate the pod (add a deny-all NetworkPolicy label selector) while preserving the container filesystem for forensics - don't restart it immediately.
  5. What's the difference between PodSecurityPolicy and Pod Security Standards?
    PodSecurityPolicy (PSP) was a cluster-wide admission controller that required a PSP resource to be defined and bound to service accounts via RBAC - complex to configure correctly and removed in Kubernetes 1.25. Pod Security Standards (PSS) are a simpler, built-in replacement: three predefined levels (privileged, baseline, restricted) enforced via namespace labels, with no custom resources needed. PSS is less flexible than PSP for fine-grained control, but Kyverno or Gatekeeper can fill that gap. The migration path from PSP is to enable PSS enforcement on namespaces and add a policy engine for anything PSS doesn't cover.
  6. Why is readOnlyRootFilesystem: true a meaningful security control?
    Most post-exploitation techniques require writing to disk: dropping a second-stage payload, modifying a config file, installing a persistence mechanism, or writing a cron job. A read-only root filesystem eliminates the entire class of attacks that rely on filesystem writes to the container's root. An attacker who achieves code execution in the container cannot persist across a pod restart and cannot stage additional tooling. Writable directories (temp files, application logs) should be explicit emptyDir or PVC mounts, not exceptions to the root policy.

4. Supply Chain Security

Massive industry focus after SolarWinds, Log4j, xz. Must-know.

The mental model

Modern software depends on hundreds of third-party packages, each of which depends on hundreds more. A compromise anywhere in that tree compromises your application. Supply chain security is about knowing what's in your software, verifying it's authentic, and controlling what enters your build pipeline.

The frameworks

The tools

Sigstore / cosignSign and verify container images and artifacts using ephemeral keys. Free, OSS, the standard.
SyftGenerates SBOMs from container images, filesystems, archives. Produces CycloneDX or SPDX.
GrypeScans SBOMs (or images) for known vulnerabilities. Pairs with Syft.
Dependency-TrackOWASP project. Tracks SBOMs across your portfolio over time, alerts on new CVEs in your existing artifacts.
Chainguard ImagesDistroless minimal images, signed, with daily-rebuilt CVE-free base images. Increasingly adopted in 2026.
Renovate / DependabotAutomated dependency updates. Renovate (Mend) is more flexible; Dependabot is GitHub-native.

Practical SLSA Level 3 build pipeline

  1. Source pulled from a verified Git repo with signed commits.
  2. Build runs in a hermetic, isolated builder (GitHub Actions reusable workflow, Tekton, or similar).
  3. Builder produces an artifact + signed provenance attestation (in-toto format).
  4. Artifact + SBOM + provenance signed with cosign using ephemeral keys (Fulcio + Rekor).
  5. Deploy gates verify signature + check provenance + scan SBOM against vuln DB before allowing the artifact into production.
Self-test: questions & answers
  1. What's an SBOM and what would you actually do with one?
    An SBOM is a machine-readable inventory of every component in an artifact: libraries, versions, licenses, and their transitive dependencies. In practice you use it in three ways: feed it into Grype or Dependency-Track to scan for CVEs against your deployed artifacts continuously (so when Log4Shell drops you know in minutes which production images are affected); use it for license compliance audits to catch GPL code in a commercial product; and provide it to customers or regulators who require a component manifest. Generating it at build time with Syft and storing it alongside the image in your registry costs almost nothing and pays off the first time a critical CVE hits.
  2. SLSA Level 1 vs Level 3 - what changes operationally?
    Level 1 just requires a scripted build and provenance generation - low bar, basically "don't build on someone's laptop." Level 3 requires the build to be hermetic (no network access, no uncontrolled inputs), run in an isolated ephemeral environment, and produce cryptographically signed provenance that includes source commit hash, builder identity, and build parameters. Operationally this means migrating from ad-hoc CI scripts to GitHub Actions reusable workflows or Tekton chains, enforcing that the builder cannot be modified by the developer submitting the code, and wiring cosign + Rekor into your release gate. It's a meaningful operational lift but it's the level where supply chain compromise becomes genuinely difficult.
  3. How does Sigstore avoid the long-lived-signing-key problem?
    Traditional artifact signing requires managing a private key that never expires - it becomes a high-value target and a rotation headache. Sigstore instead issues ephemeral, short-lived signing certificates (via Fulcio) tied to a verifiable OIDC identity (your GitHub Actions workflow, your Google account). The certificate is valid for minutes, the signing event is logged immutably in Rekor (a transparency log), and verification works by checking that the certificate was valid at signing time and the log entry exists. There is no long-lived key to steal, rotate, or accidentally commit. This is why it's become the supply chain signing default in 2026.
  4. Walk me through how the xz backdoor (CVE-2024-3094) got in, and what supply chain controls would have caught it.
    A social-engineering campaign over two years planted a malicious maintainer into the xz project who added obfuscated backdoor code into the build scripts - not the source files that reviewers typically diff. It then landed in Debian and Fedora testing packages. SLSA Level 3 hermetic builds would have caught the build-time injection because the build environment would have been hash-pinned and reproducible - a deviation in output given identical inputs would be detectable. SBOM tooling with Dependency-Track would have flagged the new xz version at ingestion and triggered a diff review. Reproducible builds (matching output hash across independent build environments) are the deepest control - they make build-time injection nearly impossible to hide.
  5. Your CI/CD produces 200 artifacts a day. How do you know which ones are safe to deploy six months from now?
    At build time: attach a signed SBOM and cosign signature to every artifact, store both in your registry. At deploy time: policy gate verifies the signature is valid and the SBOM is present. For ongoing safety: feed all SBOMs into Dependency-Track, which continuously watches new CVE feeds and fires alerts when a newly published vulnerability affects a component in any stored SBOM. This means an artifact built cleanly six months ago gets flagged automatically when a CVE in one of its dependencies is published this week - without re-scanning the image. The signed SBOM is the persistent audit trail that makes this possible.

5. Shift-Left Security (SAST / DAST / SCA / IaC / Secrets)

The CI-pipeline scanner stack. Senior engineers need depth on every layer.

5.1 SAST - Static Application Security Testing

Scans source code for vulnerabilities without running it. Catches things like SQL injection patterns, hardcoded credentials, unsafe deserialization, weak crypto.

5.2 DAST - Dynamic Application Security Testing

Tests a running application by sending requests to it. Catches things SAST misses: auth flow flaws, business-logic vulns, runtime configuration issues.

5.3 SCA - Software Composition Analysis

Scans your dependency tree for known-vulnerable third-party packages. Cross-references your package.json / requirements.txt / go.mod against vuln databases.

5.4 IaC scanning

Scans Terraform, CloudFormation, Kubernetes YAML, Ansible for misconfigurations before they deploy.

5.5 Secrets scanning

Detects credentials, API keys, tokens accidentally committed to source code.

Real-world tip: the secrets-scanning value isn't catching new commits - pre-commit hooks already do that. The real value is scanning entire git history when you onboard a new repo. Two-year-old AWS keys still on Wednesday's commits get found by Gitleaks doing a full-history scan.
Self-test: questions & answers
  1. What can SAST never catch that DAST will?
    SAST only sees code paths and data flows statically; it cannot observe runtime behavior, environmental configuration, or the actual HTTP conversation. DAST catches broken authentication flows (session tokens that don't expire, CSRF gaps), business logic flaws that only emerge from specific request sequences, and server-side misconfigurations like missing security headers or permissive CORS policies. A classic example: SAST might identify a SQL concatenation but won't know whether your WAF or parameterized adapter downstream actually prevents injection. DAST probes the live behavior and tells you whether the vulnerability is exploitable as deployed.
  2. You're seeing 800 high-severity SAST findings. How do you triage?
    First, separate noise from signal: run the same ruleset against a test repo with known-good code to identify which rules produce false positives at scale, then suppress or tune those rules. Second, rank by exploitability: findings in code that handles external (unauthenticated) input rank above internal-only code paths. Third, prioritize by reachability if your SAST supports it - Snyk Code and Semgrep Pro can filter to findings where the vulnerable code is actually reachable from a call site. Finally, assign ownership by file/module - route findings to the team that owns the code rather than dumping 800 tickets into a single backlog. The goal is a triage process that delivers 20 actionable findings this sprint, not a perfect list of 800.
  3. How do you make Checkov run in the developer's local pre-commit, AND in CI, AND on existing infrastructure?
    For local pre-commit: add Checkov to .pre-commit-config.yaml using the pre-commit framework - developers run pre-commit install once and it fires on every git commit automatically. For CI: add a Checkov step in the pipeline that runs against the PR diff and comments findings inline using Checkov's GitHub Actions integration or SARIF output to GitHub Code Scanning. For existing infrastructure: run Checkov in a scheduled CI job against the full Terraform state directory or against a Terraform plan JSON (which reflects actual current configuration, not just what's in source). The key is consistent ruleset: pin the same Checkov version and custom check directory across all three contexts so findings are identical regardless of where they surface.
  4. What's the right pipeline order: SAST - SCA - DAST? Why?
    SAST first because it runs against source code with no running environment needed - fastest feedback, fails the build cheapest. SCA second, still at build time but requires resolved dependency lock files: flags known-vulnerable packages before the image is built or deployed. DAST last because it requires a deployed, running application - highest fidelity but highest cost to set up and slowest to run. Each layer gates the next: no point running DAST against code that already fails SAST checks, and no point deploying an image with a critical CVE just to DAST scan it. The ordering is "cheapest to run and fastest to give feedback first."
  5. A developer rotates an AWS key, but the old one was in a public commit. What's your incident response sequence?
    Treat it as compromised immediately regardless of when the commit was public. First: revoke the old key in AWS IAM right now, do not wait for rotation to propagate. Second: check CloudTrail for all API calls made with that key ID - look for calls from unexpected IPs, regions, or services, especially IAM privilege escalation or data exfiltration. Third: run Gitleaks against the full repo history to identify whether other secrets were committed in the same time window. Fourth: notify your security team and log the incident even if CloudTrail shows no suspicious use, because absence of evidence is not evidence of absence for sophisticated attackers who may have established persistence elsewhere.

6. GitOps & CI/CD Security

Pipeline becomes the new perimeter.

The GitOps pattern

Git is the single source of truth for both application code AND infrastructure/cluster state. Changes happen by merging pull requests; an agent in the cluster watches the repo and reconciles the cluster state to match Git. No kubectl apply from laptops. No "that one config someone made in production six months ago that nobody remembers."

Tools

CI/CD security must-haves in 2026

Self-test: questions & answers
  1. Why is OIDC-based authentication for CI pipelines better than IAM access keys?
    IAM access keys are long-lived credentials that can be stolen from CI environment variables, git history, or runner compromise and then used indefinitely from anywhere. OIDC tokens are issued per-job by the CI provider, last minutes, are tied to a specific workflow identity (e.g., only the main branch of repo X can assume this role), and are validated by AWS STS via a trust policy that specifies exactly which OIDC claims are permitted. There are no credentials to rotate, no secrets to store, and a stolen token is useless 15 minutes later. The operational overhead of setup is a one-time trust policy configuration.
  2. ArgoCD vs Flux - what's the meaningful difference?
    ArgoCD has a richer UI and opinionated application model (Application and AppProject CRDs) that makes multi-team, multi-cluster environments easier to manage visually and with RBAC. The app-of-apps pattern lets you manage a hierarchy of applications declaratively. Flux is more composable and CLI-first: it treats its components as independent controllers (source, kustomize, helm, notification) that you wire together, which makes it easier to embed in existing tooling but harder to get an at-a-glance picture across teams. Flux is also lighter on cluster resources. In practice, ArgoCD wins when the team needs visibility and self-service for multiple teams; Flux wins when you want minimal cluster footprint and tight GitOps primitives.
  3. What's the "app of apps" pattern in ArgoCD?
    App of apps is an ArgoCD pattern where a root Application object points to a Git directory containing other Application manifests, which ArgoCD then deploys recursively. This lets you manage an entire cluster's application portfolio as a Git-native hierarchy: the root app is the entry point, child apps are scoped per team or service. The security benefit is that onboarding a new application means merging a PR to the root apps directory, which is subject to the same branch protection and review policies as any other code change - no manual ArgoCD UI operations, full audit trail in Git.
  4. How do you ensure that what's running in production exactly matches what's in Git?
    ArgoCD and Flux both continuously reconcile: they detect drift between cluster state and the desired state in Git and either alert or auto-remediate. Enable hard enforcement mode so that manual kubectl changes are automatically reverted within seconds - this closes the "someone fixed something in prod and forgot to commit it" gap. Supplement with image tag pinning: reference image digests, not floating tags like :latest, so the Git manifest is deterministic. Finally, use cosign admission verification so the cluster refuses to run any image that doesn't have a valid signature from your build pipeline - ensuring even a direct kubectl apply with an arbitrary image is blocked at the admission layer.
  5. A malicious actor gets a developer's GitHub credentials. Walk me through what they can and can't do, and what stops them.
    With GitHub credentials they can push to feature branches and open PRs - branch protection on main requires additional reviewers to approve, so they cannot self-merge. Even if they compromise a reviewer (or create a branch with a misleading name), required status checks must pass including SAST, SCA, and secrets scans which would catch malicious payload additions. If they somehow get code merged, the CI pipeline runs under OIDC with a scoped IAM role - they can't exfiltrate long-lived cloud credentials from the pipeline. If the CI job produces an artifact, it must be cosign-signed with an ephemeral key tied to the workflow identity, and the cluster admission webhook verifies that signature before running it. The attacker faces at minimum four independent controls, each requiring separate compromise.

7. Secrets Management

Vault is the must-know. The concepts matter more than the product.

The big ideas

Tools

HashiCorp VaultEnterprise standard. Dynamic secrets, transit encryption, PKI. Must-know.
AWS Secrets ManagerCloud-native AWS option. Auto-rotation. KMS-backed.
AWS SSM Parameter StoreCheaper than Secrets Manager for non-rotating values. Underused.
Azure Key VaultAzure-native. Strong RBAC.
External Secrets OperatorBridges k8s Secret resources with external vaults. Declarative, GitOps-friendly.
Doppler / InfisicalSaaS alternatives. Simpler than Vault but less powerful.
SOPSEncrypted files in Git. Mozilla project. Common for IaC repos.
Self-test: questions & answers
  1. What's a "dynamic secret" and why is it superior to a rotated static secret?
    A dynamic secret is generated on-demand by Vault for a specific requester, with a short TTL (minutes to hours), and automatically revoked when the lease expires. A rotated static secret is a fixed credential that gets replaced on a schedule - but between rotations it's long-lived, and rotation requires every consumer to pick up the new value simultaneously or face downtime. With dynamic secrets, the blast radius of a compromise is bounded by the TTL: the credential is useless after an hour with no manual intervention. Additionally, each consumer gets a unique credential, so you can trace which workload's credential was used in a suspicious API call - something impossible with a shared rotated secret.
  2. How does a k8s pod authenticate to Vault without a static token?
    Vault's Kubernetes auth method uses the pod's projected service account JWT token - automatically mounted at a known path in the pod - as proof of identity. Vault validates the JWT against the k8s API server, checks that the service account is bound to a Vault role in its configuration, and issues a short-lived Vault token with the appropriate policies. The pod never has a long-lived Vault token stored anywhere - it re-authenticates on startup using the k8s-issued JWT. SPIFFE/SPIRE takes this further by issuing an X.509 SVID (short-lived certificate) as the workload identity credential, which Vault can also consume via its OIDC or cert auth methods.
  3. Vault is down. Your application can't fetch DB credentials. What's your fallback strategy?
    Design for Vault unavailability rather than assuming high availability is sufficient. The primary mitigation is caching: the Vault Agent (a sidecar) caches the current secret in memory and can serve it to the app even when Vault is unreachable, within the lease TTL. For longer outages, applications can cache the last-known-good secret to an in-memory store with a graceful degradation mode. Vault's HA setup (with Raft storage and standby nodes) handles most transient failures. For catastrophic Vault loss, DR means restoring from a Vault snapshot - which is why automated Vault snapshots to object storage are a day-one operational requirement, not an afterthought.
  4. What's the difference between encryption at rest and Vault's transit secrets engine?
    Encryption at rest is handled by the storage layer - the disk or database encrypts data with a key it manages, protecting against physical media theft. Your application never touches keys; the database decrypts transparently when you query. Vault's transit engine is application-layer encryption: your application sends plaintext to Vault's API and receives ciphertext back, which it stores in any datastore it chooses. The keys never leave Vault, key rotation is a single API call that doesn't require re-reading data (Vault supports rewrap), and all encrypt/decrypt operations are logged in Vault's audit trail. Transit is for protecting specific sensitive fields (PAN, SSN) even when the database itself is already encrypted at rest.
  5. Critique this approach: "We store all our secrets in encrypted env vars in our CI system."
    The approach is better than plaintext but has several structural problems. CI environment variables are typically readable by anyone with access to the repository or CI configuration, and many CI systems expose them in logs when a step uses printenv or fails unexpectedly. They are long-lived credentials with no TTL - once set, they persist until manually rotated. There is no audit trail of which pipeline jobs accessed which secret or when. The encryption is CI-provider-managed with limited key rotation. The correct approach is OIDC for cloud credentials (no stored secret at all) and Vault or a cloud secrets manager fetched at job runtime using a least-privilege IAM role, so each job gets a short-lived credential with a full access audit log.

8. Identity & Zero Trust

VPN is dying. Identity-aware access is replacing it.

The principle

Zero trust = "never trust, always verify." There is no trusted network. Every request, regardless of source, must be authenticated and authorized based on identity, device posture, and context. The corporate VPN model - "if you're inside the network, you're trusted" - is explicitly the thing zero trust replaces.

The reference: BeyondCorp

Google's 2014 paper. The seminal architecture: trust based on identity + device posture + access policy, not on network location. Every paper or product about zero trust references it.

Tools and platforms

TailscaleWireGuard-based managed mesh. Identity binding via SSO, NAT traversal, ACLs, MagicDNS. Earns its keep at scale or with mobile fleets - for stable small-N deployments, raw WireGuard is operationally simpler and free of SaaS dependency.
Cloudflare Access / Zero TrustIdentity proxy in front of internal apps. Great for replacing VPN. Free tier generous.
TwingateTailscale alternative. Similar concept, different architecture.
Zscaler / NetskopeEnterprise SASE platforms. Bigger, more comprehensive, more expensive.
SPIFFE / SPIREWorkload identity standard. Service-to-service auth without shared secrets.
Okta / Entra ID / Auth0Identity providers. The IDP layer of zero trust.
Senior nuance: Tailscale solves configuration management at scale, not WireGuard itself. If you control stable endpoints, can configure raw WireGuard, and don't need identity-based ACLs across a mobile fleet - raw WireGuard is simpler, free of SaaS trust, and kernel-native. Tailscale is "WireGuard for people who can't operate WireGuard, OR for fleets where manual config drifts faster than you can track it." Articulating both sides is what distinguishes a senior answer.

Practical zero-trust controls

Self-test: questions & answers
  1. Walk me through how a Tailscale-style mesh differs from a traditional VPN.
    A traditional VPN creates a hub-and-spoke tunnel: all traffic routes through a central gateway, which becomes a bottleneck and a single point of failure. Access is binary - you're either in the VPN or you're not. A WireGuard mesh like Tailscale creates peer-to-peer encrypted tunnels directly between nodes, with no central traffic bottleneck. Access is identity-aware: ACLs are defined in terms of identity tags (this user's devices, this service account) rather than IP ranges, and they're enforced at the coordination layer. When you leave the company, you're removed from the identity store and instantly lose access to all resources - there's no VPN credential to revoke separately.
  2. What's BeyondCorp and what problem does it solve?
    BeyondCorp is Google's internal zero-trust access model, published as a paper series starting in 2014. The problem it solves is the over-trusted internal network: once an attacker (or a compromised device) is inside the corporate network, they have implicit trust to reach production systems. BeyondCorp removes that implicit trust entirely - every request to an internal resource must be authenticated by identity, authorized against policy, and evaluated for device posture, regardless of whether the request comes from the office network or a coffee shop. Access decisions are made per-request, not per-session. The model is the direct ancestor of every commercial zero-trust product on the market today.
  3. Why is "internal-only network" a security anti-pattern in 2026?
    Because the threat model that justifies implicit internal trust no longer holds. The perimeter has three failure modes: remote-code execution on any internal service gives an attacker internal access; phishing or credential compromise gives an attacker VPN access; and insider threats are insiders by definition. In all three cases, the attacker is now "inside" and has lateral movement capability across anything that trusts the internal network. The cloud model compounds this - you don't even have a consistent physical network; "internal" is a fiction across VPCs, cloud providers, and remote workers. Zero trust acknowledges this reality and makes every service individually authenticate and authorize requests.
  4. What's the difference between authentication and authorization, and how does zero trust handle each?
    Authentication answers "who are you?" - verifying identity via credentials, tokens, certificates, or biometrics. Authorization answers "are you allowed to do this?" - evaluating the verified identity against a policy for the specific resource and action requested. Zero trust handles authentication at the identity provider (Okta, Entra ID) using MFA and device posture signals, producing a short-lived token with identity claims. Authorization is handled at the policy enforcement point (Cloudflare Access, OPA, IAM policies) per-request using those claims plus context like resource sensitivity, time of day, and risk score. The two are deliberately decoupled so that strong authentication doesn't grant blanket access - a compromised credential that authenticates successfully still hits per-resource authorization.
  5. Your CFO needs to access a production database for an audit. Design the access pattern.
    Use just-in-time (JIT) access: the CFO submits an access request with a business justification via a PAM tool (CyberArk, BeyondTrust, or AWS IAM Identity Center with approval workflow). A human approver (or automated policy for low-risk requests) grants a time-limited role with SELECT-only access on the specific schema needed, scoped by a condition in the IAM policy. The CFO connects through a bastion or database proxy (RDS Proxy, PgBouncer behind an identity-aware proxy) that enforces MFA re-authentication, logs the session verbatim, and terminates the connection when the time window expires. No persistent database credentials are issued - Vault generates a dynamic credential for the session duration and revokes it automatically on expiry.

9. SIEM, Observability, SOC

OpenTelemetry won. The SIEM market is consolidating.

OpenTelemetry - the unified standard

OpenTelemetry (OTel) merges OpenTracing and OpenCensus. Vendor-neutral instrumentation for traces, metrics, and logs. Every modern observability platform speaks OTel. If you're asked about observability standards in 2026, OTel is the answer.

The Grafana stack

This stack has become the open-source default in 2026. Most non-AWS shops run some version of it.

SIEM platforms

SplunkIncumbent enterprise SIEM. Expensive but powerful.
Microsoft SentinelCloud SIEM. Native Azure integration. KQL query language.
Google ChronicleCloud-native, cheap data ingestion model.
Elastic Security (ELK)OSS option. Strong if you already run ELK for logs.
WazuhOpen-source SIEM/HIDS combo. Popular in Eastern EU and SMB.
Datadog Cloud SIEMStrong if Datadog is your observability platform.
PantherDetection-as-code SIEM. Python rules. Modern alternative.

SOC operational concepts

Self-test: questions & answers
  1. Walk me through how OpenTelemetry differs from older instrumentation approaches.
    Before OTel, every observability vendor shipped their own SDK - you'd instrument your code with Datadog's library, then be locked in: switching vendors meant re-instrumenting. OpenTracing and OpenCensus were competing attempts to standardize, which split the ecosystem. OTel merges both into a single vendor-neutral API, SDK, and wire protocol (OTLP). You instrument once using OTel's language SDKs, emit to an OTel Collector (a configurable pipeline), and route to any backend - Jaeger, Tempo, Datadog, Honeycomb - by changing Collector configuration, not application code. The three signals (traces, metrics, logs) also share a common context propagation model, so correlation across signals is built-in rather than bolted on per-vendor.
  2. You're standing up a new observability stack from scratch. Open-source budget. What do you pick?
    Instrument applications with the OTel SDK and run an OTel Collector as a DaemonSet in k8s for collection and routing. For storage and query: Loki for logs (label-indexed, cheap object storage backend), Tempo for traces (also object storage backed, integrates with Loki for trace-to-log correlation), and Mimir or Prometheus with Thanos for long-term metrics. Grafana as the unified query and visualization layer over all three. This stack is production-proven, scales to significant data volumes on object storage costs rather than expensive TSDB nodes, and gives you full signal correlation in Grafana without a vendor dependency. The operational investment is the Collector pipeline configuration and Grafana dashboards - neither is trivial but both are well-documented.
  3. What's MITRE ATT&CK and how do you use it operationally?
    ATT&CK is a structured knowledge base of adversary tactics (the why - initial access, lateral movement, exfiltration) and techniques (the how - specific methods attackers use to achieve each tactic), each with a T-code ID and documented mitigations. Operationally you use it to measure detection coverage: map each SIEM detection rule to an ATT&CK technique ID and visualize coverage in the ATT&CK Navigator - gaps in coverage show you where an attacker could move undetected. During incident response, ATT&CK gives you a shared vocabulary to describe attacker behavior precisely and cross-reference with threat intelligence reports that use the same taxonomy. It also drives red team exercise planning by selecting techniques in your gap areas.
  4. Why is "detection-as-code" a meaningful concept and not just a buzzword?
    Before detection-as-code, SIEM rules lived only in the platform UI: no version history, no peer review, no testing, and no way to reproduce "what was our detection logic six months ago when this incident happened." Detection-as-code means detection rules are YAML or Python files in Git, with the same PR review and branch protection as application code. You can write unit tests against synthetic log data (Sigma rule test suites, Panther's built-in testing), run those tests in CI, and deploy rules via GitOps to the SIEM. This eliminates the class of broken detections that get shipped silently, gives you a full audit trail of rule changes, and makes blue team work reviewable by a second engineer - the same benefits version control gives any other code.
  5. Your SIEM is producing 50,000 alerts/day. What's wrong and how do you fix it?
    50,000 alerts/day is a tuning failure, not a threat landscape problem - analysts cannot triage at that volume and will start ignoring everything, which is worse than no SIEM. The fix has three parts: first, identify your top alert sources by volume and tune or suppress the noisiest rules (most high-volume alerts are benign activity matching an overly-broad pattern). Second, add enrichment and correlation: instead of alerting on every individual failed login, alert on 10 failed logins from the same source IP within 60 seconds - this reduces volume by orders of magnitude while improving signal quality. Third, implement alert tiers: automated SOAR playbooks handle Tier 1 commodity alerts (known-safe enrichment closes them automatically), and analysts see only escalated, correlated findings that require human judgment.

10. Compliance Automation

SOC 2 / ISO 27001 / GDPR / NIS2 audit prep, automated.

Continuous compliance

Old model: prepare for the annual audit, scramble to collect evidence, pass, return to neglect. New model: continuously collect evidence, continuously test controls, audit becomes a button click. The compliance-automation tools sell exactly this transformation.

Tools

DrataMarket leader. Auto-collects evidence from cloud, SSO, HRIS, ticketing. SOC 2 / ISO 27001 / HIPAA / GDPR.
VantaDirect competitor to Drata. Similar feature set.
SecureframeLower-priced alternative.
HyperproofMore flexible framework support, used at larger orgs with multiple frameworks.
Tugboat LogicAcquired by OneTrust, often paired with privacy management.

Frameworks you should be conversant in

Self-test: questions & answers
  1. Walk me through your last ISO 27001 audit prep - what was the hardest control to evidence?
    The technically hardest controls to evidence continuously are usually in the asset management (A.5) and access control (A.8) domains because they require proving a running process, not a point-in-time snapshot: that every asset is inventoried, that every access is reviewed quarterly, that terminated employees lose access within a defined SLA. These require integrating HR systems, identity providers, and cloud APIs into your evidence collection pipeline. Compliance automation tools like Drata automate much of this via API connectors, but the gaps - shadow IT, non-SSO SaaS tools, manual processes - require human controls that are harder to evidence than technical ones.
  2. What's the difference between SOC 2 Type I and Type II?
    Type I is a point-in-time assessment: the auditor verifies that your controls are suitably designed to meet the Trust Service Criteria as of a specific date. It proves design intent but says nothing about whether you actually ran those controls consistently. Type II covers an audit period - typically 6–12 months - and requires evidence that the controls operated effectively throughout that period. Customers and enterprise procurement teams require Type II because Type I is easy to game (get everything right for one day, get the report, return to normal). Type II requires continuous operation of your controls, which is why continuous compliance automation tools exist to collect that evidence automatically rather than scrambling at audit time.
  3. How does Drata/Vanta actually collect evidence? What's the architecture?
    These platforms integrate with your existing infrastructure via OAuth and API connections: your cloud provider (AWS, GCP, Azure), identity provider (Okta, Entra ID), HRIS (Workday, BambooHR), ticketing (Jira, Linear), MDM (Jamf, Intune), and code repositories. For each connected integration, they run scheduled API calls to collect evidence artifacts - an Okta API call confirms MFA is enabled for all users, an AWS Config API call retrieves your S3 bucket encryption settings, a GitHub API call confirms branch protection rules are active. Each artifact is timestamped, stored, and mapped to specific framework controls. The audit-readiness report is essentially a structured query over this collected evidence set, showing control coverage and flagging gaps.
  4. Your company falls under NIS2. What technical controls become mandatory that weren't before?
    NIS2 mandates incident detection and response capabilities (effectively a SIEM + incident response process), vulnerability management (regular scanning and patching with documented SLAs), supply chain security measures (vetting critical suppliers), access control with MFA for privileged access, encryption of data in transit and at rest, and business continuity/disaster recovery capabilities with tested recovery procedures. The significant change from NIS1 is that these requirements now apply to "important entities" - mid-sized companies in critical sectors - not just "essential" ones, and personal liability for management for non-compliance creates real organizational pressure to actually implement rather than document-and-ignore.
  5. How do you reconcile competing requirements between PCI DSS and GDPR?
    The most common conflict is PCI DSS requiring detailed transaction logs (retained for 12 months online, 1 year offline) versus GDPR's data minimization and storage limitation principles. The resolution is scoping: PCI DSS applies specifically to cardholder data, and GDPR's principles apply proportionally - retaining transaction logs for fraud investigation and chargeback disputes is a legitimate purpose under GDPR Article 6(1)(f) (legitimate interests) or 6(1)(c) (legal obligation via payment regulations). The practical approach is to segregate PCI-scoped systems from general data processing systems, apply GDPR Article 32 encryption and access controls to the PCI scope, document the lawful basis for each data element retained, and get legal sign-off on the retention schedule.

11. AI Security (the 2026 wildcard)

Even brief familiarity here will set you apart.

OWASP LLM Top 10 (2025)

  1. LLM01: Prompt Injection - adversarial input that hijacks the model's instructions.
  2. LLM02: Sensitive Information Disclosure - model leaks training data or context.
  3. LLM03: Supply Chain - compromised pre-trained models or training datasets.
  4. LLM04: Data and Model Poisoning - attacker corrupts training data or fine-tuning.
  5. LLM05: Improper Output Handling - model output rendered as code/HTML/SQL without sanitization.
  6. LLM06: Excessive Agency - LLM agents have too much authority over real systems.
  7. LLM07: System Prompt Leakage - system prompt contents exposed to users.
  8. LLM08: Vector and Embedding Weaknesses - RAG attacks, embedding inversion.
  9. LLM09: Misinformation - confidently-wrong outputs treated as authoritative.
  10. LLM10: Unbounded Consumption - DoS via expensive prompts.

Defensive concepts

Practical pattern: secure RAG

  1. User asks a question.
  2. Question goes through input guardrail (prompt-injection detector, PII redactor).
  3. Question is embedded; vector store returns relevant chunks.
  4. Retrieved chunks + system prompt + user question composed with structural separation (XML tags, clear delimiters).
  5. LLM generates response.
  6. Response goes through output guardrail (PII leak detection, harmful-output detection).
  7. Audit log: prompt, retrieved chunks, response, guardrail decisions.
Self-test: questions & answers
  1. What is prompt injection and how is it different from SQL injection?
    SQL injection exploits a parser that conflates data and instructions by embedding SQL syntax in user input. Prompt injection exploits the same conflation problem but at the natural-language level: an attacker embeds instructions in user-controlled text that the LLM interprets as system-level directives, overriding or bypassing the system prompt. The key difference is that SQL has a formal grammar with unambiguous parsing rules, so parameterized queries cleanly separate data from instructions. Natural language has no such separator - there is no equivalent of a bind parameter for LLM prompts. Current mitigations (structural delimiters, input guardrails) reduce the attack surface but cannot eliminate it the way parameterized queries eliminate SQL injection.
  2. You're building a customer-support chatbot. What are the top 3 security controls you'd put around it?
    First: input and output guardrails (Lakera Guard or equivalent) to detect prompt injection attempts on input and PII/sensitive data leakage on output - a customer chatbot must never reveal other customers' data or internal system details. Second: least-privilege tool scope - if the bot has access to order systems or CRM, its API credentials allow only read access on the authenticated customer's own records, so a successful prompt injection can't pivot to other accounts or write operations. Third: comprehensive audit logging of every prompt, tool call, and response with the customer session ID, so incidents are fully reconstructable and you can detect patterns of abuse before they escalate.
  3. How do you red-team an LLM application?
    Structured red teaming uses automated adversarial tools: PyRIT (Microsoft) and Garak (NVIDIA) generate systematic attack probes across categories - prompt injection, jailbreak attempts, harmful content elicitation, data extraction. Run these against a staging instance on a schedule, the same way you'd run DAST against a web application. Beyond automated scanning: manual testing focuses on the application's specific tool integrations and trust boundaries, probing what happens when retrieved RAG context contains adversarial instructions, and testing indirect injection vectors (content from third-party sources that the LLM reads). Document findings mapped to OWASP LLM Top 10 categories and track them in your vulnerability management process like any other finding.
  4. What's the security risk in giving an LLM agent the ability to execute shell commands?
    Shell execution is the highest-severity tool an LLM agent can have because it allows arbitrary code execution on the host - every other tool is a subset of this capability. The risk compounds with prompt injection: an attacker who can inject instructions through any channel the agent reads (user input, retrieved documents, API responses) can execute arbitrary shell commands on your infrastructure with the agent's privileges. Even without injection, LLMs hallucinate and may generate plausible-looking but incorrect commands. The correct pattern is never giving an LLM agent direct shell access; instead, expose narrow, schema-validated API functions (create_ticket, query_database_by_id) that the agent calls, each running under a least-privilege role with no shell access.
  5. Walk me through how you'd integrate AI security into existing DevSecOps pipelines.
    Treat LLM applications like any other web application for the pipeline layers you already have: SAST on the Python/TypeScript code that wraps the LLM (Semgrep finds hardcoded API keys, insecure deserialization), SCA on the LangChain/LlamaIndex dependencies, secrets scanning on the repo. Add LLM-specific layers: model provenance checks (verify the model hash matches a known-good artifact before loading), Garak scans in the CI pipeline against the application's endpoints, and guardrail integration tests that assert the chatbot refuses known adversarial prompts. For runtime, add structured logging of all LLM interactions to your SIEM with anomaly detection on token consumption spikes (LLM10 unbounded consumption) and unusual tool call patterns (LLM06 excessive agency).

12. Interview Notes

What hiring loops typically look like, what works, what doesn't.

Informational chapter. Not a script. The patterns below describe how DevSecOps interviews are commonly structured at mid-to-large companies in 2026, and the kinds of behaviour that distinguish strong candidates from average ones. Use it as background; don't memorise it.

The typical loop

  1. Recruiter screen (30 min) - culture fit, salary expectations, motivation. Tech depth is not the point of this stage.
  2. Hiring manager screen (45-60 min) - career story, why this role, why this company. Concrete outcomes weigh more than tool name-drops.
  3. Technical deep-dive (60-90 min) - one or two domains in depth. Cloud security, k8s security, or pipeline security. "Tell me about a time when..." with follow-ups going arbitrarily deep.
  4. System design (60 min) - "design the security architecture for X." Cloud-native company, fintech with PCI DSS, multi-tenant SaaS. Whiteboard or shared canvas.
  5. Hands-on or take-home (variable) - sometimes a live debugging session, sometimes a coding/scripting exercise, sometimes "review this Terraform and find the issues."
  6. Cultural / executive (30-45 min) - closing conversation with a senior leader.

Common "tell me about a time" prompts

What distinguishes a senior answer

What hurts candidates

The STAR pattern

Situation (1 sentence) -> Task (your responsibility, 1 sentence) -> Action (what you specifically did, 2-3 sentences) -> Result (quantified outcome, 1 sentence).

Example: "We had 200 RHEL servers with no centralised identity management (situation). I was asked to integrate them with our Windows AD (task). I designed the CRUM project - built Ansible roles for SSSD configuration, mapped Linux groups to AD, added audit logging via auditd, rolled out in waves with health checks (action). Result: 200 servers cut over with no production incidents, all sudo decisions auditable to AD identity, onboarding for new admins dropped from days to hours (result)."

Practical preparation that usually pays off

13. Quick-Reference Cheatsheet

The condensed final table.

Tool-to-category one-liner table

CategoryMust-know toolWhat it does in one sentence
CNAPPWizAgentless cloud security graph, finds misconfigs and risky paths.
Image scanningTrivyScans container images for vulns, secrets, misconfig.
K8s admissionOPA / KyvernoRejects non-compliant pods at deploy time.
K8s runtimeFalcoeBPF-based runtime threat detection.
K8s networkingCiliumeBPF CNI with network policy + service mesh.
SBOMSyftGenerates an SBOM from any image or filesystem.
Vuln-scan SBOMGrypeScans an SBOM against known CVEs.
Sign artifactsSigstore / cosignSigns container images with ephemeral keys.
SASTSemgrepPattern-based static code analysis with custom rules.
DASTOWASP ZAPOpen-source dynamic web app scanner.
SCASnyk Open SourceScans dependencies for known vulnerabilities.
IaC scanCheckovScans Terraform/K8s YAML for misconfig before deploy.
Secrets scanGitleaksDetects credentials in git history and commits.
GitOpsArgoCDReconciles k8s state from Git, continuously.
Secrets vaultHashiCorp VaultDynamic secrets, transit encryption, PKI.
Zero-trust netTailscaleWireGuard mesh with identity-aware ACLs.
ObservabilityOpenTelemetryVendor-neutral instrumentation standard.
SIEM (OSS)Wazuh / ElasticOpen-source SIEM and HIDS.
Compliance autoDrataContinuous evidence collection for SOC 2 / ISO 27001.
LLM red-teamPyRIT / GarakAutomated adversarial testing of LLM apps.

Compliance frameworks at a glance

FrameworkScopeEffective from
ISO/IEC 27001:2022International ISMS, 93 controls2022 revision
SOC 2 Type IIUS-focused, operating effectiveness over 6–12 monthscontinuous
PCI DSS v4.0Payment card data protectionMandatory March 2024 - 2025
GDPREU personal data protectionMay 2018
NIS2EU cybersecurity for essential/important entitiesOct 2024
DORAEU financial sector operational resilienceJan 2025
EU AI ActEU AI system classification & obligationsPhased 2025–2027

The ten things to drill before any interview

  1. What problem CNAPP consolidates (CSPM + CWPP + CIEM + image scan).
  2. How OPA/Kyverno reject a non-compliant pod at admission.
  3. Why Falco is eBPF-based and what eBPF actually is.
  4. What an SBOM is and what you'd actually do with one.
  5. How Sigstore avoids the long-lived-key problem.
  6. The five layers of shift-left scanning in a CI pipeline (SAST, SCA, secrets, IaC, image).
  7. Why GitOps + ArgoCD is more secure than pushing kubectl from a laptop.
  8. What a "dynamic secret" from Vault actually is.
  9. BeyondCorp / zero trust in one sentence.
  10. OWASP LLM Top 10 - at minimum prompt injection, output handling, excessive agency.

End of reference. Last revised May 2026 by Paradox @ servbg.com.
Suggestions, corrections, or "you missed X": cv@servbg.com