Offensive Security for DevSecOps

A pipeline can run SAST, DAST, and SCA on every single commit, block the merge on any finding above a severity threshold, and still ship an application a human attacker walks straight through — not by exploiting a bug the scanners missed, but by using the application exactly as it was built to be used, in an order nobody anticipated. This page is about the layer of security testing that starts where automated scanning structurally ends: penetration testing, red teaming, and purple teaming. By the end you should be able to state precisely what a human tester finds that a scanner cannot and why, choose the right engagement type for a given goal, and explain how a well-run purple-team exercise changes a detection stack on the same day it runs — instead of producing a PDF that gets filed and re-read three months later during the next audit.

Where automated scanning stops: the structural blind spot

☺ Like you're 10: A spell-checker can tell you "recieve" is spelled wrong. It cannot tell you that the sentence it's sitting in is a lie. Scanners check spelling; they don't check whether the story makes sense.

It's worth being precise about the word "structural" here, because it's doing real work. SAST, DAST, and SCA aren't bad at finding bugs — they're extraordinarily good at finding a specific, well-defined category of bug, fast, on every commit, without getting tired or skipping the boring parts a human tester might rush through at 5pm on a Friday. What they cannot do isn't a maturity gap that a better rule set eventually closes. It's a category mismatch between what each tool is built to reason about and what a business-logic flaw actually is:

• SAST reads source code without executing it, so it reasons about a function's internals — an unsanitized string reaching a query, a hardcoded secret, a missing bounds check. It has no model of what the application's workflow is supposed to be, because that's not information the code's syntax tree contains. It can't tell you that step 3 of a checkout flow shouldn't be reachable before step 2 completes — both steps are individually well-formed code.
• DAST exercises a running application from the outside, fuzzing inputs and following links, but it has no concept of what a correct multi-step business transaction looks like versus an incorrect one that still returns 200 OK. A DAST scanner sees a coupon-code endpoint accept a request and respond successfully; it has no way to know the coupon should only be redeemable once, because "once" is a fact about the business, not about the HTTP response.
• SCA matches installed dependency versions against a database of known CVEs. It's blind by design to anything that isn't a previously disclosed vulnerability in someone else's code — which is exactly the category a custom-written authorization check falls into. Your own code has never been assigned a CVE.

A human tester brings something none of the three can structurally have: a mental model of what the application is for, held simultaneously with the skill to try using it in a way its designers never intended. That combination is what finds a business-logic flaw in an API that returns a perfectly valid, perfectly well-formed 200 OK response to a request that should never have been allowed at all.

Business logic flaws and chained findings, made concrete

☺ Like you're 10: One unlocked window isn't a break-in. Three separate unlocked things — a window, a side gate, and a spare key under the mat that nobody thought was a big deal alone — add up to someone walking straight to your jewelry box. A scanner checks each lock by itself and says "fine, fine, fine." A person walks the whole house.

Take a concrete, realistic example — the kind that shows up in real penetration-test reports constantly, assembled from three findings any competent scanner would each rate individually low or medium, none of which alone would block a release:

1. Finding 1 — verbose error message (Low). A malformed request to /api/profile returns a stack trace that reveals internal user IDs are sequential integers, not UUIDs. Informational on its own; a scanner correctly flags it as low severity because nothing was disclosed except an implementation detail.
2. Finding 2 — IDOR on profile read (Medium). GET /api/profile?id=1044 returns another user's profile — name, email, account-recovery phone number — with no check that the requester actually owns ID 1044. A DAST scan or a SAST rule can catch the missing check if it happens to test that specific parameter with a foreign ID; many miss it because the endpoint "works correctly" for the tester's own account, which is all an authenticated crawl typically exercises.
3. Finding 3 — no rate limiting on OTP verification (Low). /api/reset/verify accepts a 6-digit one-time code with no lockout after repeated failures. Low severity by itself — 6 digits is a million combinations, and nobody's going to sit there guessing.

A scanner reports three findings, none release-blocking. A human tester reads all three in the same afternoon and does the thing none of the scanners were built to do: combine them. Finding 1 confirms user IDs are enumerable integers. Finding 2 lets the tester walk that integer range and harvest real email addresses and phone numbers behind them. Finding 3 means that once a target email is chosen from that harvested list, the six-digit reset code guarding it can be brute-forced with no lockout, no CAPTCHA, and no alert — because nothing about a fast sequence of reset attempts trips a rule that was never written. The chain ends in a full account takeover on an arbitrary user, a finding that individually didn't exist anywhere in the pipeline's output. This is not a hypothetical pattern: it's structurally the same shape as the chain behind the Capital One breach — an SSRF finding and an over-permissioned IAM role, neither catastrophic alone, chained into exfiltration of over 100 million records.

Other common shapes of the same problem, worth recognizing on sight because a scanner will not flag any of them: a checkout that lets the client submit a negative quantity, which the server multiplies by unit price without a floor check, crediting the attacker's account instead of charging it; a multi-step wizard where posting directly to the final "complete order" endpoint skips the payment-verification step, because the server trusted the client to arrive there in order; a coupon-redemption race condition where two near-simultaneous requests both read "not yet redeemed" before either write lands, applying the discount twice. None of these are memory-safety bugs, injection flaws, or known-CVE dependencies — they're all the application doing precisely what its code says to do, which is exactly why static and dynamic analysis, built to find deviations from correct code behavior, have nothing to flag.

Penetration testing: scope, methodology, and rules of engagement

☺ Like you're 10: A penetration test is asking someone to try every doorknob in the whole building on purpose, on a day you agreed to, and write down every one that turned.

A penetration test ("pentest") is a time-boxed, authorized attempt to find and demonstrate as many exploitable weaknesses as possible within an agreed scope — breadth-first, not stealth-first. Two structured methodologies dominate real engagements and are worth knowing by name because clients and testers use them as a shared vocabulary: the Penetration Testing Execution Standard (PTES), which defines seven phases — pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting — and the OWASP Web Security Testing Guide (WSTG), a detailed checklist of specific test cases organized by category (authentication, session management, business logic, and so on) for web applications specifically. NIST SP 800-115 covers the same ground from a federal-guidance angle and is the one auditors most often expect a citation to. None of these are exam trivia — they're what a good pentest report cites in its methodology section so a reader can verify coverage, not just trust the tester's word.

Gray-box is the default for a reason worth internalizing: a black-box test mostly measures how good the tester is at reconnaissance, which is real but not usually the scarcest skill; a white-box test can spend so much time reading code that it starts to duplicate what SAST already covered. Gray-box — a normal user account, the same access a real customer or a normal insider would have — spends the engagement's hours on the question that actually matters for a chained-findings and business-logic hunt: what can this ordinary identity be pushed into doing that it shouldn't be able to?

The deliverable that actually matters is not the raw finding list — it's each finding walked through to business impact, prioritized alongside a CVSS score rather than by it alone, because a 9.8 on a system with no real data behind it can matter less than a 6.5 that reaches customer PII. See vulnerability management & triage for how those findings get scored, deduplicated against what the pipeline's own scanners already reported, and tracked to remediation in a tool like DefectDojo rather than living forever in a PDF nobody revisits.

Red teaming: an adversary emulation, not a vulnerability hunt

☺ Like you're 10: A pentest tries every door to see which ones are unlocked. A red team picks one specific prize inside the building, tries to reach it quietly, and the real question isn't "did you get in" — it's "did anyone notice."

Where a pentest asks "how many things are wrong," a red team exercise asks a narrower and harder question: "can a realistic, motivated adversary reach this one specific objective — the customer database, the code-signing key, domain admin — and if they can, does our detection and response organization notice and stop them before they do?" Scope is usually a single crown-jewel objective, not an exhaustive sweep; success is measured by whether the objective was reached and by how the defenders performed, not by a count of vulnerabilities. Stealth is part of the test — a red team that gets caught on day one and stops has still delivered a valid result, just not the one about deep access; a red team that's never detected at all has delivered a much more uncomfortable one about the detection program itself.

Real red teams don't improvise technique names — they plan and report against the MITRE ATT&CK framework, a public, continuously maintained matrix of adversary tactics (the "why" — Initial Access, Privilege Escalation, Lateral Movement, Exfiltration, and so on) and the specific techniques and sub-techniques underneath each one (the "how" — T1566 Phishing, T1055 Process Injection, T1021 Remote Services). Planning a red team engagement means selecting a realistic subset of ATT&CK techniques matching a specific adversary profile the client cares about — a ransomware crew, a nation-state actor known to target the client's sector — rather than every technique in the matrix. Execution tooling ranges from commercial command-and-control frameworks like Cobalt Strike to open-source alternatives such as Sliver, and — critically for the purple-team section below — from automated adversary-emulation platforms like MITRE Caldera and technique libraries like Atomic Red Team, which package individual ATT&CK techniques as small, safely repeatable tests rather than a full campaign.

Because defenders are deliberately kept in the dark, a red team measures the whole chain of incident response & forensics under real conditions — not "would this alert have fired in theory," but "did it fire, did anyone see it, and how long did triage take" — which is a fundamentally different and more expensive signal than a pentest report can produce, and exactly why it's run far less often.

Purple teaming: the exercise that doesn't end with a PDF

☺ Like you're 10: Instead of the burglar sneaking around for a month and then mailing you a report, imagine the burglar and the security guard doing it together, in the same room, and the second the burglar gets past a camera, they both stop and go fix that camera right then — not next quarter.

A red team's stealth is also its biggest limitation as a learning exercise: because defenders don't know it's happening, a technique that sails past every detection tool undetected produces exactly one artifact — a line in a report, delivered weeks later, describing an attack path that's already gone cold by the time anyone reads it. Purple teaming fixes this by removing the secrecy on purpose. Red and blue work together, in the same session, in real time: the red side announces and executes one specific ATT&CK technique, the blue side checks — immediately, not weeks later — whether their detection stack caught it, and if it didn't, the two sides work out why together, on the same call, often against the same test environment. The "purple" name isn't a personality label for a friendlier kind of hacking; it describes literally combining red and blue into one collaborative exercise instead of two teams that only ever meet through a document.

This is exactly why purple teaming pairs so naturally with lightweight, atomic technique libraries rather than full red-team campaigns: running one Atomic Red Team test for T1003 (credential dumping) takes minutes, the blue side can check their SIEM in real time, and if nothing fired, that's this session's actionable gap — not a line item competing for attention against forty others in a report from last month.

Teams track progress across a full engagement with the public MITRE ATT&CK Navigator, a heatmap of the whole technique matrix that gets colored in as each one is tested: green for "tested and detected," red for "tested and missed," gray for "not yet exercised." Handed to leadership at the end of a quarter, that heatmap is a far more honest measure of detection coverage than "we passed our last pentest," because it names the specific techniques nobody has actually verified detection for yet — rather than implying, by omission, that everything not mentioned is fine.

From technique to detection: writing the rule the exercise proved you needed

☺ Like you're 10: Finding out the smoke alarm didn't go off is only useful if you actually fix the smoke alarm before the next fire, not just write "smoke alarm broken" in a notebook.

The artifact a good purple-team session actually produces isn't the finding — it's the rule. Detection logic that closes a gap lives in one of a few concrete formats, and knowing which one applies where is a real skill in its own right, distinct from the offensive side entirely:

• Sigma rules — a generic, YAML-based, platform-agnostic detection format that converts into the query language of whatever SIEM actually runs it (Splunk, Elastic, Microsoft Sentinel). Writing detections in Sigma instead of a vendor's native query language means the rule survives a SIEM migration; the community rule set at SigmaHQ is the closest thing detection engineering has to a shared, versioned standard library.
• Falco rules — for anything the technique touches at the container or Kubernetes runtime layer, watching syscalls via eBPF for behavior no static policy could have predicted, covered in full in container runtime security.
• EDR / SIEM correlation rules — vendor-native detections (a CrowdStrike or Microsoft Defender custom rule, a correlation search spanning multiple log sources) for anything that needs signal fusion a single log source can't provide alone.

Take the OTP-brute-force chain from earlier as a worked example. The gap the purple-team session exposes isn't "the endpoint has no rate limit" — the team already knew that from the pentest finding. The gap is "we have no detection for what exploiting that gap actually looks like on the wire," which is a different and more durable fix than patching the one endpoint, because it also catches the next endpoint someone forgets to rate-limit:

title: High-Volume Sequential OTP Verification Attempts
id: 3f2c9e40-88b1-4b1a-9a7e-example-only
status: experimental
description: >
  Detects a high rate of failed one-time-code verification attempts against
  a single account within a short window — the network-level signature of
  the OTP brute-force chain identified in the purple-team session against
  the password-reset flow (chained with the IDOR-driven account enumeration).
logsource:
  category: application
  product: web
detection:
  selection:
    http.url|contains: '/api/reset/verify'
    http.response.status: 401
  timeframe: 5m
  condition: selection | count(client_ip, target_account) by target_account > 15
level: high
tags:
  - attack.credential_access
  - attack.t1110.003   # password spraying / guessing sub-technique

Notice what changed: before the purple-team session, "no rate limit on the OTP endpoint" was a finding sitting in a triage backlog, competing for engineering time against every other medium-priority item. After it, there's a deployed rule that fires the moment anyone — an automated attacker, a red team next quarter, a real incident — attempts the exact technique that was proven to work, regardless of whether the underlying rate-limit bug has been fixed yet. That's the actual value purple teaming adds on top of a pentest report: a pentest tells you a door is unlocked; a purple-team session gets you an alarm on that door today, whether or not the lock gets replaced this sprint.

Where offensive security sits in the DevSecOps cadence

☺ Like you're 10: You brush your teeth every day, but you only go to the dentist twice a year — both matter, and neither one is a substitute for the other.

A common and costly misunderstanding is treating offensive security as one more gate that should be squeezed into the CI/CD pipeline the same way SAST, DAST, and SCA are. It structurally can't work that way: a competent pentest takes days to weeks of skilled human time, and a red team engagement can run for months by design — neither fits inside a merge-blocking check that has to return a result before a developer's coffee gets cold. What actually replaces "run it on every commit" is a deliberate cadence, layered by cost and depth, matched to how often each layer's signal actually changes:

The layers aren't independent, either — each one should feed the next. Findings a pentest turns up feed straight into vulnerability management and triage for remediation tracking. The techniques a red team used to reach its objective, whether or not it was caught, become the exact technique list a purple team schedules next quarter to verify detection coverage before the next real red team run. And secure by design and threat intelligence is what should be steering which ATT&CK techniques and which crown-jewel objectives get chosen in the first place — a red team scoped against threats nobody targeting your sector actually uses is an expensive exercise that teaches you very little.