./run-pipeline.sh --role=devops-engineer --target=devsecops
DevOps → DevSecOps interview prep
For any DevOps engineer moving toward a DevSecOps-focused role · generic / foundational mock interview
// before you walk in
DevSecOps-focused roles — especially at application security consultancies and in regulated industries (banking, government, fintech) — usually center on the same shape of work: SSDLC framework design, threat modeling, secure code review, and DevSecOps pipeline integration, delivered around SAST, DAST, SCA, IAST, and a triage/false-positive workflow.
Many of these teams standardize on Fortify and/or Black Duck as their commercial AST stack (between the two, SAST/SCA/DAST/IAST are all covered), alongside Azure DevOps, HashiCorp Vault, JFrog Artifactory, and Kubernetes/OpenShift security basics — so this guide keeps its commercial-tool examples anchored to those two, since they're the vendors most likely to come up by name in this kind of interview.
What this means going in: expect focus on SSDLC concepts, threat modeling maturity, and general fluency with SAST/DAST/SCA/IAST tooling. Deep CI/CD engineering depth usually matters less than showing where security fits in the pipeline and speaking intelligently about triage, gates, and SDLC governance — worth checking which specific tools your target company actually uses beforehand (job posting, LinkedIn, case studies) and swapping in their names wherever this guide says "Fortify" or "Black Duck."
// acronym cheat sheet — read this first
Coming from a DevOps background — these shortcuts get used constantly in AppSec-world conversationsSAST
Static Application Security Testing
scans source code, no execution — pre-build
DAST
Dynamic Application Security Testing
attacks a running app from outside — black-box
IAST
Interactive Application Security Testing
agent inside the app during real testing — SAST+DAST
SCA
Software Composition Analysis
scans open-source/3rd-party dependencies for CVEs
SBOM
Software Bill of Materials
the inventory list of every component/version used
ASPM
Application Security Posture Management
correlates/dedupes findings from all scanners in one view
SSDLC
Secure Software Development Life Cycle
security embedded in every SDLC phase, not just at the end
STRIDE
Spoof/Tamper/Repudiate/Info-leak/DoS/Elevate
threat modeling category checklist
IaC
Infrastructure as Code
infra defined in files (Terraform/Ansible) — scannable pre-deploy
SIEM
Security Information & Event Management
central log/alert correlation — e.g. Sentinel
IAM
Identity & Access Management
who can do what to which cloud resource
mTLS
Mutual TLS
both sides of a connection prove identity + encrypt
SLSA
Supply-chain Levels for Software Artifacts
framework for proving a build wasn't tampered with
Fortify SSC
Fortify Software Security Center
Fortify's dashboard that aggregates its own scan results
SRM
Black Duck Software Risk Manager
ASPM — correlates findings from 150+ tools, not just Black Duck's
Polaris
Black Duck unified SaaS engine platform
runs Coverity+SCA+Seeker together; feeds results into SRM
GitOps
Git as the source of truth for deployment
a controller (ArgoCD) syncs cluster state to match Git
CI/CD
Continuous Integration / Delivery
automated build→test→deploy pipeline, defined as code
DEV
SEC
OPS
security isn't a phase — it's a continuous thread through every commit, build, and deployment
// start here if security isn't second nature yet
The rest of this guide assumes fluency with terms like "finding," "false positive," or "OWASP Top 10" — the everyday vocabulary of an AppSec shop. Coming from DevOps, that vocabulary isn't automatic yet, so this section covers it first. It's the difference between sounding like someone who's used a scanner and someone who's only ever configured one.
101
Vulnerability, finding, triage, false positive
secWhat's the difference between a "vulnerability," a "finding," and a "false positive"?
- Vulnerability — an actual flaw or weakness in a system, application, or configuration that could genuinely be exploited to cause harm. This exists whether or not anyone has found it yet.
- Finding — what a scanner (or a human reviewer) reports. It's a claim that a vulnerability exists at a specific location. Every vulnerability that gets reported is a finding, but not every finding is a real vulnerability.
- False positive — a finding that claims a vulnerability exists, but on closer inspection it doesn't (the code path is unreachable, the input is already sanitized elsewhere, the scanner misunderstood the framework's behavior). This is the single biggest daily friction point in AppSec — which is exactly why "triaging" exists as its own paid service line at many AppSec consultancies.
- False negative — the more dangerous, quieter opposite: a real vulnerability that no tool flagged at all. This is why no single scan type is treated as complete coverage.
What does "triage" actually mean in this context, and what does the process look like?
Triage is the step between "a scanner produced 200 findings" and "here's what the developer actually needs to act on." It means: confirm whether each finding is a true or false positive, deduplicate the same underlying issue reported by multiple scanners, assign a real-world severity (not just the tool's default score — factoring in exploitability and exposure), and route the confirmed ones to the right owner with the right priority. Manual triage doesn't scale past a handful of findings a day, which is why ASPM tools (DefectDojo, SRM, Fortify SSC) exist to automate most of it.
101
CVE, CWE, and CVSS
secWhat's the difference between a CVE, a CWE, and a CVSS score?
A simple analogy: CWE is the crime category, CVE is the police report for one specific incident, CVSS is how serious that incident was.
- CWE (Common Weakness Enumeration) — a catalog of general classes of software weakness (e.g.
CWE-89: SQL Injection,CWE-79: XSS). It describes the type of flaw, maintained by MITRE. - CVE (Common Vulnerabilities and Exposures) — a unique ID for one specific, publicly known vulnerability in one specific product/version (e.g. a particular flaw in a particular version of a library). This is what SCA tools match your dependencies against.
- CVSS (Common Vulnerability Scoring System) — the numeric severity score (0–10) for a given CVE, based on factors like attack complexity, privileges required, and impact. Bands: Critical 9.0–10, High 7.0–8.9, Medium 4.0–6.9, Low 0.1–3.9.
Reference: MITRE CVE/CWE programs, FIRST.org CVSS specification.
101
OWASP Top 10
secWhat is the OWASP Top 10, and what's actually on the current list?
It's the industry-standard, community/data-driven list of the most critical web application security risks, published by the OWASP Foundation. It's an awareness list, not a compliance framework — but nearly every SAST/DAST tool maps its rules back to it. OWASP released an updated 2025 list in January 2026 — the first update since 2021 — so it's worth knowing the current shape rather than the older one:
- A01 Broken Access Control — now also absorbs SSRF (previously its own category).
- A02 Security Misconfiguration — jumped from #5 in 2021 to #2, reflecting how much risk comes from cloud/config drift rather than code bugs.
- A03 Software Supply Chain Failures — brand new category: dependency confusion, malicious packages, compromised CI/CD.
- A04 Cryptographic Failures (previously "Sensitive Data Exposure")
- A05 Injection (SQLi, command injection, etc.)
- A06 Insecure Design — missing threat modeling, flawed architecture, not just implementation bugs.
- A07 Authentication Failures
- A08 Software and Data Integrity Failures
- A09 Security Logging and Alerting Failures (renamed from "...and Monitoring")
- A10 Mishandling of Exceptional Conditions — new category: poor error handling, unsafe fallbacks, leaking stack traces.
Reference: owasp.org/Top10/2025.
101
Black box, grey box, white box testing
secWhat do black box, grey box, and white box mean, and which scan types map to each?
These describe how much internal knowledge the tester/tool has of the system under test:
- White box — full internal visibility: source code, architecture, credentials. SAST is white box — it reads the source directly.
- Black box — zero internal knowledge, tested purely from the outside like a real attacker would. DAST is black box — it only sees the running application's external behavior.
- Grey box — partial knowledge: some internal visibility combined with external testing. IAST is grey box — it has source-level visibility and observes real external test traffic simultaneously, which is exactly why it earns the "combines SAST + DAST" description.
101
Common security tools to recognize by name
secBeyond the SAST/DAST/SCA vendor names already covered, what general security tools should I at least recognize on sight?
- Burp Suite — the industry-standard tool for manual and semi-automated web application penetration testing; a security engineer intercepts and manipulates HTTP requests directly. Distinct from ZAP mainly in maturity and manual-testing workflow depth — most professional pentesters use Burp Suite Pro day to day.
- Nmap — network/port scanner; discovers what hosts and services are reachable on a network before anything else happens.
- Metasploit — an exploitation framework used in penetration testing to actually attempt exploiting known vulnerabilities (not just detecting them) in a controlled, authorized engagement.
- Wireshark — packet/network traffic analyzer; inspects raw traffic to see exactly what's being sent, useful for verifying whether traffic is actually encrypted or diagnosing a suspicious connection.
- Nessus / OpenVAS — infrastructure/network vulnerability scanners (as opposed to application-layer SAST/DAST) — check hosts and services for known CVEs and missing patches.
- Kali Linux — a Linux distribution that bundles most of the above (and hundreds more) preinstalled; the default OS most penetration testers work from.
101
Core security principles
secWhat is the CIA triad?
The foundational model for what "security" is actually protecting: Confidentiality (only authorized parties can read the data), Integrity (data can't be modified without detection), Availability (the system stays up and usable for legitimate users). Every vulnerability class ultimately threatens one or more of these three — SQL injection threatens confidentiality and integrity; a DoS threatens availability.
What's the difference between Authentication and Authorization?
Authentication (AuthN) — proving who you are (logging in, a valid token, MFA). Authorization (AuthZ) — once identity is confirmed, deciding what that identity is actually allowed to do. A huge share of real-world breaches are authorization failures, not authentication ones — someone legitimately logged in, but able to reach data or actions they shouldn't (this is exactly what OWASP's #1 category, Broken Access Control, covers).
What do "least privilege" and "defense in depth" mean in practice?
Least privilege — every user, service, and pipeline job gets only the minimum access it needs to do its job, nothing more (this is the same principle behind scoped Vault secrets and ephemeral CI runners covered earlier). Defense in depth — never rely on a single control; layer multiple independent protections (SAST catches it in code, a security gate catches it at release, a WAF catches it at runtime) so one control failing doesn't mean total compromise.
PT
XSS — Cross-Site Scripting
secWhat is XSS, and what are the different types?
XSS lets an attacker inject client-side script into content served to other users, so the victim's browser executes attacker code as if the site itself wrote it — inside the victim's own session, with their own cookies and permissions. Three main types, distinguished by where the payload comes from:
- Reflected — the payload rides in the current HTTP request (a URL parameter) and is echoed straight back in the response, unsanitized. Requires tricking the victim into clicking a crafted link — it's not persisted anywhere.
- Stored (persistent) — the payload is saved server-side (a comment, a profile field, a support ticket) and served back to every user who later views that page — no crafted link needed, which is why it's ranked more severe than reflected.
- DOM-based — the vulnerability lives entirely in client-side JavaScript: untrusted data from a DOM source (like
location.hash) flows into a dangerous DOM sink (likeinnerHTML) without ever touching the server. Server-side fixes don't protect against this at all.
How do you mitigate XSS?
Context-aware output encoding is the primary defense — encode for the specific context data lands in (HTML body, an HTML attribute, a JavaScript string, a URL); these all have different escaping rules, and most modern frameworks (React, Angular) do this by default unless you deliberately bypass it (e.g.
dangerouslySetInnerHTML). For rich text that must allow some HTML, sanitize on output with a library like DOMPurify rather than trying to blacklist tags yourself. Layer a strict, nonce-based Content Security Policy (CSP) on top as defense in depth — it can stop an XSS payload from executing even if one slips through encoding. A WAF that blocks obvious <script> patterns is a weak, easily-bypassed layer, not a substitute for the above.How do you actually test for XSS?
Inject a harmless proof-of-concept payload (classically
<script>alert(1)</script>, or an event-handler variant like "><img src=x onerror=alert(1)> when angle brackets are filtered) into every input — form fields, URL parameters, headers — and check whether it executes unescaped in the response, in the page source for stored XSS, or reaches a dangerous DOM sink for DOM-based XSS. Burp Suite and OWASP ZAP automate a large share of this by fuzzing every input with a library of known payloads; DOM-based XSS is harder to detect automatically because non-URL sources (like document.cookie) and non-HTML sinks (like setTimeout) often need manual source review. An alert box only proves execution — proving real impact means going further, e.g. showing the payload can steal a session cookie or perform an authenticated action.Reference: OWASP Testing Guide (WSTG-INPV-01/02, WSTG-CLNT-01), OWASP XSS Prevention & DOM-based XSS Prevention Cheat Sheets, PortSwigger Web Security Academy.
PT
SQL Injection
secWhat is SQL injection, and what are the different types?
SQLi happens when untrusted input is concatenated directly into a SQL query instead of being treated strictly as data, letting an attacker alter the query's logic. Three broad categories, based on how the attacker gets the data out:
- In-band (classic) — the attacker uses the same channel to launch the attack and see results. Union-based uses the SQL
UNIONoperator to append the attacker's own query results onto the legitimate ones in a single response. Error-based deliberately triggers database error messages to leak schema details (table/column names) from the error text itself. - Blind / inferential — the application shows no direct data or error, so the attacker infers information purely from behavior. Boolean-based injects a condition that's always true or false and watches whether the response content changes. Time-based injects a conditional
SLEEP()and measures whether the response is delayed. - Out-of-band (OOB) — used when there's no visible response or error at all; relies on the database's ability to make its own outbound DNS/HTTP request (e.g. Oracle's
UTL_HTTP, SQL Server'sxp_dirtree) to exfiltrate data to a server the attacker controls.
How do you mitigate SQL injection?
Parameterized queries / prepared statements are the primary, correct fix — the query structure and the data are sent to the database separately, so user input can never alter the query's logic no matter what characters it contains. ORM frameworks generally do this by default. Beyond that: apply least privilege to the database account the application uses (it shouldn't have permission to drop tables or read unrelated schemas), validate/allowlist input as a secondary layer, and make sure error handling never surfaces raw database error messages to the end user (which is exactly what error-based SQLi depends on).
How do you actually test for SQL injection?
Start simple: inject a single quote (
') into a parameter and see if it breaks the query (a 500 error or a database error message is a strong signal). Then probe systematically: try a boolean pair like ' OR '1'='1 vs ' OR '1'='2 and compare whether the response differs (boolean-based); try a payload with SLEEP(5) and see if the response is delayed by ~5 seconds (time-based); try appending a UNION SELECT with a matching column count to see if extra data appears in the response. In practice, this is exactly what automated tools like sqlmap or Burp Suite's active scanner do at scale rather than doing it payload-by-payload by hand — but understanding the manual logic behind each type is what lets you interpret and confirm what the tool reports.Reference: OWASP SQL Injection Prevention Cheat Sheet, PortSwigger SQL Injection guide.
PT
CSRF — Cross-Site Request Forgery
secWhat is CSRF, and what forms does it take?
CSRF tricks an already-authenticated victim's browser into submitting a state-changing request (transfer funds, change an email address, delete an account) to a site it's logged into, without the victim intending it — exploiting the fact that browsers automatically attach cookies to requests regardless of which site triggered them. This is the "confused deputy" problem: the server can't tell a genuine user-initiated request from one silently fired by a malicious page the victim happened to visit.
- Classic CSRF — a malicious page auto-submits a hidden form or image tag pointing at the target site's state-changing endpoint.
- SameSite=Lax bypass variants — since browsers now default cookies to
SameSite=Lax, attackers work around it using top-level navigations (a plain link orwindow.open) if the vulnerable action can be triggered via GET. - Client-side CSRF — in modern SPAs, the vulnerable component shifts from the server to client-side JavaScript itself, if it builds an authenticated
fetch()/XHR request using attacker-influenced data (a URL parameter,postMessage, localStorage).
How do you mitigate CSRF?
Layer multiple defenses rather than relying on just one: the synchronizer token pattern (a unique, unpredictable per-session CSRF token required on every state-changing request) for stateful apps, or double-submit cookies for stateless ones; the
SameSite cookie attribute as a strong but not sufficient defense-in-depth layer (Lax still allows some GET-triggered CSRF through top-level navigation); and validating the Origin/Referer header, failing closed if both are absent. Never rely on "just use POST instead of GET" alone — that blocks nothing on its own. Also worth remembering: any XSS vulnerability can be used to defeat CSRF tokens entirely, since a script running in the victim's own origin can simply read the token itself.How do you actually test for CSRF?
Capture a legitimate state-changing request in Burp Suite, then strip out the CSRF token (or the custom header carrying it) and replay it — if the server still accepts it, there's no real protection. If a token is present, also test with a token of identical length but a different value to confirm the server is actually validating it and not just checking for presence. Then check whether
SameSite is set and to which value, and whether the endpoint can be triggered via a simple GET request (which would allow a bypass even with Lax cookies).Reference: OWASP CSRF Prevention Cheat Sheet, PortSwigger CSRF guide, HackTricks CSRF.
PT
Scenario — login, register, forgot password
secAs a pentester, you're handed an app with a login page, a registration page, and a "forgot password" flow. Walk me through what you'd actually check.
These three pages share a common attacker goal — account takeover — so the checks overlap heavily:
- Username/email enumeration — does the app respond differently for a valid vs. invalid email on login, register, or forgot-password ("this email is already registered" vs. a generic message)? A different response, error message, status code, or even response time leaks which accounts exist — high-value recon for an attacker before a credential-stuffing or targeted attack.
- Brute force / credential stuffing — is there rate limiting, account lockout, or CAPTCHA on the login endpoint? Test by hammering it with repeated attempts.
- Password reset token strength and handling — is the reset token cryptographically random and single-use, or predictable/sequential? Does it expire in a reasonable window? Is it leaked anywhere it shouldn't be (in the URL, logged server-side, sent in a way an attacker on the network could intercept)? Can the token be reused after it's already been consumed?
- Password reset host header / link poisoning — if the reset link is built dynamically from the request's
Hostheader, can it be manipulated to send the victim a reset link pointing at an attacker-controlled domain? - Mass assignment on registration — does the registration endpoint accept extra, unexpected fields (e.g.
role: "admin"orisVerified: true) that shouldn't be client-settable, and does the backend blindly bind them? - CSRF on password change/reset — is a CSRF token required on the "set new password" or "change password while logged in" actions?
- Missing account lockout notification / no logging — does the legitimate user get notified of a password reset or repeated failed logins? Is the event logged for later investigation?
GIT
Git as version control
devWalk me through your typical Git workflow — branching, merging, resolving conflicts.
Feature-branch workflow — branch off
main/develop, commit small logical changes, open a merge/pull request, resolve conflicts locally with git merge or git rebase, then squash or merge after review. Mention git log, git diff, git blame for investigating history, and git stash for context-switching.Why does Git matter in a DevSecOps pipeline specifically (not just DevOps)?
Git is the first security control point. Secret scanning at commit/push time catches hardcoded credentials before they ever reach a remote repo — commonly done with gitleaks or TruffleHog, either as a local pre-commit hook or as a pre-built GitHub Actions step (e.g.
gitleaks/gitleaks-action or trufflesecurity/trufflehog action) that runs automatically on every push/PR without custom scripting. Branch protection rules and mandatory code review enforce the "shift-left" principle. Commit signing (GPG/Sigstore) supports software supply chain integrity.Reference: OWASP DevSecOps Guideline — "shift left" principles.
SDLC
SDLC
devWhat is SDLC and what are its phases?
The structured process for building software: Planning → Requirements → Design → Development → Testing → Deployment → Maintenance. Traditionally security was a separate, late-stage gate (often just before release) — which is exactly what SSDLC and DevSecOps were created to fix.
SSDLC
SSDLC (secure SDLC)
secWhat is SSDLC and how is it different from plain SDLC?
Embeds security activities into every phase of the SDLC rather than testing at the end:
- Planning → security requirements, compliance mapping
- Design → threat modeling
- Development → secure coding standards + SAST
- Testing → DAST / IAST / SCA
- Deployment → configuration hardening, IaC scanning
- Maintenance → continuous monitoring, patching
Reference: NIST SP 800-218 (SSDF), OWASP SAMM.
RISK
Initial risk assessment vs. application risk assessment
secWhat's the difference between an "Initial Risk Assessment" and an "Application Risk Assessment"?
Initial risk assessment: a lightweight, early-stage triage — usually done at project intake or design phase — that classifies the app's risk tier (High/Medium/Low) based on data sensitivity, exposure, and business criticality. It decides how much security rigor the rest of the SDLC needs (a full threat model and pentest, or just a baseline scan).
Application risk assessment: a comprehensive, application-specific, ongoing evaluation of the risks that initial assessment flagged — likelihood × impact scoring, existing controls, residual risk, and remediation/risk-acceptance decisions. It's iterative and revisited throughout the SDLC and in production, scoped to that specific application's architecture and data flows.
One-liner: "Initial risk assessment scopes how much security an application needs; application risk assessment is the ongoing, application-specific process of measuring and treating that risk."
Application risk assessment: a comprehensive, application-specific, ongoing evaluation of the risks that initial assessment flagged — likelihood × impact scoring, existing controls, residual risk, and remediation/risk-acceptance decisions. It's iterative and revisited throughout the SDLC and in production, scoped to that specific application's architecture and data flows.
One-liner: "Initial risk assessment scopes how much security an application needs; application risk assessment is the ongoing, application-specific process of measuring and treating that risk."
Reference: NIST SP 800-30, ISO 27005.
What if there's no workflow, data flow diagram, documentation, or architecture yet — just a business idea? How do you do an initial risk assessment then?
This is actually the normal starting point for initial risk assessment, not an edge case — at the idea stage there's nothing to diagram yet. Instead of analyzing artifacts, it's done through a short, structured intake questionnaire that scopes risk from business-level answers alone:
- What data will this handle? (public info vs. PII vs. payment data vs. health data — data sensitivity is the single biggest driver of risk tier)
- Who's the user base, and is it internet-facing, internal-only, or B2B?
- Does it involve authentication, payments, or third-party/vendor integrations?
- What regulatory scope does that trigger? (GDPR, PCI DSS, HIPAA, local data-residency law)
- What's the business criticality if it's compromised or unavailable?
RISK
Application risk assessment vs. threat modeling
secHow is an Application Risk Assessment different from Threat Modeling?
Application risk assessment is asset/business-driven: "What could go wrong with this app, how likely, how bad, is it acceptable?" Broad, often compliance-oriented.
Threat modeling is architecture/design-driven: "Given this system's data flows and trust boundaries, what are the concrete attack paths, and what controls mitigate each?" Technical, structured, per-application.
Framing: Risk assessment answers "should we worry?" — threat modeling answers "worry about what, exactly, and how do we stop it?"
Threat modeling is architecture/design-driven: "Given this system's data flows and trust boundaries, what are the concrete attack paths, and what controls mitigate each?" Technical, structured, per-application.
Framing: Risk assessment answers "should we worry?" — threat modeling answers "worry about what, exactly, and how do we stop it?"
TM
Threat modeling methods
secWhere does threat modeling actually happen in the SDLC, and when should it be triggered?
Primarily at the design phase — after requirements are known but before code is written, while the architecture is still cheap to change. But it isn't a one-time checkbox: it should be re-triggered whenever the attack surface meaningfully changes — a new feature that touches sensitive data, a new external integration or trust boundary, a significant architecture change, or a new authentication/authorization flow. Best practice is a lightweight initial pass at design time for every feature, with a deeper session reserved for high-risk features (the ones an initial risk assessment already flagged as High tier).
Name a threat modeling methodology and explain it.
STRIDE (Microsoft) — categorizes threats by type:
- Spoofing – impersonating identity
- Tampering – modifying data/code
- Repudiation – denying an action occurred
- Information disclosure – exposing data
- Denial of service – degrading availability
- Elevation of privilege – gaining unauthorized access
Reference: Microsoft SDL Threat Modeling, OWASP Threat Modeling Cheat Sheet.
TM
Threat modeling tools
secWhat tools have you seen used for threat modeling?
- IriusRisk — commercial, automates threat generation from architecture diagrams, maps to countermeasures and compliance frameworks.
- Microsoft Threat Modeling Tool — free, STRIDE-based, diagram-driven.
- OWASP Threat Dragon — free/open source, similar diagram + STRIDE approach.
- pytm — code-as-threat-model (Python), good for CI integration.
TM
Scenario — threat modeling a register/email function
secTake a "register with email" function. What threats apply, and which model fits best?
STRIDE is the right fit here — it's a single, well-scoped function with clear trust-boundary crossings, and every STRIDE category maps onto something concrete:
- Spoofing — registering with someone else's email to impersonate them, or automated bot registration at scale.
- Tampering — mass assignment: sending extra fields in the request body (
role: "admin",isVerified: true) that the backend shouldn't accept from the client but blindly binds anyway. - Information disclosure — the strongest, most likely threat on this specific function: username/email enumeration — if the response (message, status code, or timing) differs for "email already registered" vs. "registration successful," an attacker can silently map out every valid account on the platform before ever attempting to log in.
- Denial of service — registration spam/bot flooding, or "email bombing" a victim's inbox with verification emails triggered by repeated registration attempts using their address.
- Elevation of privilege — same root cause as the tampering case above (mass assignment), if it lets a new account register with elevated permissions.
- IDOR — less relevant to registration itself (there's no existing resource to reference by ID yet) but becomes directly relevant one step later, at email verification or profile completion, if a verification link or profile ID can be guessed/incremented to affect a different user's account.
TM
Scenario — threat modeling a login function
secNow take the login function. What threats apply, and which model fits best?
STRIDE again, since login is the single highest-value trust boundary in the entire application — every category applies with real, common examples:
- Spoofing — the headline threat here: credential stuffing (reusing breached password lists) and brute force against weak or unrestricted login attempts.
- Tampering — manipulating request parameters (a hidden role field, a JWT payload if it isn't properly signature-verified) to escalate privilege post-authentication.
- Repudiation — no logging of login attempts (successful or failed) means no audit trail if an account compromise needs to be investigated later.
- Information disclosure — username enumeration again (a different error for "wrong password" vs. "no such account" — the correct fix is one identical generic message for both), and verbose error messages that leak stack traces or backend details.
- Denial of service — two distinct flavors: flooding the login endpoint itself, and account lockout abuse — an attacker deliberately triggering a victim's own lockout policy by repeatedly failing their login, denying the legitimate user access.
- Elevation of privilege — session fixation (reusing a pre-login session ID after authentication instead of issuing a fresh one) and insufficient authorization checks immediately after a successful login.
Reference: OWASP Authentication Cheat Sheet, OWASP ASVS (Authentication requirements).
FUND
DevOps vs. DevSecOps
secIn one sentence, what's the difference between DevOps and DevSecOps?
DevOps optimizes for speed and collaboration between Dev and Ops through automation; DevSecOps adds security as a shared, continuous responsibility embedded into every pipeline stage rather than a final gate — "shift security left" without slowing delivery down.
CI/CD
What is a pipeline / CI/CD
devExplain CI/CD in your own words.
CI — developers frequently merge code into a shared repo, triggering automated build + test to catch integration issues early. CD — automatically packaging and (optionally) releasing that validated build to staging/production. A pipeline is the automated sequence of stages (build → test → security scan → deploy) defined as code, so every change goes through the same repeatable, auditable process.
CI/CD
CI/CD tools & Tekton
devWhat CI/CD tools have you worked with, and what else is common in the market?
Real experience: GitLab CI/CD. Also common, in rough order of enterprise prevalence:
- Jenkins — the original extensible CI server, plugin-based, self-hosted, master/agent architecture.
- Azure DevOps Pipelines — tightly integrated with Azure Boards/Repos; many similar DevSecOps roles specifically call this out.
- GitLab CI/CD — pipeline-as-code (
.gitlab-ci.yml) built directly into the Git platform. - GitHub Actions — event-driven, YAML workflows, huge marketplace of pre-built actions (including security scanners).
What is Tekton, and is it for OpenShift or Kubernetes? How is it different from a "regular" CI/CD tool?
Tekton is an open source, Kubernetes-native CI/CD framework (a Continuous Delivery Foundation project) — it isn't tied to OpenShift specifically, it runs on any Kubernetes cluster. Pipelines, tasks, and triggers are all defined as Kubernetes Custom Resource Definitions (CRDs), so a pipeline run is just a pod scheduled by the cluster itself, using the same scaling and resource management as any workload.
"Managed Tekton" = OpenShift Pipelines — Red Hat's own distribution/product built on top of upstream Tekton, integrated into the OpenShift console, CLI (
Difference from a "regular" CI/CD tool (Jenkins, GitLab CI): traditional tools run their own dedicated server/agent infrastructure outside the cluster. Tekton has no separate server at all — the pipeline is Kubernetes resources, so it inherits the cluster's RBAC, scaling, and observability instead of needing a separate one bolted on. Common pairing: Tekton for CI + ArgoCD for CD (GitOps).
"Managed Tekton" = OpenShift Pipelines — Red Hat's own distribution/product built on top of upstream Tekton, integrated into the OpenShift console, CLI (
tkn), and IDE plugins. So: Tekton = the open source engine, OpenShift Pipelines = Red Hat's managed, supported packaging of that engine for OpenShift specifically.Difference from a "regular" CI/CD tool (Jenkins, GitLab CI): traditional tools run their own dedicated server/agent infrastructure outside the cluster. Tekton has no separate server at all — the pipeline is Kubernetes resources, so it inherits the cluster's RBAC, scaling, and observability instead of needing a separate one bolted on. Common pairing: Tekton for CI + ArgoCD for CD (GitOps).
Reference: Red Hat OpenShift Pipelines documentation, tekton.dev.
CI/CD
CI/CD stages — DevOps vs. DevSecOps
devWhat are the CI/CD stages in a standard DevOps pipeline?
Source → Build → Unit test → Package/artifact → Deploy (staging) → Integration test → Deploy (production) → Monitor.
How does that change for a DevSecOps pipeline?
Source (secret scan, pre-commit) → Build (SAST) → Package (SCA/SBOM, IaC scan) → Test (DAST, IAST, container image scan) → Release (triage/false-positive review, artifact signing, policy gate) → Deploy (secure config check) → Operate/Monitor (cloud posture, SIEM, runtime protection).
Good phrase: "Every DevOps stage gets a corresponding security gate — it's the same pipeline, just with security checkpoints layered in, not bolted on at the end."
Good phrase: "Every DevOps stage gets a corresponding security gate — it's the same pipeline, just with security checkpoints layered in, not bolted on at the end."
CI/CD
CI/CD runners / agents
devWhat is a CI/CD runner or agent, what types exist, and how do you choose between them?
A runner/agent is the process (often inside a container or VM) that actually executes a pipeline job — checks out code, runs the build/test/scan commands, then reports status back to the CI server.
Types:
Types:
- Hosted/shared (GitHub-hosted runners, GitLab SaaS runners) — fully managed, zero maintenance, spun up fresh per job. Fast to start, but no access to private/internal networks and less control over the environment.
- Self-hosted (Jenkins agents, GitLab Runner, GitHub self-hosted runner) — you own the infrastructure. Needed when the pipeline must reach internal/on-prem systems, use specific hardware, or meet data-residency/compliance requirements common in banking and government work.
- Ephemeral vs persistent — ephemeral runners (spun up per job, e.g. via a Kubernetes plugin or Docker executor, then destroyed) are preferred for security since nothing persists between jobs — no leftover secrets, no cross-job contamination. Persistent/static agents are simpler to manage but riskier if compromised, since state and credentials can linger.
CI/CD
Pull requests & branch protection
devHow do you make sure code only merges after it passes all checks?
Configure branch protection rules (GitHub/GitLab/Azure Repos) on
main: require the pull request to pass all defined required status checks (build, unit tests, SAST, SCA) before the merge button is even enabled, require at least one approving review, and optionally require branches to be up to date before merging. The pipeline reports each check's pass/fail status directly on the PR, so a failing SAST scan blocks the merge exactly the same way a failing unit test would — security becomes a merge blocker, not an afterthought.GATE
Quality gate vs. security gate
secWhat's the difference between a quality gate and a security gate, and how do you decide when a scan should pass or block the pipeline?
A gate is an automated checkpoint in the pipeline with a pre-agreed, documented threshold — the pipeline only continues if the results are within that threshold; otherwise it fails the build.
Quality gate (e.g. SonarQube quality gate): code-quality metrics — test coverage percentage, code duplication, maintainability rating, number of code smells.
Security gate: vulnerability-based thresholds from SAST/SCA/DAST/IAST results — for example "block the build if any Critical or unapproved High severity finding exists; Medium/Low findings are logged but don't block." The threshold is agreed in advance with stakeholders (a pre-approved risk-acceptance list for known, tracked exceptions), so the gate is predictable rather than an argument every release.
This is exactly the kind of policy a dedicated application security triaging service exists to help tune — getting the threshold right so it blocks real risk without drowning teams in false-positive-driven build failures.
Quality gate (e.g. SonarQube quality gate): code-quality metrics — test coverage percentage, code duplication, maintainability rating, number of code smells.
Security gate: vulnerability-based thresholds from SAST/SCA/DAST/IAST results — for example "block the build if any Critical or unapproved High severity finding exists; Medium/Low findings are logged but don't block." The threshold is agreed in advance with stakeholders (a pre-approved risk-acceptance list for known, tracked exceptions), so the gate is predictable rather than an argument every release.
This is exactly the kind of policy a dedicated application security triaging service exists to help tune — getting the threshold right so it blocks real risk without drowning teams in false-positive-driven build failures.
CI/CD
CI/CD integration with ticketing / tracking
devHow does a pipeline integrate with tools like Jira, ServiceNow, Trello, or Azure DevOps Boards, and what's the use case?
When a scan (SAST/SCA/DAST) finds a new confirmed issue, the pipeline (often via an ASPM tool — see below) automatically opens a ticket in the team's tracker rather than leaving it buried in a scan report:
- Jira / Azure DevOps Boards — most common for dev teams; ticket auto-assigned to the code owner (via
CODEOWNERSor component mapping), tagged with severity, linked back to the specific commit/file/line. - ServiceNow — common in larger/regulated enterprises (government/banking client environments in particular) for formal change and incident management, and for feeding security findings into a broader GRC/audit workflow.
- Trello — lighter-weight, more common for smaller teams or informal triage boards.
TOOLS
DevSecOps tools — overview
secWhat categories of security tools exist across the pipeline, and where does each fit?
SAST (code, pre-build), SCA (dependencies, build), IAST (runtime + code, test), DAST (running app, black-box, test/staging), IaC scanning (Terraform/Ansible/YAML, pre-deploy), container/image scanning (build/registry), ASPM (correlates everything above, release stage onward), and cloud security posture management + SIEM (runtime, operate/monitor).
SAST
SAST — and custom rules
secWhat is SAST, and why would you write custom rules?
Static Application Security Testing analyzes source code or bytecode without executing it to find vulnerabilities like injection flaws, insecure crypto use, or hardcoded secrets — typically at commit/build time.
Custom rules matter because out-of-the-box rulesets generate noise or miss org-specific risks — e.g. flagging a deprecated internal crypto library, or enforcing that DB queries go through a sanitized wrapper. Tuning rules is also how false positives are reduced, which matters directly here since triaging is often its own paid service line for exactly this problem.
Custom rules matter because out-of-the-box rulesets generate noise or miss org-specific risks — e.g. flagging a deprecated internal crypto library, or enforcing that DB queries go through a sanitized wrapper. Tuning rules is also how false positives are reduced, which matters directly here since triaging is often its own paid service line for exactly this problem.
Commercial: Fortify SAST, Black Duck Coverity. Open source: SonarQube, Semgrep.
What's the actual difference between a "custom rule," "tuning," and "sanitizing" in SAST — these get used almost interchangeably.
They're related but distinct actions:
- Custom rule — writing a brand-new detection rule from scratch for something the tool has no built-in rule for at all — usually an organization-specific pattern: a proprietary database access layer, an internal auth middleware that every route is supposed to use, a home-grown serialization format. No default rule can catch a violation of a pattern the vendor never knew existed.
- Tuning — adjusting the behavior of a rule that already exists: disabling a rule that's irrelevant to this codebase (e.g. turning off XXE checks for an app with no XML parser at all), changing a default severity, or narrowing a rule's scope so it only fires in the contexts that actually matter here.
- Sanitizing (a.k.a. teaching the tool about a sanitizer) — the most targeted of the three: telling the tool that a specific internal function is a trusted sanitizer, so it stops treating data that passed through that function as still "tainted." Without this, a SAST tool will keep flagging a SQL query as vulnerable even though the input already passed through the team's own validated, safe wrapper function — because the tool has no way of knowing that wrapper is safe unless it's told.
Walk me through how you'd actually go about writing a custom rule, tuning it, and defining a sanitizer.
Most modern SAST tools (Semgrep is the common example, and GitLab's Advanced SAST analyzer works the same way) expose this through a rule configuration file rather than requiring you to modify the scanner itself:
- 1. Write the custom rule — define, in the tool's rule syntax (Semgrep uses YAML with a pattern-matching DSL), the exact code pattern to flag — e.g. "any call to
legacyDbLayer.rawQuery()where the argument isn't wrapped bysanitize()first." You can build and test the pattern in the tool's own rule playground before deploying it. - 2. Tune it — after the first few scans, review what it's flagging: disable it in contexts where it doesn't apply, adjust the severity to match real risk, and narrow the pattern if it's over-matching innocuous code.
- 3. Define the sanitizer — most rule engines let you explicitly declare a function as a sanitizer inside the rule definition itself, so the tool's data-flow/taint analysis treats any value that has passed through it as clean and stops tracking it as tainted from that point onward.
- 4. Re-scan and repeat — tuning isn't a one-time setup step; track the false-positive rate over time (industry figures put an untuned SAST tool at roughly 30–60% false positives, dropping to 10–20% once genuinely tuned) and revisit rules after major refactors or framework migrations, since that's exactly when a previously-accurate rule starts misfiring again.
Reference: Semgrep custom rules documentation, GitLab SAST ruleset customization docs, appsecsanta.com SAST false-positive tuning guide.
SCA
SCA and SBOM
secWhat is SCA, and what is an SBOM?
Software Composition Analysis scans open-source/third-party dependencies for known CVEs and license risks. An SBOM is the structured, machine-readable inventory of every component/library/version — an "ingredients list." SBOMs are increasingly a compliance requirement (e.g. US Executive Order 14028), and SCA tools are what generate/verify them. Standard format to name: CycloneDX (also SPDX).
Commercial: Black Duck SCA (industry leader — worth emphasizing if the target company is a certified Black Duck service provider). Open source: OWASP Dependency-Check, Dependency-Track.
DAST
DAST
secWhat is DAST and when do you run it?
Tests a running application from the outside — black-box, no source access — simulating real attacker behavior (SQLi, XSS, auth bypass) against a live/staging endpoint. Runs later in the pipeline than SAST.
Commercial: Fortify WebInspect, Invicti DAST (proof-based/verified scanning — confirms a finding is truly exploitable rather than a guess, which cuts false positives sharply). Open source: OWASP ZAP, Burp Suite Community.
IAST
IAST
secWhat is IAST and how is it different from SAST and DAST?
Combines both worlds — an agent instruments the app from inside during functional/QA testing, seeing real execution paths (like DAST) with source-level precision (like SAST). Lower false-positive rate since it confirms a vulnerability was actually reached/exploited during a real test run.
Commercial: Black Duck Seeker (formerly Synopsys Seeker). Very few strong open source options — mostly a commercial category.
ASPM
ASPM / centralized management dashboards
secWhat is ASPM, and what tools would you use to centralize findings from all your scanners?
Application Security Posture Management (ASPM) sits above individual scanners — it ingests findings from SAST, DAST, SCA, IAST, container, and IaC tools, deduplicates the same issue found by multiple scanners into one entry, prioritizes by real risk (not just raw CVSS), and routes tickets to the right developer. It's the layer that turns "five scanners, five noisy reports" into one prioritized backlog.
- DefectDojo — open source ASPM/vulnerability management; widely used to aggregate results from many different scanners for free.
- Fortify SSC (Software Security Center) — Fortify's own on-prem aggregation and workflow dashboard for its SAST/DAST results.
- Black Duck SRM (Software Risk Manager, formerly Code Dx) — Black Duck's ASPM platform; correlates findings from 150+ tools (not just Black Duck's own) into one prioritized, deduplicated view with compliance mapping.
- Black Duck Polaris — distinct from SRM: Polaris is the unified SaaS engine platform that runs Coverity (SAST), Black Duck SCA, and Seeker (DAST/IAST) together under one UI; its results typically feed into SRM for cross-tool correlation.
- Invicti ASPM (formerly Kondukto, now merged with Invicti's proof-based DAST) — vendor-agnostic ASPM that connects 100+ scanners and CI/CD systems, distinguished by feeding proof-based DAST results in as verified/exploit-confirmed findings.
Say a security gate blocks the build with 20 findings. How do you actually automate confirming they're false positives, instead of manually reviewing all 20 every release — is there a way to use AI for this?
Yes — and this has become a real, mainstream ASPM capability rather than a hypothetical, though it's worth being precise about what the AI is actually doing versus what stays deterministic:
- The detection engine stays rule-based and deterministic. Nearly every serious vendor (Semgrep, Checkmarx, Invicti, Cycode) is explicit about this: the actual vulnerability detection is still traditional taint/pattern analysis — AI is layered on top for triage, prioritization, and remediation suggestions, not for deciding what counts as a vulnerability in the first place. Treating AI as the detector itself, rather than the triager, is the wrong mental model.
- Reachability analysis does most of the heavy lifting first — before AI even enters the picture, checking whether the vulnerable function is actually called anywhere reachable in your code (not just present in a dependency) is what several tools report as eliminating up to 90%+ of noise on its own, since an unreachable finding is a false positive for practical purposes regardless of what a CVE database says.
- On top of that, AI-driven exploitability triage classifies each remaining finding into a bucket — false positive / acceptable risk / genuinely exploitable — using the code's actual context (is the input really attacker-controlled here, does a sanitizer sit in the path, is this endpoint actually internet-facing). Vendors report this cutting remaining false positives dramatically further.
- Governance stays human — the honest, defensible version of this workflow is AI proposes the classification and a remediation diff, a human (or an already-agreed policy) approves it, and nothing auto-merges without that review trail. That audit trail matters a lot in a regulated, banking/government client context — "the AI decided" is not an acceptable answer in an audit.
Reference: Cycode AI Exploitability Agent, Checkmarx Triage & Remediation Assist, Semgrep reachability analysis, Invicti proof-based scanning documentation.
TOOLS
Famous security scan tools — quick reference
sec| Category | Open source | Commercial (focus) |
|---|---|---|
| SAST | SonarQube, Semgrep | Fortify, Black Duck Coverity |
| SCA / SBOM | Dependency-Check, Dependency-Track, CycloneDX | Black Duck SCA |
| IAST | — limited options | Black Duck Seeker |
| DAST | OWASP ZAP, Burp Suite Community | Fortify WebInspect, Invicti DAST |
| ASPM / dashboard | DefectDojo | Black Duck SRM, Fortify SSC, Invicti ASPM |
| IaC scan | Checkov, tfsec | — |
| Container/image scan | Trivy | — |
| Secret scan | gitleaks, TruffleHog | — |
If a scanner throws 200 findings on a legacy app, what do you do first?
Triage — separate true positives from false positives (literally a paid AppSec service line), prioritize by severity + exploitability + exposure (not CVSS score alone), and tune the ruleset so the same noise doesn't repeat next scan. An ASPM tool automates most of this correlation step.
SUPPLY
Supply chain attacks in CI/CD
secWhat are supply chain attacks in a CI/CD context, and how do you harden the pipeline against them?
A supply chain attack compromises something the pipeline trusts — a dependency, a build tool, a runner, or the pipeline definition itself — rather than attacking the application code directly. Common patterns: a malicious/typosquatted package pulled in as a dependency, dependency confusion (a public package with the same name as an internal private one gets installed instead), a compromised CI runner used to inject malicious code into a build, or a poisoned base image pulled from an untrusted registry.
Hardening the pipeline:
Hardening the pipeline:
- Pin dependency versions and use lockfiles; pull from a private, proxied registry (Artifactory/Nexus) rather than public registries directly.
- Run SCA/SBOM on every build so unexpected new dependencies are visible immediately.
- Use ephemeral, least-privilege runners (see the runners section) so a compromised job can't persist or affect the next one.
- Sign commits and artifacts (Sigstore/cosign) and verify signatures before deploy — this is what the SLSA (Supply-chain Levels for Software Artifacts) framework formalizes as build provenance.
- Enforce branch protection + mandatory review so nobody can push directly to
mainor modify pipeline YAML unreviewed. - Restrict runner network egress so a compromised job can't exfiltrate secrets or call out to an attacker-controlled host.
Reference: SLSA framework (slsa.dev), OWASP CI/CD Security Top 10.
SCAN
How a secret scan actually runs
secWalk me through, step by step, how a secret scanner actually finds a leaked credential.
It varies by tool, but in general every secret scanner (gitleaks, TruffleHog, GitHub secret scanning) runs the same broad sequence:
- 1. Ingest the content — not just the current files, but the full Git history: every commit, every branch, every diff, even files that were later deleted. A secret committed and removed two years ago is still sitting in
.githistory unless the history itself is rewritten. - 2. Chunk it — the tool splits the repository content into manageable pieces (per file, per commit diff) so it can process them in parallel.
- 3. Detect candidates, two ways combined:
- Regex / rule matching — hundreds of known patterns for specific formats: AWS keys start with
AKIA, GitHub tokens have their own prefix, private keys start with-----BEGIN PRIVATE KEY-----, database connection strings follow a recognizable shape. - Entropy analysis — real secrets are close to random, so they have high Shannon entropy (a measure of randomness per character). A string that's high-entropy AND matches a plausible secret shape gets flagged even if it doesn't match any named pattern — this is what catches a custom internal API key with no distinguishing prefix.
- Regex / rule matching — hundreds of known patterns for specific formats: AWS keys start with
- 4. Filter noise — allowlists strip out known-fake values (documentation examples like AWS's own
AKIAIOSFODNN7EXAMPLE, test fixtures, placeholder strings). - 5. (Optional) Verify — some tools, notably TruffleHog, go one step further: they take the candidate and make a live API call to the actual provider (e.g. a test call to the Stripe API) to confirm the credential is still active. A live, verified secret is treated as a P0 — confirmed, not just suspected.
- 6. Report — commit SHA, file path, line number, a redacted preview of the match, and (if verified) confirmation the credential is actually exploitable right now.
Why do some tools verify secrets via a live API call, and what's the tradeoff?
Regex + entropy tells you a string looks like a secret. Verification tells you it is one — right now. That distinction matters enormously for triage: a scan with 40 "possible" hits nobody has time to check gets ignored; a scan with 2 "confirmed live" hits gets fixed the same day. The tradeoff is that verification requires making real network calls to third-party providers as part of the scan, which needs to be scoped and rate-limited carefully in CI so it doesn't itself look like abuse.
Where does secret scanning actually run in the pipeline?
Three places, ideally all three: (1) a pre-commit hook on the developer's machine — fastest feedback, blocks the secret before it's even committed locally; (2) a pre-push / PR check in CI, scanning the diff of the branch; (3) a periodic full-history scan of the whole repository, since secrets committed before scanning was ever set up are still sitting in history until someone finds and rotates them.
SCAN
How a SAST scan actually runs
secBefore it can even analyze anything, how does a SAST tool figure out what language and framework it's actually looking at?
Mostly the same way a human would glance at a repo: file extensions (
.java, .py, .go) and manifest/build files that name the stack explicitly — package.json and framework dependencies for Node/React, pom.xml/build.gradle for Java/Spring, requirements.txt/Pipfile for Python/Django, go.mod for Go. Tools like GitLab SAST literally run a detection pass over the repo first, then select and hand off to the matching language-specific analyzer. This is also why SAST coverage is uneven — a tool is only as good as its support for your specific stack; a generic multi-language scanner often misses framework-specific idioms (e.g. Spring or Rails conventions) that a dedicated single-language scanner (Brakeman for Rails, Bandit for Python) would catch.Once the language is identified, what actually happens next — does the tool compile and build the code?
Depends on the language and the tool:
- Interpreted languages (Python, JavaScript, Ruby) — the tool typically parses the source text directly into a syntax tree; no compilation needed.
- Compiled languages (Java, C#, C/C++) — some tools need a full or partial build to resolve types, dependencies, and cross-file references accurately, especially for deep semantic analysis; others parse source without building, trading some accuracy for speed and not needing a working build environment in the pipeline.
- Bytecode/binary analysis — some tools (e.g. for Java) can alternatively analyze compiled
.class/bytecode or even binaries directly, useful when source isn't available.
Does the tool translate everything into some kind of intermediate representation? What does that actually look like?
Yes — this is the core of how SAST works, regardless of language:
- Lexical analysis (tokenizing) — the raw text is broken into tokens: keywords, identifiers, operators.
- Syntax analysis (parsing) — tokens are assembled into an Abstract Syntax Tree (AST), a tree that represents the code's grammatical structure regardless of formatting or whitespace.
- Building further models on top of the AST — a Control Flow Graph (CFG), mapping every possible execution path (if/else branches, loops, function calls), and a Data Flow Graph (DFG), tracking how values move between variables. Some enterprise tools (Veracode is a good example to name) go further and convert everything into one Common Intermediate Representation shared across all supported languages, so the exact same detection logic runs identically whether the source was Java or C#.
What analysis techniques actually run on top of that model to find a vulnerability?
Three layered techniques, from simplest to most powerful:
- Pattern/signature matching — the fastest, simplest technique: look for known-bad code shapes directly in the AST (a call to a deprecated crypto function, a hardcoded string that looks like a credential). Fast, few false positives, but only catches obvious cases.
- Control flow analysis — walks the CFG to understand branches and loops, catching logic flaws like a security check that can be bypassed under certain conditions.
- Data flow / taint analysis — the real differentiator for a good SAST tool. It marks untrusted input as "tainted" at its source (e.g.
request.getParameter()), then follows that tainted value across the DFG through every assignment and function call, checking whether it reaches a dangerous sink (a SQL query, a file write, aneval()) without passing through a sanitizer along the way. If tainted data reaches a sink unsanitized — that's the SQL injection or XSS finding.
Reference: Wiz "What is SAST", Checkmarx/Cycode SAST technical guides, appsecsanta.com.
SCAN
How a DAST scan actually runs
secWalk me through, step by step, how a DAST scan actually runs against a live application.
- 1. Target identification — the scanner is pointed at a URL, or in API-focused testing, at an OpenAPI/Swagger spec or GraphQL introspection endpoint.
- 2. Authentication — if the app requires login, the scanner establishes and maintains an authenticated session (cookies, bearer tokens, SSO flow) so it can reach protected routes, since that's often where the highest-impact issues live.
- 3. Crawling / spidering — the tool maps the entire attack surface: following links, submitting forms, parsing client-side JavaScript. Modern single-page apps need an AJAX spider since content loads dynamically and there's no static HTML to follow — any endpoint the crawler misses simply never gets tested.
- 4. Attack simulation — against every discovered input (form field, URL parameter, header), the scanner fires crafted payloads targeting specific vulnerability classes: SQL injection strings, XSS vectors, path traversal sequences, malformed headers — largely mapped to the OWASP Top 10.
- 5. Response analysis — the tool inspects the application's responses for signs the attack landed: error messages, unexpected behavior, a reflected payload, a timing difference. Some newer scanners (Invicti's "proof-based scanning" is the named example) go further and safely confirm exploitability rather than inferring it from the response alone — which is what cuts false positives sharply.
- 6. Reporting — findings compiled with the request/response pair that triggered them, so a developer can reproduce it directly.
Reference: Wiz "DAST Scanning", PortSwigger/Burp Suite documentation, Invicti technical blog.
What makes DAST harder to run well than it sounds?
Authentication handling (session-based, token-based, SSO — the scanner needs the right method for your app or protected routes never get tested), single-page apps needing an AJAX spider instead of a traditional HTML crawler, and business logic flaws (can a user reach data they shouldn't, can a multi-step workflow be chained into an attack) that no automated scanner reliably catches — those still need human penetration testing on top of DAST.
SCAN
How an IAST scan actually runs
secHow does IAST actually observe what's happening inside the application while it's running?
Through instrumentation — an agent, sensor, or runtime hook is attached to the application in a QA/staging environment, before or as it starts:
- Compiled/VM languages (Java, .NET) — typically bytecode instrumentation: the agent registers with the runtime at startup (in Java, via the
-javaagentflag and the JVM'sInstrumentationAPI) and rewrites each class's bytecode as it loads, inserting hooks around security-sensitive calls (database queries, file I/O, deserialization) — with zero changes to the actual source code. - Dynamic languages (Python, Node.js, Ruby) — usually monkey-patching: the agent swaps out sensitive functions/methods at runtime with instrumented wrapped versions.
Reference: New Relic/OpenTelemetry Java instrumentation internals, Raven.io/ZetCode IAST guides.
Why does IAST have such a low false-positive rate compared to SAST, and what's the catch?
Because it only reports a vulnerability that was actually reached and exercised during a real test run — not a theoretical code path a static tool merely traced on paper. The catch is the flip side of that strength: IAST's coverage is exactly as good as the test suite driving it. A vulnerable function that no test ever calls is invisible to IAST, no matter how dangerous it is. It also only supports platforms with an available agent, and instrumentation adds some runtime performance overhead.
SCAN
How an SCA scan actually runs
secWalk me through, step by step, how an SCA scan actually runs.
- 1. Parse manifests and lockfiles —
package.json/package-lock.json,pom.xml,requirements.txt,go.mod,Gemfile.lock. The manifest says what you asked for; the lockfile has the exact resolved version actually installed — SCA needs both. - 2. Build the full dependency tree — not just direct dependencies (the ones you explicitly added), but every transitive dependency underneath them. A project with 20 direct dependencies can easily pull in 500+ total packages once transitive dependencies are resolved — and most real-world vulnerabilities live in that transitive layer (Log4Shell is the textbook example: most affected applications never declared Log4j directly — it arrived buried inside Spring Boot, Solr, or Elasticsearch).
- 3. Correlate against vulnerability databases — match each component's exact version against the NVD, GitHub Security Advisories, OSV, and vendor-specific feeds to find known CVEs. This step is matching, not discovery — SCA doesn't find new vulnerabilities, it tells you whether a vulnerability someone else already found and published affects a component you're using.
- 4. License analysis — flag copyleft licenses (GPL-style) that could force obligations on your own codebase if shipped commercially.
- 5. Generate the SBOM — the same inventory built in step 2, exported in a standard machine-readable format (CycloneDX or SPDX) so it can be shared, audited, or instantly re-checked the moment a new CVE is published.
- 6. (Advanced) Reachability analysis — the more mature tools go one step further and check whether the vulnerable function inside that dependency is actually called anywhere in your code, using static call-graph analysis. A CVE in a function you never invoke is far lower priority than one on a path your app actually executes — this is the single biggest lever for cutting SCA false-positive noise.
Reference: Wiz "SCA Scanning", Chainguard/appsecsanta SCA technical guides.
Why can't SCA just scan the manifest file alone and skip the lockfile?
The manifest only shows direct dependencies and often a loose version range (e.g.
^2.0.0), not the exact version actually installed. The lockfile pins the precise resolved version for every package, direct and transitive — without it, an SCA tool is guessing at what's really running rather than matching against what's really there.IAC
Infrastructure as Code + IaC scanning
opsWhat tools do you use for IaC, and how do you scan it for security issues?
Author infrastructure in Terraform, configuration in Ansible (or Kubernetes YAML). Before
apply, run static scanners against the IaC files themselves — Checkov or tfsec — catching misconfigurations (e.g. a public S3 bucket, a security group open to 0.0.0.0/0) before anything is ever provisioned.DOCKER
Docker and image scanning
opsHow do you secure a container image before it goes to production?
Scan the built image with Trivy (or Grype) for OS/package CVEs, use minimal base images (distroless/alpine), avoid running as root, and push only signed/scanned images — gate the pipeline so critical-CVE images can't be promoted.
What's a container registry, and which have you used?
Stores and versions container images, like Git does for code. Common ones: Docker Hub, Amazon ECR, Azure Container Registry, GitLab Container Registry, Harbor (self-hosted, OSS).
NET
Encrypting communication between containers
opsHow do you encrypt communication between Docker containers?
A few layers, usually combined:
- Overlay network encryption — Docker Swarm supports
--opt encryptedon an overlay network, encrypting traffic between hosts at the network layer automatically. - TLS between services — terminate TLS in the application itself, or in front of it with a reverse proxy/sidecar, so traffic is encrypted regardless of the underlying network.
- Service mesh mTLS — in Kubernetes, this is normally handled by a service mesh like Istio (see below), which automatically encrypts and authenticates every service-to-service call with mutual TLS, without the application code having to manage certificates itself.
- Network policies — restrict which containers/pods can even talk to each other in the first place (Kubernetes
NetworkPolicy, or Docker user-defined bridge networks), reducing the blast radius even before encryption is considered.
MESH
Service mesh — Istio
opsWhat is a service mesh, and what is Istio specifically?
A service mesh is a dedicated infrastructure layer that manages service-to-service communication in a microservices/Kubernetes environment — without the application code needing to handle networking concerns itself. It typically works by injecting a lightweight sidecar proxy (Envoy, in Istio's case) next to every service pod; all traffic in and out of the pod flows through that proxy.
Istio is the most widely used service mesh implementation. What it provides:
Istio is the most widely used service mesh implementation. What it provides:
- Security — automatic mutual TLS (mTLS) between services, so every call is encrypted and both sides are authenticated, with zero changes to application code.
- Traffic management — fine-grained routing, retries, timeouts, canary/blue-green rollouts, circuit breaking.
- Observability — automatic metrics, distributed tracing, and service-to-service traffic graphs, since every request already passes through the proxy.
SECRET
Secret management — HashiCorp Vault
opsWhat is HashiCorp Vault, what's the use case, and how do you integrate it into a pipeline or cluster?
Vault is a centralized secret management system — instead of credentials, API keys, and certificates sitting in config files, environment variables, or (worse) hardcoded in Git, everything is stored, tightly access-controlled, and audited in one place.
Use case: a database password that never has to be known or copy-pasted by a human; short-lived, automatically-expiring credentials generated on demand instead of a static password that lives forever; a single audit trail of exactly which service or person accessed which secret and when.
How it works / key concepts:
Use case: a database password that never has to be known or copy-pasted by a human; short-lived, automatically-expiring credentials generated on demand instead of a static password that lives forever; a single audit trail of exactly which service or person accessed which secret and when.
How it works / key concepts:
- KV secrets engine — the simplest case, a secure key-value store for static secrets.
- Dynamic secrets — Vault generates a short-lived, unique credential (e.g. a database user) on request and automatically revokes it after a lease expires — nothing long-lived to leak.
- Auth methods — services/pipelines authenticate to Vault itself using AppRole (common for CI/CD runners), Kubernetes service account tokens, or cloud IAM identity — not a static Vault password.
AWS
Cloud (AWS) — IAM and security tooling
opsWhat is IAM and why is it central to cloud security?
Identity and Access Management controls who (users, roles, services) can do what to which resources. Principle of least privilege, roles over long-lived keys, MFA on privileged accounts, regular audits of unused permissions — most cloud breaches trace back to IAM misconfiguration, not a zero-day.
How do Docker and Kubernetes map onto AWS specifically?
ECR stores images; ECS is AWS's own orchestrator; EKS is managed Kubernetes. GuardDuty is AWS's threat-detection service — it doesn't scan code, it continuously analyzes CloudTrail, VPC Flow Logs, and DNS logs for anomalous account/network activity, which is why it sits at the monitor/operate end of the pipeline rather than in build or test.
What's the difference between CloudWatch and CloudTrail?
The simplest framing: CloudWatch tells you how a workload is behaving; CloudTrail tells you who changed what. CloudWatch is operational monitoring — metrics, logs, and alarms for resource performance and health (CPU spiking, a Lambda timing out, an error rate crossing a threshold) — and it's alert-oriented, able to trigger a Lambda or notify a team automatically. CloudTrail is an audit trail — it records every API call made against the account (who did what, when, from where), through the console, CLI, or SDKs — and it's evidence-oriented, used for security investigations, compliance, and answering "who terminated that instance at 2am." In practice they're complementary, not competing: a common pattern is piping CloudTrail logs into CloudWatch so an unusual spike in failed API calls or console logins can trigger a real-time CloudWatch alarm instead of only being discoverable after the fact.
Reference: AWS CloudWatch and CloudTrail documentation.
CLOUD
Securing a multi-tenant environment
opsHow do you secure a tenant or multi-tenant cloud environment?
The core goal is tenant isolation: a security event, bug, or performance spike in one tenant must never expose data or degrade service for another. The main layers:
- Identity and tenant context — derive tenant identity from an authenticated, verified token (never a client-supplied value alone), and propagate that tenant context through every service call, cache key, and storage path.
- Data isolation model — a spectrum, not one setting: fully separate databases per tenant (strongest isolation, highest operational cost), a shared database with per-tenant schemas, or a shared database/table with Row-Level Security (RLS) enforced at the database layer plus application-level checks as defense in depth. Higher-value/regulated tenants often justify stronger (more expensive) isolation than low-tier ones.
- Encryption — at rest and in transit as a baseline; for the highest-sensitivity tenants, a separate encryption key per tenant (so a key compromise or legal data-deletion request is scoped to one tenant only).
- Network segmentation — restrict lateral movement between tenant workloads (network policies, separate VPCs/subnets, or separate accounts entirely for the strongest boundary).
- Per-tenant rate limiting and quotas — so one noisy or compromised tenant can't exhaust shared resources and degrade service for everyone else (a tenant-scoped denial-of-service).
- Continuous verification, not just initial design — isolation boundaries erode over time through undocumented changes and ungoverned provisioning; continuous compliance scanning that confirms isolation configuration still matches its intended state, and an architecture review gate at every new tenant's onboarding, are what keep the boundary holding as the tenant population grows.
Reference: OWASP Multi-Tenant Security Cheat Sheet.
AZURE
Azure — SIEM & log aggregation tooling
opsWhat's Azure's SIEM tool and what does it do?
Microsoft Sentinel — cloud-native SIEM + SOAR. Aggregates logs across the environment, applies analytics rules/ML to detect threats, and can trigger automated playbooks for response. Relevant since many DevSecOps job postings mention "monitoring correlation" tools as a core skill.
You mentioned Splunk, Prometheus, and Grafana in the same breath — what does each one actually do, and how do they fit together?
They sit at different layers and aren't really interchangeable:
- Splunk — a full commercial log aggregation and SIEM platform: it collects, indexes, searches, correlates, and alerts on log data end to end, all in one product. The open source equivalent stack for the same job is ELK (Elasticsearch for storage/search, Logstash for ingestion, Kibana for visualization).
- Prometheus — collects metrics, not logs: numeric time-series data like CPU usage, request latency, or error rate, scraped on a pull-based model. It's not a log store at all — a common source of confusion.
- Grafana — purely a visualization/dashboard layer; it doesn't collect or store anything itself. It queries data sources — Prometheus for metrics, Loki (Grafana's own log-aggregation system, deliberately designed to feel "like Prometheus but for logs") for logs, or even Elasticsearch/Splunk — and renders it all as dashboards.
IAC
Terraform, Ansible, and GitOps/ArgoCD
opsWhat's the difference between Terraform and Ansible, and where does ArgoCD fit?
Terraform = provisioning (declarative, creates infrastructure — VMs, networks, clusters). Ansible = configuration management (installs/configures software on infrastructure that already exists, agentless, push-based). ArgoCD = GitOps continuous delivery for Kubernetes — a controller continuously reconciles the cluster's actual state against the desired state declared in Git, so Git becomes the single source of truth and drift is automatically detected/corrected.
// advanced topics — 2026 roadmap
Everything below goes past a generic foundational interview and into where DevSecOps is actually heading in 2026: Kubernetes-native hardening, Zero Trust, the real mechanics behind artifact signing, and AI/ML as both a new attack surface and a new triage tool. Good to have in your back pocket for a senior or forward-looking conversation — not usually asked of someone in their first DevSecOps role, but strong signal if you bring it up yourself.
ADV
Kubernetes security & cluster hardening
secBeyond running kube-bench, what does actually hardening a Kubernetes cluster look like?
It spans the whole cluster surface, not one setting:
- Benchmark compliance — Kube-bench checks the cluster's configuration (API server flags, kubelet config, etcd permissions, scheduler settings) against the CIS Kubernetes Benchmark; it's a point-in-time compliance check, not a live threat detector.
- RBAC least privilege — audit actual permissions (tools like
rakkessshow an access matrix per role/service account), remove any lingeringcluster-adminbindings, and give every workload its own scoped ServiceAccount instead of reusingdefault. - Pod-level hardening — enforce Kubernetes Pod Security Standards (Baseline/Restricted): non-root containers, read-only root filesystem, dropped Linux capabilities, no
hostNetwork/hostPID/hostIPC. - Admission-time policy enforcement — OPA/Gatekeeper for complex cross-resource Rego policies (registry allowlists, mandatory labels, resource quotas); many teams pair this with a signature-verification policy so an unsigned image is rejected before it ever schedules.
- Network segmentation — default-deny
NetworkPolicyplus a CNI that can actually enforce it (Cilium or Calico), so a compromised pod can't freely reach every other pod in the cluster. - etcd and node-level hardening — encrypt etcd at rest via a KMS provider, and harden the underlying node OS itself against the CIS RHEL/Ubuntu benchmark, not just the K8s objects running on it.
- Audit logging — ship the K8s API server's audit log to your SIEM and alert on sensitive operations (create/delete/exec) in production namespaces.
Reference: CIS Kubernetes Benchmark, NSA/CISA Kubernetes Hardening Guide, NIST SP 800-190.
What's the practical difference between OPA/Gatekeeper and Kubernetes' own Pod Security Standards?
Pod Security Standards are Kubernetes-native, built-in, and cover a fixed, predefined set of pod-level checks (privilege escalation, host namespaces, capabilities) — simple to turn on, but not extensible. OPA/Gatekeeper is a general-purpose policy engine — you write arbitrary Rego rules against any resource type, so it covers things PSS can't touch at all: "every image must come from our internal registry," "every Deployment must have a
cost-center label," "every image must carry a valid Cosign signature." Many mature clusters run both: PSS as the baseline floor, OPA/Gatekeeper for the organization-specific rules on top.We already have a section on cloud IAM — is Kubernetes RBAC the same thing, or something different?
Same underlying idea, different layer entirely, and both need to be secured independently: AWS IAM controls access to cloud provider resources — who can call the EC2/S3/EKS API, spin up infrastructure, or assume a role. Kubernetes RBAC controls access inside the cluster itself — which user or ServiceAccount can list Secrets, exec into a pod, or create a Deployment in a given namespace, entirely separate from whatever cloud account the cluster happens to run on. A common real gap: a team locks down AWS IAM tightly but leaves the in-cluster RBAC permissive — e.g. every ServiceAccount implicitly able to read Secrets cluster-wide — so an attacker who compromises one pod can walk laterally through the whole cluster even though the cloud account itself is well-governed. Hardening one without the other leaves the other one wide open.
Practical RBAC least-privilege checklist: give every workload its own dedicated ServiceAccount (never share the
Practical RBAC least-privilege checklist: give every workload its own dedicated ServiceAccount (never share the
default one across unrelated workloads), scope Role/RoleBinding to a single namespace rather than reaching for ClusterRole/ClusterRoleBinding unless genuinely cluster-wide access is required, avoid wildcard verbs/resources ("*") in a Role definition, and periodically audit actual granted permissions against what's really used (this is exactly what a tool like rakkess or kubeaudit is for) since permissions tend to accumulate and rarely get revoked once a project matures.Reference: Kubernetes RBAC documentation, CIS Kubernetes Benchmark (RBAC controls), NSA/CISA Kubernetes Hardening Guide.
ADV
Zero Trust architecture & identity
secWhat does "Zero Trust" actually mean in practice, beyond the buzzword?
Formalized in NIST SP 800-207: never trust a request based on network location alone (being "inside the VPN" or "inside the cluster" proves nothing), explicitly verify every request's identity and authorization, and assume the network is already compromised (assume breach) so blast radius stays contained even if one component is. In a Kubernetes/microservices context this becomes concrete: mTLS for every service-to-service call (typically via a service mesh like Istio — already covered), least-privilege RBAC applied consistently across K8s, cloud IAM, and Vault policies, and micro-segmentation so a compromised pod can only reach the handful of services it actually needs.
What problem does SPIFFE/SPIRE actually solve that mTLS alone doesn't?
mTLS needs both sides to have a valid, trusted certificate — SPIFFE/SPIRE is what issues and rotates those certificates automatically, giving every workload a short-lived, cryptographically verifiable identity (a SPIFFE ID) instead of relying on long-lived static secrets or IP-based trust. It solves the "how does a workload prove who it is, cluster-to-cluster or cloud-to-cloud, without a shared static secret" problem — particularly relevant once you're running across multiple clusters or multiple clouds where a single service mesh's built-in identity doesn't naturally extend.
What's PAM, and where does it fit alongside Vault?
Privileged Access Management is specifically about controlling and auditing human access to highly sensitive systems and credentials — think a break-glass admin login, not a service's database password. Vault already handles dynamic, short-lived credentials well for workloads and pipelines; a dedicated enterprise PAM tool (CyberArk is the common name here) adds session recording, just-in-time privilege elevation, and approval workflows specifically for human privileged access — the two are complementary, not competing.
ADV
Image/artifact signing — Cosign, SLSA, Rekor
secWalk me through what actually happens, mechanically, when you sign and push a container image with Cosign.
- 1. Build and hash — the image is built, and a cryptographic digest (
sha256:...) is computed over its content. This digest — not the mutable tag — is what actually gets signed; a tag like:latestcan be repointed to different content later, a digest can't. - 2. Sign — Cosign (part of the Sigstore project) signs that digest. Modern practice uses keyless signing: instead of managing a long-lived private key yourself, Cosign requests a short-lived certificate from Sigstore's Fulcio CA using your CI system's own OIDC identity (e.g. "this is a GitHub Actions run from repo X, workflow Y") — so the signature is tied to a verifiable pipeline identity instead of a key someone has to protect forever.
- 3. Push and record — the signed image is pushed to the registry over TLS (registry pushes should always be over HTTPS/TLS — an unencrypted registry push is a real, avoidable supply-chain gap). The signature itself, plus a transparency record, is published to Rekor — Sigstore's public, append-only transparency log — so the signing event is independently, publicly auditable and can't be silently altered after the fact.
- 4. Verify before deploy — at Kubernetes admission time, a policy engine (Kyverno's
imageVerify, or OPA/Gatekeeper) checks the image's signature against the expected signer identity before allowing the pod to schedule at all — an unsigned or wrongly-signed image is rejected outright, not just flagged.
What is SLSA, and what do the levels actually mean?
SLSA (Supply-chain Levels for Software Artifacts) is a framework that grades how trustworthy a build's provenance is — can you actually prove what source and process produced this artifact? Roughly: L1 — the build process is documented and produces provenance metadata at all. L2 — the build runs on a hosted/managed build service and the provenance is signed. L3 — the build runs in an isolated, ephemeral, hardened environment where even the build service operator can't tamper with it undetected (a common real-world path here: Tekton Chains, which automatically signs provenance for every Tekton pipeline run). Higher levels are about making it progressively harder for an attacker — or even a compromised insider — to slip something into the build undetected.
Reference: slsa.dev, Sigstore/Cosign documentation, OpenSSF Scorecard.
ADV
Compliance as code
secWhat is "compliance as code," and how do you actually scan for it?
Instead of a compliance framework (PCI-DSS, ISO 27001, CIS Controls v8) living in a spreadsheet that gets manually re-checked once a year, its individual controls get encoded as machine-checkable policy — most commonly as OPA/Rego rules — and evaluated continuously in the same pipeline that already runs SAST/SCA. A control like "no S3 bucket may be publicly readable" or "all databases must have encryption at rest enabled" becomes a Rego rule that runs against every Terraform plan or live cloud config, the same way a security gate runs against SAST findings — pass/fail, automatically, on every change, with a timestamped record of every evaluation as your audit evidence instead of a point-in-time manual attestation. This is exactly what turns an annual audit scramble into an always-current, continuously provable state.
Reference: OPA/Rego documentation, CIS Controls v8, OWASP DSOMM (compliance-as-code is one of its measured practices).
ADV
Trivy — capabilities & limits
secWhat can Trivy actually scan? It's often described as "just an image scanner" — is that accurate?
No — Trivy is genuinely multi-purpose, which is exactly why it shows up so often as the free/OSS complement to a commercial stack:
- Container images — OS package and language-library CVEs inside a built image, the use case it's best known for.
- Filesystem / repository scans — scan a local checkout or filesystem directly, without needing a built image at all.
- SCA (dependency scanning) — Trivy can scan manifests/lockfiles for known-vulnerable dependencies, overlapping with what Black Duck/Sonatype Nexus IQ do at enterprise scale.
- IaC misconfiguration scanning — Terraform, Kubernetes manifests, Dockerfiles, and CloudFormation, overlapping with Checkov/tfsec.
- SBOM generation — can generate a CycloneDX or SPDX SBOM directly from an image or filesystem.
- Kubernetes cluster scanning — the Trivy Operator runs in-cluster for continuous rescanning of already-running workloads, catching a CVE disclosed after a workload was already deployed.
- Secret scanning — it can also catch hardcoded secrets inside a scanned image or filesystem as a secondary capability.
So what are Trivy's actual limits — where would you still reach for Black Duck, Sonatype, or Fortify instead?
Trivy is a vulnerability/misconfiguration matcher against known public data (NVD, vendor advisories) — it doesn't do the deeper analysis an enterprise platform adds on top: no reachability/call-graph analysis to tell you whether a vulnerable function is actually invoked (Black Duck SCA and Snyk both go further here), no license-compliance policy engine at the depth Black Duck offers for legal/OSS governance, no true SAST (no data-flow/taint analysis of your own proprietary code — that's Fortify/SonarQube/Semgrep territory entirely), and no centralized enterprise dashboard, SLA tracking, or compliance-report generation across a whole organization (that's what DefectDojo, Fortify SSC, or Black Duck SRM add on top of Trivy's raw findings). The honest framing: Trivy is an excellent, fast, free first-line scanner across many artifact types — it's a complement to your commercial stack's deeper analysis and governance layer, not a replacement for it.
ADV
Invicti, clarified
secIs Invicti a DAST tool, an ASPM tool, or something else — and how would you actually use it?
Both, and the "how" matters more than the label. At its core, Invicti is a DAST engine, distinguished by proof-based scanning — instead of just flagging a pattern that looks exploitable (the usual DAST false-positive problem), it safely attempts to actually confirm the vulnerability is exploitable before reporting it, which is what drives its very low false-positive rate. Since merging with Kondukto, it also ships an ASPM layer — connecting to 100+ other scanners (not just its own DAST) to correlate, deduplicate, and prioritize findings org-wide, the same category of tool as DefectDojo, Black Duck SRM, or Fortify SSC. Practically: you'd point Invicti's DAST at a running staging/QA environment as part of the pipeline's test stage, and separately use its ASPM side as a candidate central dashboard if you wanted one platform correlating DAST + SAST + SCA findings together rather than running DefectDojo alongside it.
ADV
AI/ML security & LLM threats
secWhat's the OWASP LLM Top 10, and what are the headline risks?
The AI/ML equivalent of the web OWASP Top 10 — the most critical risks specific to LLM-powered applications:
- Prompt injection — the headline risk: malicious instructions hidden in user input or in content the LLM reads (a webpage, a document, a tool's output) override the application's intended behavior.
- Insecure output handling — treating an LLM's output as safe/trusted and passing it directly into a shell command, a database query, or rendered HTML without the same validation any other untrusted input would get.
- Training data poisoning — corrupting the data a model is trained or fine-tuned on to implant a backdoor or bias.
- Model theft / model supply chain — a model file itself (frequently a Python
picklefile) can contain malicious deserialization payloads, and models pulled from public hubs (Hugging Face) carry the same "malicious dependency" risk a poisoned npm package does. - Excessive agency — giving an LLM-based agent more tool access or autonomy than the task actually requires, so a successful prompt injection can cascade into real-world actions (sending emails, making API calls, modifying data).
Reference: OWASP LLM Top 10 (Top 10 for LLM Applications).
What is MITRE ATLAS, and how is it different from MITRE ATT&CK?
ATT&CK catalogs adversary tactics/techniques against traditional IT systems (initial access, lateral movement, exfiltration). ATLAS is MITRE's parallel framework specifically for adversarial attacks against AI/ML systems — model evasion (crafting input to fool a classifier), model inversion (reconstructing training data from a model's outputs), and data poisoning — the ML-specific attack techniques ATT&CK was never designed to cover.
What's specifically risky about MCP (Model Context Protocol) servers and agentic AI tool use?
Once an LLM can call tools autonomously — through MCP servers or any agent framework — new, very concrete risks appear: tool poisoning (a malicious or compromised MCP server returns instructions disguised as data, hijacking the agent's next action), cross-agent/cross-tool supply chain risk (one compromised tool in a multi-tool chain can manipulate everything downstream of it), and the need for human-in-the-loop enforcement on any consequential action (sending data externally, modifying production systems) rather than letting an agent act fully autonomously on unverified input.
ADV
AI/LLM in the DevSecOps pipeline
secBeyond the AI-assisted triage already covered, where else can AI/LLMs actually help inside a DevSecOps pipeline today?
A few concrete, already-real use cases (matching the "AI proposes, human approves" pattern from the triage discussion earlier):
- Auto-generating and refining SAST custom rules — describing a pattern in plain language and having the assistant draft the Semgrep/CodeQL rule syntax, which a human then reviews and tunes (this is what Semgrep's own AI Assistant does).
- Auto-remediation PRs — given a confirmed SAST/SCA finding, generating the actual code fix as a reviewable pull request rather than just a text description of the problem (Corgea is a named example built specifically around this).
- Summarizing and explaining findings — turning a dense scanner report into a plain-language explanation a developer can act on quickly, cutting the time spent just understanding what a finding means.
- Drafting IaC, policies, or documentation securely — writing a first-pass Terraform module, OPA/Rego policy, or threat-model writeup, still reviewed by a human before it's trusted.
What could an LLM like Claude specifically do here, and what are the honest limits?
Realistically: reading a diff or scan output and flagging likely-risky patterns in plain language, drafting a custom SAST rule or a remediation patch for a human to review, summarizing a pile of findings into a prioritized narrative, or helping write a threat-model document or an IaC policy. The honest limit — worth saying explicitly in an interview rather than overselling it — is that an LLM is not a substitute for a deterministic scanner: it doesn't have guaranteed, repeatable coverage the way taint analysis does, it can miss things or be wrong confidently, and anything it proposes (a rule, a fix, a "this is safe to ignore" triage call) needs a human or an already-agreed policy to actually sign off before it's acted on — exactly the same governance principle from the AI-triage discussion earlier, just applied one level more broadly.
ADV
Scanning LLM models & AI-powered apps
secHow do you actually scan or test an LLM-powered application — is it a DAST scan, an API scan, something else entirely?
It's genuinely a combination, since "the app" now has two different attack surfaces:
- The model artifact itself — before ever loading a downloaded model file, scan it for malicious embedded code: many model formats (especially Python's
pickle-based ones) can execute arbitrary code on load, so a poisoned model from a public hub is functionally similar to a malicious PyPI package. Tools like ModelScan (Protect AI) exist specifically for this — treat it as SCA for models. - The application/API layer — this genuinely is a DAST/API-scan-style exercise: the LLM endpoint is tested like any other API, sending crafted inputs (prompt injection payloads, jailbreak attempts, boundary-testing content) and checking whether the guardrails hold — the same black-box "attack the running thing from outside" model DAST already uses, just with AI-specific payloads instead of SQLi/XSS ones.
- Adversarial/red-team frameworks purpose-built for this — Garak, PyRIT (Microsoft), and Counterfit automate exactly this kind of LLM-specific attack simulation, the rough equivalent of what Burp Suite/ZAP are for a traditional web app.
- Guardrail/output validation testing — separately verifying that runtime guardrails (LLM Guard, NeMo Guardrails, Lakera Guard) actually catch what they claim to — prompt injection attempts, jailbreaks, unsafe content — under adversarial conditions, not just happy-path prompts.
Reference: OWASP LLM Top 10, MITRE ATLAS, Protect AI ModelScan, Garak/PyRIT documentation.
GAP
What's missing? Gap assessment & maturity models
secWe've covered risk assessment, threat modeling, and the pipeline's security stages — is anything missing from a complete DevSecOps program?
Yes — everything covered so far is mostly the automated tooling layer
Shift right, not just shift left — runtime protection after deployment: a WAF (blocks known attack patterns at the network edge) and RASP (Runtime Application Self-Protection — an in-app agent that can detect and block an exploit attempt live, in production). Everything discussed earlier stops at "before release"; shift right covers "after release."
Human-driven penetration testing / red teaming — automated scanners (SAST/DAST/IAST) don't reliably catch business logic flaws: can a user reach data they shouldn't through a legitimate-looking multi-step workflow? That still needs a skilled human tester. Purple teaming — red team (attackers) and blue team (defenders) working together rather than adversarially — is increasingly how this gets run to maximize learning.
Security champions program — a nominated, security-minded developer embedded in each team, acting as the first line of triage and a bridge to the central AppSec team, rather than security being one small central team trying to cover every squad.
Security awareness training for developers — secure coding practices, phishing awareness, social engineering — the human layer, since tooling alone doesn't fix a developer who doesn't know what an injection vulnerability looks like in the first place.
Incident response (IR) / DFIR planning — a documented runbook for when something does get through: who's paged, how the incident is contained, evidence preservation, post-incident review. Tabletop exercises test this before a real incident forces it.
Cryptography and key/secrets lifecycle management — beyond just storing secrets in Vault: key rotation policy, HSM/KMS usage for the most sensitive keys, certificate expiry management.
Data classification and data security — not every field in a database is equally sensitive; classifying data (public/internal/confidential/restricted) drives where encryption, masking, and DLP (Data Loss Prevention) controls actually need to apply.
Continuous compliance mapping — mapping controls to frameworks like PCI DSS, ISO 27001, or local regulatory requirements (especially relevant in banking/government client environments) as an ongoing, automated practice rather than a once-a-year audit scramble.
Bug bounty / crowdsourced testing — an ongoing, continuously-running complement to scheduled internal pentests, particularly valuable for public-facing applications.
How would you formally identify these gaps rather than just guessing what's missing?
That's exactly what a DevSecOps maturity model is for — a structured framework to assess where the organization actually stands today across every pillar (culture, automation, threat modeling coverage, tool integration, incident response) and build a prioritized roadmap from there, instead of guessing.
- OWASP DSOMM (DevSecOps Maturity Model) — the most widely adopted open framework for this; breaks the practice into measurable, executable levels rather than vague statements like "we do security."
- BSIMM (Building Security In Maturity Model) — benchmarks an organization's practices against data gathered from real firms.
- OWASP SAMM — similar idea, oriented around software assurance maturity specifically (already referenced under SSDLC).
Reference: OWASP DSOMM (dsomm.owasp.org), BSIMM (bsimm.com), OWASP SAMM.
NOTE
Closing / behavioral angle
noteYou come from a DevOps background — why DevSecOps, and why this company specifically?
Coaching note: this is the chance to be authentic rather than recite definitions. Draw a direct line from your own hands-on DevOps experience — container/Kubernetes work, Terraform/Ansible automation, any exposure to security tooling like a scanner, Vault, or a SIEM — to why that already sits right next to security, and why formalizing that shift toward a security-focused role is a natural next step. Then connect it to whatever this specific company's tool stack and specialization actually is (research it beforehand). Be honest about deliberately building depth (courses/certs) rather than claiming years of AppSec-specific experience not yet had.
SAST = static, before running the app. DAST = dynamic, against a running app.
SCA = scans dependencies. SBOM = the inventory those scans produce.
IAST = SAST + DAST combined. Runs during functional testing.
STRIDE = threat modeling categories. PASTA = risk-centric threat modeling process.
Terraform = provision. Ansible = configure. ArgoCD = GitOps deploy.
Fortify → SAST + WebInspect (DAST). Black Duck → SCA, Coverity (SAST), Seeker (IAST).
Polaris = the AST engines. SRM / Fortify SSC / Invicti ASPM = the correlation dashboards.
Initial risk assessment = scoping. Application risk assessment = ongoing, app-specific treatment.
Risk assessment = "should we worry?" Threat modeling = "about what, exactly?"
Tekton = K8s-native CI/CD engine. OpenShift Pipelines = Red Hat's managed Tekton.
Quality gate = code metrics threshold. Security gate = vulnerability severity threshold.
GuardDuty = AWS threat detection. Sentinel = Azure SIEM. Both sit at monitor/operate.