For AppSec engineers
Security engineers who review designs and code, run security testing and triage findings.
Application security
52 guidesFix SQL injection in Python sqlite3
Bind query values separately from SQL syntax, then prove the fix preserves legitimate behavior and blocks an injection probe.
Development · Developers, AppSec engineers
Design a safer file-upload pipeline
Treat upload receipt, content processing, storage, and later delivery as separate security decisions.
Design, Development · Developers, AppSec engineers
Verify webhook deliveries before acting
Verify the provider’s signature over the correct bytes, then apply replay, authorization, and idempotency controls before a business action.
Design, Development · Developers, AppSec engineers
Review tenant boundaries before implementation
Trace tenant identity through requests, data stores, caches, jobs, and administration, then turn plausible isolation failures into tests.
Design · Developers, AppSec engineers
Respond to an exploited or malicious dependency
When a dependency vulnerability is being exploited, or a package version is malicious, triage gives way to incident response: find every running copy, contain it, patch and redeploy, hunt for exploitation, rotate secrets and close on deployed evidence.
Maintenance · AppSec engineers, Platform engineers and SREs
Review trust boundaries in mobile and native clients
Protect local data and platform interactions while keeping server-side authorization independent of the client’s behavior.
Design, Development · Developers, AppSec engineers
Constrain server-side fetches to their intended destinations
Prevent untrusted URLs from turning a preview, import, or webhook feature into access to internal services.
Design, Development · Developers, AppSec engineers
Handle failures without leaking internals or weakening controls
Give callers a useful, bounded response while preserving protected diagnostic evidence and safe application state.
Development · Developers, AppSec engineers
Run coordinated vulnerability disclosure from report to advisory
Make private reporting discoverable, verify reports, coordinate a tested remedy, and give affected users enough information to act.
Maintenance · Developers, AppSec engineers, Security leaders
Protect cookie-authenticated actions against CSRF
Make the server distinguish an intended action from a request another site caused the browser to send.
Development · Developers, AppSec engineers
Configure CORS and CSP around the browser capabilities you need
Control who can read API responses and which resources a page may execute without confusing either control with authorization.
Development · Developers, AppSec engineers
Render rich text without granting it application privileges
Choose text rendering or a restricted HTML policy, then test the final DOM after every transformation.
Development · Developers, AppSec engineers
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.
Development, Testing · Developers, AppSec engineers
Preserve business invariants under concurrent requests
Make a balance, reservation or approval rule hold when requests overlap, retry and fail halfway through.
Design, Testing · Developers, AppSec engineers
Extract archives without escaping the destination
Prevent traversal, link tricks, overwrites and decompression exhaustion while preserving legitimate file extraction.
Design, Development · Developers, AppSec engineers
Convert untrusted office documents and PDFs in an isolated parser
DOCX, XLSX and ODF files are ZIP archives of XML, and PDFs can carry scripts; the converters that read them are large C and C++ programs with a long CVE history. Check the package before any parser reads it, convert each document in a container with no network, no writable root and hard limits, kill it at a deadline, and re-render to pixels when people will open the result.
Design, Development · Developers, AppSec engineers, Platform engineers and SREs
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.
Development, Testing · Developers, AppSec engineers
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.
Testing, Maintenance · Developers, AppSec engineers
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.
Testing · Developers, AppSec engineers
Preserve framework security controls across the request lifecycle
Trace middleware, persistence and rendering so custom code does not bypass the protections supplied by the framework.
Development · Developers, AppSec engineers
Constrain desktop IPC and privileged helpers
Keep renderer content, local callers and plugins from turning a narrow feature into unrestricted operating-system access.
Development · Developers, AppSec engineers
Design firmware updates that can recover safely
Connect trusted boot, update authorization, rollback policy and end-of-life behavior to the device’s actual failure modes.
Development, Release · Developers, AppSec engineers
Parse bounded JSON and XML into an explicit application schema
Separate parser capabilities from schema rules, reject ambiguous and coercible inputs, and implement the boundary in a complete Python project.
Development · Developers, AppSec engineers
Keep untrusted object keys out of prototype and authority paths
Trace an actual nested-merge mutation, replace it with a narrow schema, and make authorization independent of inherited properties.
Development · Developers, AppSec engineers
Harden an Android app's storage, network and entry points
Encrypt local secrets with Android Keystore keys now that Jetpack Security is deprecated, set transport policy in Network Security Configuration, close exported components and mutable PendingIntents, confine WebViews, verify App Links and judge Play Integrity verdicts on the server, mapped to OWASP MASVS 2.1.
Development · Developers, AppSec engineers
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.
Planning, Design, Testing · Developers, AppSec engineers
Case study: Log4Shell (CVE-2021-44228)
How a JNDI lookup in Apache Log4j became internet-wide remote code execution, why transitive and shaded dependencies made it so hard to patch, which mitigations held, and what it teaches about dependency inventory and SBOMs.
Release, Maintenance · Developers, AppSec engineers
Prevent CRLF header injection, log forging and CSV formula injection
Carriage return and line feed separate HTTP header fields, log records and CSV rows, and a leading = turns a spreadsheet cell into a formula. Let the framework write headers, log structured JSON, and neutralize formula triggers in exports.
Development · Developers, AppSec engineers, Platform engineers and SREs
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.
Testing, Release · Developers, AppSec engineers, Platform engineers and SREs
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.
Testing, Maintenance, Security program · AppSec engineers, Platform engineers and SREs, Security leaders
Prevent DOM XSS, postMessage abuse and client-side injection
Trace attacker-controlled values from the URL, messages and storage to the browser APIs that parse HTML or run code, then close those sinks with safe APIs, a sanitizer, Trusted Types and strict message checks.
Development · Developers, AppSec engineers
Harden an iOS app's storage, network and entry points
Store secrets in the Keychain with the narrowest accessibility class, set file protection explicitly, keep App Transport Security on, prefer universal links, constrain WKWebView bridges, keep step-up keys in the Secure Enclave, verify App Attest on the server and ship an accurate privacy manifest, mapped to OWASP MASVS 2.1.
Development · Developers, AppSec engineers
Prevent NoSQL, LDAP, XPath and expression-language injection
SQL is not the only query language that receives user input. Stop MongoDB operator injection with type checks and $eq, escape LDAP filter values, pass XPath values as variables, and never evaluate SpEL or OGNL built from request data.
Development · Developers, AppSec engineers
Validate input safely and prevent regex denial of service
Find and fix exponential and quadratic regex backtracking with measured examples, choose linear-time engines or timeouts, and build allowlist validation that decodes once and rejects type confusion and parameter pollution.
Development · Developers, AppSec engineers
Audit unsafe Rust, FFI boundaries and crate dependencies
Know what the Rust compiler proves and what it leaves to you: review unsafe code for soundness, wrap foreign calls in small safe functions, decide how overflow and panics behave in release builds, gate crates with RustSec, and replace C one boundary at a time.
Development · Developers, AppSec engineers
Choose a threat modeling method and turn its findings into tests
Use the four-question frame to scope a design, pick STRIDE, attack trees, LINDDUN or PASTA by the question you need answered, and leave behind threat records and abuse-case tests the team can run.
Design · Developers, AppSec engineers
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.
Testing, Maintenance · AppSec engineers, Security leaders
Case study: MOVEit Transfer mass exploitation (CVE-2023-34362)
How one unauthenticated SQL injection in an internet-facing file transfer product let the Cl0p group steal data from thousands of organizations in days in 2023, how defenders found the web shell, and the vendor and customer controls that would have limited it.
Maintenance, Security program · Developers, AppSec engineers
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.
Planning, Design, Testing, Security program · Developers, AppSec engineers
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.
Planning, Design, Testing · Developers, AppSec engineers
Threat pattern library for threat modeling
Thirty-two recurring threat patterns grouped by identity, authorization, parsers, concurrency, integrations, data exposure, supply chain, availability and AI agents, each with where it shows up on a data-flow diagram, mitigations, a verification step and STRIDE, CWE and CAPEC links, plus a YAML catalog and a script that lists patterns per diagram element.
Design · Developers, AppSec engineers
Set up a PSIRT: services, intake, triage, SLAs and the CNA role
How to structure and run a product security incident response team on the FIRST PSIRT Services Framework: organizational models, intake channels, triage, response targets, a case record and SLA script, becoming a CVE Numbering Authority under the CNA rules 4.2.0, and coordinating with other vendors.
Maintenance · AppSec engineers, Security leaders
Publish security advisories with CSAF, VEX, CVE records and OSV
What a useful security advisory contains and how to publish it in the formats tools read: a validated CSAF 2.0 VEX document, the CSAF provider files, CVE records through a CNA (CVE Record Format 5.2), and OSV records for open-source packages. Covers the status of CSAF 2.1 as of October 2026.
Maintenance · Developers, AppSec engineers
Respond to product security incidents: plan, tabletop and postmortem
An incident response plan for product security incidents (exploited vulnerabilities, compromised releases, leaked signing keys, malicious dependencies shipped to customers), aligned with NIST SP 800-61 Rev. 3, with reporting clocks, a two-scenario tabletop exercise template and a blameless postmortem template.
Maintenance, Security program · AppSec engineers, Platform engineers and SREs, Security leaders
Prevent file inclusion: LFI, RFI, dynamic imports and template names
Stop request data from choosing which file, module or template your application loads: local and remote file inclusion in PHP, dynamic require() and import() in Node.js, importlib and template names in Python, Thymeleaf view names in Spring, render in Rails, and the allowlist fix that works in all of them.
Development · Developers, AppSec engineers
Consume third-party APIs safely (OWASP API10:2023)
Treat every upstream and third-party API response as untrusted input: validate it against a schema, set connect and read timeouts, cap the response size, refuse to follow redirects blindly, keep TLS verification on, and scope the credentials you hold for each provider.
Design, Development · Developers, AppSec engineers
Secure design patterns: a catalogue for insecure-design (A06)
A catalogue of reusable secure-design patterns, grouped by concern, each with when to use it, a short example and the failure it prevents: choke-point authorization, capability tokens, parse-don't-validate, safe-by-default APIs, tenant scoping, fail-closed, idempotency, and more.
Design · AppSec engineers
Worked threat model: a mobile banking app
A complete worked threat model for a mobile banking-style app: the data-flow diagram and its elements, STRIDE threats on the client, the transport and the backend, and the mitigations mapped to OWASP MASVS v2 controls and current Android and iOS platform APIs.
Design · AppSec engineers
Worked threat model: an LLM agent with tools
A complete worked threat model for an LLM agent with tools: the data-flow diagram, the threats from prompt injection, excessive agency, data exfiltration, confused-deputy and memory poisoning, and the mitigations, mapped to the OWASP Top 10 for LLM Applications 2026 and the OWASP Top 10 for Agentic Applications 2026.
Design · AppSec engineers
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.
Development, Testing, Maintenance, Security program · Developers, AppSec engineers, Security leaders
Case study: Citrix Bleed (CVE-2023-4966)
How a NetScaler memory over-read leaked session cookies that bypassed passwords and MFA in 2023, why patching did not end hijacked sessions, and how the pattern returned in 2025.
Maintenance · Developers, AppSec engineers
Case study: Spring4Shell (CVE-2022-22965)
How Spring's data binding let request parameters reach the class loader on JDK 9 and later in 2022, why the denylist workaround leaked, and what it teaches about framework-level mass assignment.
Development, Maintenance · Developers, AppSec engineers, Platform engineers and SREs
Software supply chain
17 guidesGenerate an SBOM for the software you actually release
Define the inventory boundary, compare build and artifact evidence, and connect the resulting SBOM to an immutable release.
Release · Developers, AppSec engineers, Platform engineers and SREs
Choose SBOM formats and identify components accurately
Separate schema versions, document references and package identities so inventory conversion and advisory matching preserve meaning.
Release · Developers, AppSec engineers
Review SBOM changes between releases
Turn inventory differences into explainable release decisions without confusing generator changes with software changes.
Release · AppSec engineers, Platform engineers and SREs
Triage new dependency vulnerability findings
Turn a weekly batch of Dependabot, OSV-Scanner or npm audit findings into a short list of distinct, shipped, reachable issues, each routed to one outcome: fix, not affected, accept or escalate.
Development, Maintenance · Developers, AppSec engineers
Use VEX without losing vulnerability evidence
Produce and consume precise vulnerability status statements tied to the product, version, justification and evidence.
Release, Maintenance · AppSec engineers
Case study: the Shai-Hulud npm worm (2025-2026)
How a self-replicating npm worm turned stolen tokens into hundreds of infected packages in 2025, how its 2026 successors hijacked release pipelines and trusted publishing, what npm and GitHub changed in response, and the publishing, install and response practices that stop it.
Development, Release, Maintenance · Developers, AppSec engineers, Platform engineers and SREs
Case study: the tj-actions/changed-files compromise (CVE-2025-30066)
In March 2025 an attacker moved the version tags of a popular GitHub Action, and of a reviewdog action before it, to code that printed CI secrets into build logs. This case study traces the token chain back to one pull_request_target workflow, sizes the exposure, and shows how it was caught and which controls held.
Development, Release, Maintenance · Developers, AppSec engineers, Platform engineers and SREs
Case study: the xz Utils backdoor (CVE-2024-3094)
How a multi-year maintainer takeover planted a backdoor in xz Utils release tarballs, how build-time injection hid it from the git repository, why a performance anomaly exposed it, which systems shipped it, and what it teaches about reproducible builds and maintainer health.
Development, Release, Maintenance, Security program · Developers, AppSec engineers, Platform engineers and SREs
Case study: the SolarWinds Orion build compromise (SUNBURST)
How an implant on SolarWinds' build server inserted the SUNBURST backdoor into signed Orion updates in 2020, how it was found, why code signing and review could not catch it, and which build controls would have.
Release, Maintenance · AppSec engineers, Platform engineers and SREs
Case study: the Codecov Bash Uploader compromise (2021)
How a credential leaked through Codecov's Docker image process let an attacker change the Bash Uploader that many CI pipelines downloaded and ran, which sent their environment variables, and the secrets in them, to the attacker for two months in 2021.
Development, Release, Maintenance · AppSec engineers, Platform engineers and SREs
Case study: the polyfill.io CDN takeover (2024)
How the sale of the polyfill.io domain and project in February 2024 turned a script tag on more than 100,000 websites into a channel for malicious redirects by June, why Subresource Integrity could not have protected it, and the controls that would have.
Development, Maintenance, Security program · AppSec engineers, Platform engineers and SREs
Stop dependency confusion and typosquatting at install time
Pin every internal package name to its real source, verify installed bytes against a lockfile, and delay or gate install scripts so a public look-alike cannot replace a private dependency.
Development · Developers, AppSec engineers, Platform engineers and SREs
Harden GitHub Actions against workflow and supply-chain attacks
Close the paths that give untrusted pull-request code secrets or a write token: pass context through env, keep pull_request_target away from fork code, pin actions to commit SHAs, scope GITHUB_TOKEN and OIDC, and treat artifacts as data.
Development, Release · Developers, AppSec engineers, Platform engineers and SREs
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.
Development, Testing, Release, Security program · Developers, AppSec engineers, Platform engineers and SREs
Secure the developer workstation: extensions, package managers, secrets and AI agents
Attackers reach the software supply chain through developers' editors, package installs and AI agents. Allow-list extensions, stop install scripts and brand-new versions, keep long-lived secrets off laptops, and lock down repository files that run code when a project opens.
Design, Development, Release · Developers, AppSec engineers, Platform engineers and SREs
Open source license compliance: SPDX expressions, obligations and SBOM checks
Know which licenses you ship, read SPDX license expressions correctly, meet the obligations of common licenses for the way you distribute, and enforce a license policy in CI from the SBOM.
Development, Release, Security program · AppSec engineers, Security leaders
Staged rollout and rollback for security-critical updates
Ship security fixes, detection content and configuration quickly without taking the fleet down: rollout rings and canaries, content validation, kill switches and rollback that works on a broken host.
Release · AppSec engineers, Platform engineers and SREs
Runtime, cloud & APIs
5 guidesCreate security logs someone can investigate
Record meaningful decisions with consistent structure, protect the resulting evidence, and prove that important events reach an operational owner.
Maintenance · Developers, AppSec engineers, Platform engineers and SREs
Operate edge rules without hiding application defects
Tune WAF and abuse controls against legitimate traffic, parser behavior and measurable business effects.
Maintenance · AppSec engineers, Platform engineers and SREs
Apply a security baseline across AWS, Azure and Google Cloud
Give workloads platform identities instead of keys, guard the instance metadata endpoint, block public storage, keep audit logs past the default retention, close inbound admin ports and use the native secret store, with tested Terraform for AWS, Azure and Google Cloud.
Release, Maintenance · Developers, AppSec engineers, Platform engineers and SREs
Harden managed Kubernetes on EKS, AKS and GKE
Know what your provider secures and what you still own, then lock down API access, cloud identity, nodes, pod privileges and admission with settings that are generally available in Kubernetes 1.37, checked against the CIS and NSA/CISA baselines.
Development, Release, Maintenance · AppSec engineers, Platform engineers and SREs
Harden the images you ship against CIS, STIG and SCAP benchmarks
Hold each image your team ships (container base images, golden VM images, Kubernetes node images) to a published benchmark through a pinned SCAP Security Guide profile, scan every build with OpenSCAP, and fail the build on any failure that a deviation register does not explain with an owner, an approver and an expiry.
Development, Release, Maintenance, Security program · Developers, AppSec engineers, Platform engineers and SREs
Identity & cryptography
9 guidesPadding oracle attacks
Use a byte-level CBC example to see how a tiny validity signal becomes plaintext information, then design verification that checks more than the error message.
Design, Development · Developers, AppSec engineers
Account recovery: password resets, help-desk resets and account linking
Treat password resets, support-desk recovery and account linking as new grants of authority: single-use high-entropy proofs, atomic consumption, session revocation, and stable identity rather than email matching.
Development · Developers, AppSec engineers
Data minimization and retention: collect less and prove that deletion works
Design collection and deletion around a data-flow graph that includes logs, derived tables, exports and restored backups, and use per-person keys so deletion can reach copies you cannot edit.
Planning, Design, Security program · Developers, AppSec engineers
Post-quantum migration: cryptographic inventory, hybrid TLS and deadlines
Inventory public-key cryptography by operation, owner and lifetime, turn on hybrid ML-KEM key exchange where it is already available, and plan signature and archive migration against the NIST, NSA, NCSC and EU dates.
Design, Maintenance · AppSec engineers
Contain a leaked secret, then investigate and clean up
Revoke an exposed API key, token or private key at its issuer before anything else, end the sessions it minted, check the provider's logs, then remove every copy and replace it with a credential that expires on its own.
Development, Maintenance · Developers, AppSec engineers, Platform engineers and SREs
Stop account takeover with the right MFA and login defenses
Rank MFA options by the attacks they stop, implement TOTP and push approvals correctly, and close the login, reset and recovery paths that attackers use instead of breaking the second factor.
Development · Developers, AppSec engineers
Defend OAuth and OIDC against redirect and token attacks
Apply RFC 9700 and RFC 10017: exact redirect matching, PKCE with downgrade protection, state and iss binding, refresh-token rotation, sender-constrained tokens, and a backend-for-frontend so browser tokens cannot be stolen.
Development · AppSec engineers
Case study: the LastPass breach (2022)
How an attacker went from a compromised developer laptop to a DevOps engineer's home computer, the keys to LastPass's cloud backups and a copy of customer vaults; why each vault's safety then rested on its master password and PBKDF2 iteration count; and what it teaches about backup keys, privileged endpoints, KDF upgrades and unencrypted metadata.
Design, Development, Maintenance · AppSec engineers, Platform engineers and SREs
Case study: certificate expiry outages at Ericsson (2018) and Microsoft Teams (2020), and Equifax's blind spot
How an expired certificate inside Ericsson's core-network software cut mobile data for millions in about 11 countries, how an expired authentication certificate took Microsoft Teams offline, how an expired inspection certificate left Equifax blind for 19 months, through its 2017 breach, and the inventory, automation and testing that prevent each.
Maintenance · Developers, AppSec engineers, Platform engineers and SREs
Governance & frameworks
20 guidesStart a minimal AppSec program with owners, triggers and metrics
Begin with ownership, a few risk-triggered activities, and evidence that findings are resolved; expand from demonstrated needs.
Security program · AppSec engineers, Security leaders
Run an AppSec program: owners, finding states, deadlines and champions
Translate a security baseline into service ownership, change triggers, reusable patterns and evidence that work reaches deployment.
Security program · AppSec engineers, Security leaders
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.
Testing, Security program · AppSec engineers, Security leaders
Run an OWASP SAMM assessment with evidence and a practical roadmap
Use OWASP SAMM to distinguish isolated successes from repeatable practices and choose improvements the organization can sustain.
Security program · AppSec engineers, Security leaders
Control mapping between frameworks: state the relationship without overstating equivalence
Record exactly how an implementation supports a requirement, which evidence is reusable and which obligations remain unresolved.
Security program · AppSec engineers, Security leaders
Supplier software assurance: check SOC 2 reports, SBOMs and signed updates against your use
Connect supplier claims to product scope, supported versions, release integrity and vulnerability handling before making a procurement decision.
Release, Security program · AppSec engineers, Platform engineers and SREs, Security leaders
Cyber Resilience Act and payment pages: turn product-security obligations into an engineering evidence plan
Determine the relevant actor, product, market and requirement before connecting CRA or payment-security expectations to implementation work.
Planning, Maintenance, Security program · AppSec engineers, Security leaders
Set remediation SLAs and measure AppSec outcomes
Set vulnerability SLAs by exploitation and exposure, route misses through expiring exceptions, and measure the program with cohort-based, censoring-aware metrics that resist gaming.
Maintenance, Security program · AppSec engineers, Platform engineers and SREs, Security leaders
Build a runbook for CRA vulnerability and incident reporting
Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform within 24 and 72 hours. Decide what is reportable, start the clock at the right moment, file through the platform and keep an evidence trail.
Maintenance, Security program · AppSec engineers, Security leaders
Map PCI DSS Requirement 6 to engineering practice and evidence
Turn PCI DSS v4.0.1 Requirement 6 into engineering work: secure development, review, patching, web-attack protection, payment-page script control and change management, with the records an assessor samples and the parts that became mandatory on 31 March 2025.
Security program · AppSec engineers, Platform engineers and SREs, Security leaders
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.
Testing, Security program · AppSec engineers, Security leaders
Prioritize vulnerabilities by exploitation, exposure and impact
Rank vulnerabilities with CISA KEV, EPSS, CVSS 4.0 vectors and SSVC decision points, adjust for presence, reachability and asset value, and turn the result into due dates. Covers NVD's 2026 enrichment changes and CISA BOD 26-04.
Maintenance, Security program · AppSec engineers, Security leaders
Apply CISA Secure by Design: principles, pledge goals and evidence
What CISA's Secure by Design guidance and pledge ask of software manufacturers as of October 2026, and how to turn each of the three principles, the seven pledge goals and the Product Security Bad Practices into engineering actions, metrics and evidence.
Security program · AppSec engineers, Security leaders
BSIMM vs SAMM vs SSDF: what each is for and which to use
How BSIMM16, OWASP SAMM 2.2.0 and NIST SSDF 1.1 differ, what each measures and does not, a chooser by situation, and a verified SSDF-to-BSIMM16-and-SAMM crosswalk with a script that reports evidence gaps.
Security program · AppSec engineers, Security leaders
Run a developer security training program that changes code
Build role-based, hands-on developer security training from this site's learning paths, labs and fix cards, meet PCI DSS 6.2.2, NIST SSDF PO.2.2 and ISO/IEC 27001 A.6.3 with real evidence, and measure the effect with repeat findings instead of completion rates.
Security program · Developers, AppSec engineers, Security leaders
Build an application security career: roles, skills, portfolio and certifications
The main application security role tracks (AppSec engineer, product security engineer, security champion, platform security engineer, security architect), the skills expected at each level, how to build a portfolio a hiring team can verify using this site's labs, projects and fix cards, and what common certifications do and do not show.
Security program · Developers, AppSec engineers, Security leaders
NIST CSF 2.0 for product teams: the outcomes you own and the evidence for them
Find the CSF 2.0 outcomes a product team actually owns, including GOVERN and supply-chain risk management (GV.SC), write a current and target profile for one product, and check it against NIST's own catalog in CI.
Security program · AppSec engineers, Security leaders
UK Software Security Code of Practice: the 14 principles as engineering practice
What the UK government's voluntary Software Security Code of Practice (May 2025) asks of software vendors, each of its 14 principles mapped to engineering practice, NIST SSDF and the EU Cyber Resilience Act, and a CI check for the support-period principles.
Maintenance, Security program · AppSec engineers, Security leaders
Regulated product security lifecycles: IEC 62443-4-1, FDA 524B, ISO/SAE 21434 and UN R155/R156
What the secure development lifecycles for industrial, medical and automotive products require, the practices they share (threat modeling, SBOM, vulnerability handling and updates), and how to build that evidence once and package it for each instrument.
Planning, Security program · AppSec engineers, Security leaders
Compliance evidence reuse: one evidence set for SSDF, PCI DSS, ISO 27001, SOC 2 and the CRA
Keep one set of release-bound engineering evidence (SBOM, provenance, review records, scan results, ASVS results and vulnerability handling) and map it to several frameworks: a worked crosswalk, an evidence index checked in CI with a CSV export, and an OSCAL component definition.
Release, Security program · AppSec engineers, Platform engineers and SREs, Security leaders
AI security
16 guidesContain prompt injection at the application boundary
Assume retrieved content can influence model output; enforce data access and consequential actions in components the model cannot authorize for itself.
Design, Development · Developers, AppSec engineers, Platform engineers and SREs
Keep retrieval inside the user’s data boundary
Carry document permissions through ingestion, retrieval, caching and citations so a model never receives another tenant’s records.
Design, Development · Developers, AppSec engineers, Platform engineers and SREs
Authorize agent tools outside the model
Bind each proposed action to the user, resource and approved arguments before allowing a tool to cause a side effect.
Design, Development · Developers, AppSec engineers, Platform engineers and SREs
Keep generated output out of executable contexts
Choose safe rendering and narrow operations so model text cannot become browser code, database syntax or an unrestricted command.
Design, Development · Developers, AppSec engineers, Platform engineers and SREs
Build evaluations around prohibited outcomes
Test the application’s actual security boundaries, preserve legitimate tasks and distinguish deterministic enforcement from variable model behavior.
Design, Testing, Security program · Developers, AppSec engineers, Platform engineers and SREs
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.
Design, Testing, Security program · Developers, AppSec engineers, Platform engineers and SREs
Bound agent spending, memory and recovery
Enforce budgets and stop conditions outside the model, and make retained context and side effects recoverable.
Design, Development · Developers, AppSec engineers, Platform engineers and SREs
Treat model releases as executable supply-chain inputs
Verify provenance, constrain loading and preserve the relationship between model weights, configuration and runtime dependencies.
Development, Release · Developers, AppSec engineers, Platform engineers and SREs
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.
Development, Testing, Release, Security program · Developers, AppSec engineers, Platform engineers and SREs
Assess extraction, membership and inference risks
Define what an adversary can observe and measure privacy leakage without confusing a model’s output with proof about its training data.
Design, Development, Release · AppSec engineers
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.
Planning, Testing, Security program · Developers, AppSec engineers, Platform engineers and SREs, Security leaders
Secure AI-assisted development with coding assistants and agents
Treat generated code, suggested packages, repository text and MCP servers as untrusted inputs, and confine coding agents with OS-level isolation and short-lived, narrowly scoped credentials.
Design, Development · Developers, AppSec engineers
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.
Design, Development, Testing, Security program · AppSec engineers
Call a hosted LLM API safely
A code-first checklist for wiring up an OpenAI or Anthropic API call from a backend: keep keys server-side, redact PII before prompts and logs, choose provider retention settings deliberately, validate structured output and still treat it as untrusted, and set timeouts, retries and per-user cost caps.
Design, Development · Developers, AppSec engineers
Keep secrets and controls out of hidden context (OWASP LLM08:2026)
OWASP LLM08:2026 Hidden Context Exposure, which replaced System Prompt Leakage: why system prompts, tool schemas and retrieved policy text get extracted, what must never be in them, and how to enforce rules where a leak changes nothing.
Design, Development · Developers, AppSec engineers
Defend agent memory and context against poisoning (OWASP ASI06)
OWASP ASI06 Memory & Context Poisoning: how an instruction or false fact saved once in agent memory, conversation summaries or a retrieval store steers later sessions, users and agents, and the write, scope, provenance, expiry and recovery controls that contain it.
Design, Development · Developers, AppSec engineers