DevSecOps Pipeline Engineer — Interview Questions

Option B is strongest: it uses concrete analogies (code review vs. penetration test) that developers already understand, names specific vulnerability types for each tool (hardcoded secrets, SQL concatenation for SAST; SQL injection payloads, XSS for DAST), explains the fundamental constraint of each tool (SAST cannot see runtime behaviour; DAST cannot see source code), explains why SAST produces more false positives (pattern detection without runtime context), and explains why both are needed. The placement recommendation (SAST in CI every PR, DAST against staging) is the practical guidance that converts understanding into action. Application security vocabulary: SAST (Static Application Security Testing) — security analysis of source code or bytecode without executing the application. DAST (Dynamic Application Security Testing) — security testing of a running application by sending attack payloads and observing responses. Shift-left security — moving security testing earlier in the development lifecycle to catch vulnerabilities when they are cheapest to fix. False positive — a security tool finding that reports a vulnerability that does not actually exist. XSS (Cross-Site Scripting) — an injection vulnerability where attackers embed malicious scripts in web pages. Options C and D are accurate but lack the analogy and the false positive explanation.

Option B is strongest: it opens with the key insight that this is a risk management judgment (not a CVSS lookup), provides three named criteria with explanations, introduces the 'critical but no patch available' scenario that most engineers miss, explains the acceptance decision format ('we accept this vulnerability because...'), and gives the team communication framing that articulates the philosophy of the gate design. The 'gate that cries wolf' insight is particularly important — it names the failure mode of over-blocking (developers routing around the gate) and quantifies the acceptable false positive rate (5%). Security gate vocabulary: Security gate — a pipeline step that evaluates security findings and either blocks (fails the pipeline) or reports (advisory) based on configured rules. CVSS score — a numerical rating of vulnerability severity (0–10); widely used but context-independent. Exploitability — the likelihood that a vulnerability can be successfully exploited in a specific deployment environment. Acceptance decision — a documented, time-boxed decision to accept a known vulnerability risk rather than remediate it. False positive rate — the percentage of security findings that do not represent actual vulnerabilities. Options C and D are accurate but lack the 'cries wolf' failure mode and the acceptance decision format.

Option B is strongest: it names the two failure modes of acceptance communication (undocumented = negligence, over-explained = excuse-making), provides the full acceptance statement format as a template, gives a complete realistic example with all elements filled in (specific CVE, no patch reason, compensating control of read-only container with no shell access, advisory subscription as monitoring, specific expiry date), names what makes each element effective, and explicitly names the anti-pattern (open-ended acceptance that never gets resolved). The compensating control explanation — read-only container with no shell access — is the detail that shows a practitioner who thinks about deployment context, not just vulnerability scores. Vulnerability management vocabulary: Vulnerability acceptance — a documented, time-boxed decision to acknowledge a known vulnerability without immediate remediation. Compensating control — a security measure that reduces the risk of a known vulnerability being exploited. Acceptance expiry — the date or trigger event after which the acceptance decision must be re-evaluated. CVE (Common Vulnerabilities and Exposures) — a standardised identifier for publicly known security vulnerabilities. Security advisory — a notification from a software vendor about a vulnerability and the availability of a fix. Options C and D are accurate but lack the failure mode framing and the complete realistic example.

Option B is strongest: it explains what each tool covers and — more importantly — what each tool misses (dependency scanning misses OS-level packages; image scanning has no such blind spot for the image), provides the specific realistic scenario that most developers have not considered (OpenSSL CVE in Ubuntu base image of a Node.js service), and provides the actionable guidance ('if you only run one, run image scanning'). The OpenSSL example is the insight that makes the distinction real: it is a non-application vulnerability that would silently pass through dependency scanning and reach production. Container security vocabulary: Container image scanning — security analysis of the full container image filesystem, including OS packages, system libraries, runtimes, and application dependencies. Dependency scanning (SCA — Software Composition Analysis) — security analysis of an application's declared package dependencies. Base image — the foundation layer of a container image, typically an OS distribution (Ubuntu, Alpine). Image layer — one of the layers that makes up a container image, each added by a Dockerfile instruction. Transitive dependency — a dependency of a dependency; not always listed in the top-level package manifest. Options C and D are accurate but lack the OpenSSL scenario and the 'if running one, run image scanning' recommendation.

Option B is strongest: it acknowledges the industry data reference (6x/30x) while making it concrete for each stage, provides a realistic timeline for each stage's cost (30 minutes vs. 1-2 days vs. multi-function incident response), names the specific compliance cost component (GDPR 72-hour notification window — a legal obligation management understands), provides the management communication sentence that positions the investment as zero marginal cost per run, and closes with the break-even framing. The 'zero marginal cost per run after setup' insight is the key: it reframes security gates from a recurring cost to a one-time investment with unlimited future runs. Shift-left security vocabulary: Shift-left security — the practice of moving security testing and controls earlier in the development lifecycle (toward the left side of a deployment pipeline). Security gate — an automated checkpoint in a CI/CD pipeline that evaluates security findings. GDPR breach notification — the legal obligation under GDPR to notify supervisory authorities within 72 hours of discovering a personal data breach. Context switching cost — the productivity cost of a developer moving between tasks; estimated at 15-30 minutes to regain full focus. Marginal cost — the cost of one additional unit of output; for CI pipeline gates, marginal cost per run approaches zero after setup. Options C and D are accurate but lack the GDPR notification detail and the zero-marginal-cost framing.