Testing
Prove the controls work: security regression tests, static and dynamic testing, fuzzing, ASVS verification and outside testing.
Does the running software resist what the threat model predicted?
Start here: Test an application
Security practices in this phase
Automated security tests
Test authorization for each role and tenant, rejected inputs, limits and error handling, and add a regression test for every vulnerability you fix.
Done when: Security tests run in CI with the other tests and fail the build when a control regresses.
SAST and DAST
Tune static analysis to your own code, scan a deployed test build as a logged-in user, and confirm each finding with a request that reproduces it before fixing it.
Done when: Confirmed findings have a reproducing test, and suppressed false positives have a recorded reason.
Fuzzing
Fuzz code that parses untrusted files, archives and protocols, and keep every crashing input as a regression test.
Done when: Fuzzing runs on a schedule, and each crash it finds becomes a test.
ASVS verification
Choose the ASVS level that fits the application and record, for each requirement in scope, the test or review that shows it is met.
Done when: Every requirement in scope has evidence another engineer can repeat.
Penetration testing
Scope penetration tests with the threat model for major releases and new attack surface, and track their findings like any other bug.
Done when: Each test has a written scope, and its findings are fixed or accepted with an owner.
Guides
28 guides- Combine static and dynamic tests around a verified finding
Use analysis tools to find evidence, then retain an application regression that demonstrates the failure and the fix.
- Fuzz a parser and turn crashes into lasting regressions
Build a narrow harness, observe memory and resource failures, minimize the input, and test the repaired parser.
- Build evaluations around prohibited outcomes
Test the application’s actual security boundaries, preserve legitimate tasks and distinguish deterministic enforcement from variable model behavior.
- Red-team LLM applications and agents by their effects
A red-teaming method for LLM features and agents: scope the whole system, map attacks to OWASP and MITRE ATLAS identifiers, score trials from observed effects, report rates with confidence intervals and retest on every model or provider change.
- Turn NIST AI RMF, ISO/IEC 42001 and EU AI Act duties into engineering evidence
What the NIST AI RMF and its Generative AI Profile, ISO/IEC 42001 and the EU AI Act, as amended in 2026, ask of teams that build AI features, turned into engineering practices and one set of evidence. Not legal advice.
- Place each security control in the pipeline and decide what it blocks
Put secrets scanning, SAST, SCA, IaC and image scanning, DAST, fuzzing, attestation and admission control where each sees the right input, block only on findings a developer can act on, and deploy only images the pipeline has attested.
- Choose and evaluate application security testing tools
What SAST, DAST, IAST, SCA, secrets, IaC, container and API scanners and ASPM each find and miss, where each runs, how to evaluate them on a seeded repository with per-CWE scoring and triage cost, and which to adopt first.
Also part of this phase
- Enforce authorization for every object action
Authorize the authenticated subject, requested operation, and specific resource together; a valid login or unpredictable identifier is insufficient.
- Authorize functions and fields as well as objects
Prevent mass assignment, sensitive-field exposure and administrative actions that a valid object lookup alone cannot protect.
- Preserve business invariants under concurrent requests
Make a balance, reservation or approval rule hold when requests overlap, retry and fail halfway through.
- Review a code change through its trust boundaries
Turn a pull request into a small set of security claims that can be checked against the surrounding system and tests.
- Bound background jobs and make retries safe
Keep queues, workers and paid dependencies within a defined budget when clients retry, cancel or disappear.
- ASVS 5.0 verification records: requirement, test and evidence another engineer can repeat
Scope edition-qualified requirements, connect them to implementation and tests, and separate a passing check from an unsupported assurance claim.
- Protect training and retrieval data from targeted poisoning
Track who can influence datasets, keep evaluation independent and investigate targeted behavior changes without relying on aggregate accuracy.
- Test smart contracts through state invariants
Define the properties funds and privileges must preserve, then exercise callbacks, transaction sequences and exceptional conditions locally.
- Prevent business-logic flaws with server-side invariants
Recompute prices on the server, run workflows as state machines, build reset links from configuration, limit valuable flows, and turn each business rule into an invariant that the database and the tests both check.
- Find, fix and contain memory-safety bugs in C and C++
Recognize out-of-bounds access, use after free, NULL dereference and integer overflow in C and C++, fix them with checked lengths and single ownership, harden release builds, catch the rest with sanitizers and fuzzing, and plan new code in a memory-safe language.
- Start with a VDP, then add bug bounties and penetration tests
Publish a vulnerability disclosure policy and security.txt first, add a bug bounty only when you can triage and fix at the pace rewards bring, and buy penetration tests with a written scope, rules of engagement and a retest.
- Protect the source repository: rulesets, reviews and signed commits
Configure the controls every repository that ships software needs: protected branches and tags, required review with CODEOWNERS, signed commits, secret push protection and account security, mapped to the SLSA Source track, the OpenSSF OSPS Baseline and Scorecard.
- Choose cloud security posture tools and apply zero trust
What CSPM, CWPP, CIEM, CNAPP, DSPM and ASPM each find and miss, how they overlap, how to evaluate one on your own accounts, and how zero trust as defined in NIST SP 800-207 uses what they measure.
- Run a security champions program with protected time and outcome metrics
Put a trained engineer with protected hours in every in-scope team, write the role into a one-page charter, route sensitive changes and findings through champions and AppSec, and judge the program by coverage and outcomes instead of attendance.
- Write testable security requirements and a security Definition of Done
Derive security requirements from OWASP ASVS 5.0, abuse cases and the threat model, write them as acceptance criteria a test can fail, trace each one to a test or evidence, and close stories against a short security Definition of Done.
- Abuse case library: tests and controls by feature
Recurring abuse cases for sign-up and login, password reset, MFA enrolment, invites, file upload, payments and coupons, webhooks, search, export, admin and AI chat or agents: the attacker goal, preconditions, a concrete test and the control, each linked to CWE and CAPEC.
- Create temporary files safely: mkstemp, O_EXCL and private directories
Stop symlink, hardlink and pre-created-file attacks on the temporary files your code writes in shared directories such as /tmp: create each file atomically with O_EXCL and owner-only permissions through mkstemp or its equivalent in shell, Python, Java, Node.js, Go, .NET and Rust, keep related files in a private directory, and treat the Linux protected_* sysctls and systemd PrivateTmp as a backstop.
- Contain LLM misinformation (OWASP LLM07:2026)
Stop plausible but wrong model output from driving decisions and actions: ground answers in sources, verify every citation, separate generation from execution with a claim-check-act pattern, gate consequential actions on a human, and evaluate factuality on your own domain.
- DeFi attack patterns: oracles, flash loans, proxies and signatures
The four smart-contract attack classes beyond reentrancy: price-oracle manipulation, flash-loan amplification, upgradeable-proxy storage collisions and uninitialized implementations, and signature replay, each with vulnerable and fixed Solidity, Foundry tests and verified incidents.
- Case study: the Amazon Q Developer extension compromise (2025)
How an over-scoped GitHub token, extracted from an AWS CodeBuild pull request build, let a threat actor commit code to the Amazon Q Developer extension for VS Code that shipped in version 1.84.0 in July 2025, why the injected code aimed at the Q Developer CLI failed, and the CI and AI-agent controls the incident argues for.
- Case study: First American's EaglePro document exposure (2019)
How sequential IDs in unauthenticated links exposed First American's title documents in 2019, after its own penetration test found the flaw and a clerical error let it go unfixed.