DevSecOps & Secure Pipelines
SAST/DAST/SCA/IAST, CI/CD hardening, secrets scanning, supply-chain defense, SBOM, IaC scanning, dependency pinning, CVE triage and security quality gates.
14 questions
JuniorTheoryVery commonWhat do SAST, DAST and SCA each analyse, and when does each run?
What do SAST, DAST and SCA each analyse, and when does each run?
SAST reads source without running it and finds insecure code paths. DAST probes a running instance and sees runtime behaviour, not source. SCA checks declared dependencies for known-vulnerable versions. Each covers a different defect class.
Common mistakes
- ✗Treating SAST and DAST as interchangeable rather than complementary
- ✗Expecting SAST to catch runtime or deployment misconfiguration it cannot see
- ✗Assuming SCA finds custom-code flaws instead of known dependency issues
Follow-up questions
- →Why can dynamic testing
DASTmiss a flaw that static analysisSASTreports? - →Where does interactive testing
IASTsit between these three?
JuniorTheoryVery commonHow does secret scanning work in a repository and in CI, and what does it miss?
How does secret scanning work in a repository and in CI, and what does it miss?
Scanners match known credential patterns and flag high-entropy strings — as a pre-commit hook, in CI, and across history. Pre-commit catches leaks early but is bypassable, so the CI check enforces. It misses novel formats and rotates nothing.
Common mistakes
- ✗Trusting the pre-commit hook alone, which a developer can skip
- ✗Scanning only the current tree and never the repository history
- ✗Treating detection as remediation instead of rotating the credential
Follow-up questions
- →Why must the CI check run in addition to a local pre-commit hook?
- →How do you keep entropy-based detection from drowning a team in false positives?
MiddleTheoryVery commonWhy must scanner findings be triaged, and how does scanner noise kill adoption?
Why must scanner findings be triaged, and how does scanner noise kill adoption?
A scanner report is a hypothesis list, not a bug list — static analysis over-approximates, so many findings are unreachable or already mitigated. Triage confirms exploitability, then sets severity and an owner. Noise teaches developers to ignore the tool.
Common mistakes
- ✗Treating every scanner finding as a confirmed exploitable vulnerability
- ✗Leaving findings unowned, so the backlog grows and trust erodes
- ✗Taking the scanner's severity label as the final business priority
Follow-up questions
- →How do you make a suppression auditable rather than a silent dismissal?
- →What signal tells you a scanner's noise level is now hurting delivery?
JuniorTheoryCommonWhy pin dependency versions and verify hashes against supply-chain typosquatting?
Why pin dependency versions and verify hashes against supply-chain typosquatting?
A lockfile pins the exact version and hash of every dependency, direct and transitive, so a rebuild fetches the same bytes and a republished package fails verification. Signatures add provenance, and a registry proxy blocks confusable names.
Common mistakes
- ✗Pinning direct dependencies but letting the transitive tree float
- ✗Recording versions without hashes, so republished bytes still pass
- ✗Reading a signature as proof of safety rather than of provenance
Follow-up questions
- →How does a private registry proxy reduce dependency-confusion risk?
- →What does pinning cost, and how do you still take security patches quickly?
JuniorTheoryCommonAn API key was pushed to a shared repo, then force-pushed away. Is it safe?
An API key was pushed to a shared repo, then force-pushed away. Is it safe?
No. Treat it as compromised the moment it landed — clones, forks, CI logs and mirrors hold it, and a force-push removes nothing from them. Rotate first, then audit its use over the exposure window. Scrubbing history is cleanup, not remediation.
Common mistakes
- ✗Believing a force-push or history rewrite un-leaks the credential
- ✗Delaying rotation until the leak is confirmed to have been exploited
- ✗Forgetting CI logs, caches, forks and mirrors keep their own copy
Follow-up questions
- →Why do short-lived dynamic credentials from a vault shrink this whole response?
- →What must the credential's audit log show to close the exposure window?
MiddleDesignCommonYour platform team runs one shared CI pipeline for 60 services on a two-week release train. Security scanning is already wired in — static analysis on every pull request, dependency scanning on every build, secret scanning on push — but every finding is advisory today and nothing gets fixed. Leadership wants a real gate. Constraints — a pull request must not sit blocked longer than a scan takes; the on-call must be able to ship a production hotfix at 3am; the platform team owns the pipeline but not the 60 services' backlogs; and any suppression has to survive an audit six months later. Design the gate. Specify what blocks the build and what only warns, how the break-glass path works and who is accountable when it is used, and how you avoid the outcome where teams quietly move the scan out of the blocking job.
Your platform team runs one shared CI pipeline for 60 services on a two-week release train. Security scanning is already wired in — static analysis on every pull request, dependency scanning on every build, secret scanning on push — but every finding is advisory today and nothing gets fixed. Leadership wants a real gate. Constraints — a pull request must not sit blocked longer than a scan takes; the on-call must be able to ship a production hotfix at 3am; the platform team owns the pipeline but not the 60 services' backlogs; and any suppression has to survive an audit six months later. Design the gate. Specify what blocks the build and what only warns, how the break-glass path works and who is accountable when it is used, and how you avoid the outcome where teams quietly move the scan out of the blocking job.
Block only high-confidence, high-severity classes — a verified secret, a critical reachable dependency — and warn on the rest. Break-glass is a self-service label that ships but alerts security and opens a timed ticket. Suppressions are reviewed, owned and expiring.
Common mistakes
- ✗Blocking on every severity, which teaches teams to route around the gate
- ✗Offering no break-glass path, so an incident hotfix stalls behind a scan
- ✗Allowing untracked, non-expiring suppressions that no audit can reconstruct
Follow-up questions
- →What metric would tell you the gate is being bypassed rather than satisfied?
- →Why must the blocking step live in platform-owned pipeline code?
SeniorDesignCommonYou inherit an application-security programme at a company with 200 repositories, 30 delivery teams and no security scanning outside two pilot repos. Leadership gives you two quarters and no extra headcount. Constraints — teams own their own pipelines and can edit them freely; a previous attempt failed when a blocking scanner produced hundreds of findings per repo and teams disabled it within a week; delivery velocity is a tracked executive metric; and you have one shared CI platform but four different language stacks. Design the rollout so scanning actually sticks. Cover the order you onboard repositories, how you keep the first weeks from drowning teams in findings, how you make the gate hard to route around without policing people, what you ask of the teams versus what you own centrally, and how you would show leadership the programme is working.
You inherit an application-security programme at a company with 200 repositories, 30 delivery teams and no security scanning outside two pilot repos. Leadership gives you two quarters and no extra headcount. Constraints — teams own their own pipelines and can edit them freely; a previous attempt failed when a blocking scanner produced hundreds of findings per repo and teams disabled it within a week; delivery velocity is a tracked executive metric; and you have one shared CI platform but four different language stacks. Design the rollout so scanning actually sticks. Cover the order you onboard repositories, how you keep the first weeks from drowning teams in findings, how you make the gate hard to route around without policing people, what you ask of the teams versus what you own centrally, and how you would show leadership the programme is working.
Start in warn mode and baseline existing findings so teams see only new ones. Ship scanning as an inherited central pipeline template, so it is default-on and removal is visible. Onboard by risk. Central owns tuning and triage, teams own fixes. Report time to remediate and bypass rate, not raw counts.
Common mistakes
- ✗Turning on a blocking gate before baselining the existing backlog
- ✗Letting each team wire its own scanner, so coverage is unverifiable
- ✗Reporting raw finding counts instead of remediation and bypass rates
Follow-up questions
- →Why does an inherited pipeline template beat documentation teams must follow?
- →What would make you slow the rollout down in the middle of a quarter?
SeniorDesignCommonYour vulnerability backlog holds 4000 open findings from dependency, container and cloud-posture scanning, and nothing is being closed. You must propose a vulnerability-management policy the engineering organisation will actually meet. Constraints — severity today comes straight from each tool's severity score, so 900 findings are rated critical; internet-facing and internal services sit in one queue; some findings live in base images owned by the platform team rather than by the application teams; and the audit committee wants fixed remediation deadlines in writing. Design the policy. Cover how you set priority beyond a severity score, what the service-level tiers are and what they attach to, how ownership is assigned when nobody wrote the vulnerable code, what happens when a deadline is about to be breached, and how you keep the policy from simply generating a second backlog of overdue items.
Your vulnerability backlog holds 4000 open findings from dependency, container and cloud-posture scanning, and nothing is being closed. You must propose a vulnerability-management policy the engineering organisation will actually meet. Constraints — severity today comes straight from each tool's severity score, so 900 findings are rated critical; internet-facing and internal services sit in one queue; some findings live in base images owned by the platform team rather than by the application teams; and the audit committee wants fixed remediation deadlines in writing. Design the policy. Cover how you set priority beyond a severity score, what the service-level tiers are and what they attach to, how ownership is assigned when nobody wrote the vulnerable code, what happens when a deadline is about to be breached, and how you keep the policy from simply generating a second backlog of overdue items.
Priority is risk, not a severity score alone — combine severity with exploitation signals, reachability, and asset exposure. Tiers attach to that composite and the clock starts at triage. Base-image findings route to the platform team by ownership metadata. Breaches escalate to a time-boxed risk acceptance.
Common mistakes
- ✗Treating a severity score as a priority rather than as one input to risk
- ✗Assigning base-image findings to teams that cannot actually fix them
- ✗Allowing open-ended risk acceptance instead of a time-boxed decision
Follow-up questions
- →Why do exploitation signals such as a known-exploited catalogue reorder the queue so much?
- →What does starting the deadline clock at triage rather than at scan time protect against?
MiddleDebuggingOccasionalThis pipeline's security stage passes on every run. Why, and how do you fix it?
This pipeline's security stage passes on every run. Why, and how do you fix it?
The scan cannot fail the build — continue-on-error: true swallows its exit code and Gate hardcodes exit 0. It also echoes the token into a log and runs write-all on an unpinned action. Gate on the real exit code, drop the echo, rotate the token, scope permissions, pin by SHA.
Common mistakes
- ✗Reading a green job as a passing gate without checking the exit path
- ✗Treating
continue-on-erroras a responsiveness setting rather than a bypass - ✗Deleting the leaked token from the log instead of rotating the credential
Follow-up questions
- →Why does pinning an action to a commit SHA matter more than pinning to a tag?
- →How would you stop a team re-adding
continue-on-errorto the security job?
MiddleDesignOccasionalA 40-engineer platform group manages all cloud infrastructure as Terraform modules and Kubernetes manifests in one monorepo. A post-incident review found a storage bucket made public by a one-line change that passed code review, and a cluster running workloads as root. Constraints — the same repo serves production and sandbox accounts, and sandbox must stay permissive; the group already has thousands of existing resources that would fail a strict ruleset today; and infrastructure changes must still merge within a day. Design infrastructure-as-code scanning with policy-as-code. Say where scanning runs relative to plan and apply, how you express rules so they are testable and reviewable, how you introduce a ruleset without blocking every existing change on day one, and what stops someone applying from a laptop entirely outside the pipeline.
A 40-engineer platform group manages all cloud infrastructure as Terraform modules and Kubernetes manifests in one monorepo. A post-incident review found a storage bucket made public by a one-line change that passed code review, and a cluster running workloads as root. Constraints — the same repo serves production and sandbox accounts, and sandbox must stay permissive; the group already has thousands of existing resources that would fail a strict ruleset today; and infrastructure changes must still merge within a day. Design infrastructure-as-code scanning with policy-as-code. Say where scanning runs relative to plan and apply, how you express rules so they are testable and reviewable, how you introduce a ruleset without blocking every existing change on day one, and what stops someone applying from a laptop entirely outside the pipeline.
Scan plan output, not just source, in the pull request and again at apply. Rules are versioned policy code with their own tests, scoped per environment so sandbox differs from production. Roll out in warn mode with an expiring baseline, and let only the pipeline identity apply.
Common mistakes
- ✗Scanning source only, missing what the plan actually resolves to
- ✗Enabling a strict ruleset as blocking against a large legacy estate
- ✗Leaving human apply credentials, so the gate is optional in practice
Follow-up questions
- →Why does scanning the plan catch what a manifest-only scan misses?
- →How do you keep per-environment policy exceptions from becoming permanent?
MiddleTheoryOccasionalA critical advisory lands and no patched version exists yet. What do you do?
A critical advisory lands and no patched version exists yet. What do you do?
First establish exposure — query the inventory for affected artifacts and which are internet-facing. With no fix yet, buy time with compensating controls: disable the feature, filter the input at the edge, tighten egress. Patch to a pinned release once one ships.
Common mistakes
- ✗Waiting for a patch instead of applying compensating controls now
- ✗Skipping exposure analysis and treating every service as equally urgent
- ✗Closing the item at the mitigation and never returning to patch properly
Follow-up questions
- →Why is an edge filter a stopgap rather than a fix for the vulnerable code?
- →How does a pinned lockfile speed up the eventual upgrade?
MiddleTheoryOccasionalWhen does a dependency vulnerability exist but stay unreachable, and how is that proved?
When does a dependency vulnerability exist but stay unreachable, and how is that proved?
Existing and reachable differ. SCA flags a version, but the vulnerable function may never be called from your code. Reachability analysis walks the call graph from your entry points; nothing reaching the sink means latent risk — lower priority, still patched.
Common mistakes
- ✗Treating an unreachable finding as fixed rather than as deprioritised
- ✗Assuming transitive dependencies cannot be exploited at all
- ✗Ranking findings purely by severity label, ignoring real call paths
Follow-up questions
- →How does a build-time inventory
SBOMmake a reachability verdict auditable later? - →What can invalidate a reachability verdict — reflection, dynamic loading, configuration?
MiddleTheoryOccasionalWhat does an SBOM answer that a dependency scan alone cannot?
What does an SBOM answer that a dependency scan alone cannot?
An SBOM is a machine-readable inventory of every component and version actually in a build, including transitive ones, emitted from the resolved dependency tree. A scan gives today's findings; the SBOM answers later which shipped artifacts hold a component.
Common mistakes
- ✗Listing only direct dependencies and omitting the transitive tree
- ✗Generating an SBOM once instead of per build, so it drifts from reality
- ✗Confusing an SBOM (component inventory) with a scanner findings report
Follow-up questions
- →How do the inventory formats
SPDXandCycloneDXdiffer in practice? - →Why generate an SBOM at build time rather than from the manifest file?
SeniorDesignOccasionalAt 22:00 a critical remote-code-execution flaw is disclosed in a logging library used across your industry, with a public proof of concept and active exploitation. You run roughly 200 services across four business units. Constraints — build-time component inventories exist for about half the estate and nothing for the rest; a dozen services are vendor-supplied container images you cannot rebuild; two business units have their own on-call and do not report to you; and the company will not accept a full production freeze. Design the organisation's response. Cover how you establish what is actually affected within hours, how you sequence remediation across teams you do not control, what you do about artifacts you cannot rebuild, how you decide between mitigating and patching per service, and what you change afterwards so the next disclosure is cheaper.
At 22:00 a critical remote-code-execution flaw is disclosed in a logging library used across your industry, with a public proof of concept and active exploitation. You run roughly 200 services across four business units. Constraints — build-time component inventories exist for about half the estate and nothing for the rest; a dozen services are vendor-supplied container images you cannot rebuild; two business units have their own on-call and do not report to you; and the company will not accept a full production freeze. Design the organisation's response. Cover how you establish what is actually affected within hours, how you sequence remediation across teams you do not control, what you do about artifacts you cannot rebuild, how you decide between mitigating and patching per service, and what you change afterwards so the next disclosure is cheaper.
Declare an incident with one commander and one inventory of record. Query the inventories you have, then scan running artifacts to close the gap. Sequence by exposure — internet-facing first. For vendor images use network mitigations while pressing the supplier. Afterwards make build-time inventories mandatory.
Common mistakes
- ✗Relying on team self-reporting instead of an inventory of record
- ✗Sequencing by team convenience rather than by real exposure
- ✗Declaring closure at the mitigation, without patching or a durable fix
Follow-up questions
- →How do you handle a service whose owning team disputes its exposure?
- →Why is build-time inventory coverage the highest-leverage follow-up here?