NIST SSDF · SP 800-218 edition

NIST SSDF Secure Coding Challenges

NIST's Secure Software Development Framework requires role-based secure coding training (PO.2) and defines exactly what "well-secured" source code, review and testing look like (PW.4–PW.9). It's the baseline behind Executive Order 14028's self-attestation for anyone selling software to the U.S. federal government.

Book a Demo Explore the Mapping

Ready when the auditor asks

Generate Your NIST SSDF Training Report

Every completed challenge rolls up into a NIST SSDF training report. Point and click to generate it, then hand it straight to your auditor, customer or partner the moment they ask for evidence.

Capability, not checkbox compliance

Hands-On Challenges for Every Category

NIST SP 800-218 organizes secure development into four practice groups. "Prepare the Organization" (PO.2) requires role-based training for developers, testers and architects before they touch a secure SDLC. "Produce Well-Secured Software" (PW) is where that training gets applied: reusing vetted components, writing code to secure practices, reviewing it, testing it, and configuring it securely by default. Every challenge below is a real vulnerability mapped to a PW practice. Developers fix it without breaking functionality, and every verified fix is evidence your organization can point to for an EO 14028 self-attestation or a federal software supply-chain review.

Satisfying PO.2 role-based training

OWASP Top 10 Course

Role-based secure coding training for developers, testers and architects, the practice SSDF's "Prepare the Organization" group (PO.2) asks for before any of PW.4 through PW.9 can be applied.

Start the Course

PW.4 · Reuse Well-Secured Software

Reuse Existing, Well-Secured Software

Vetting third-party components, dependencies and build pipelines before trusting them in production.

easy

Improper Artifact Integrity Validation

A build step pipes a remote script straight into a shell without verifying it. Harden the pipeline so it no longer executes unverified code from the…

medium

Dependency Confusion

A CI/CD pipeline resolves an internal package name from a public registry. Fix the workflow so a look-alike public package can never shadow your…

medium

Poisoned Pipeline Execution

A poisoned pipeline execution lets untrusted code changes run with the workflow's privileges. Lock down what the pipeline checks out and runs.

PW.5 · Create Source Code Per Secure Coding Practices

Create Source Code Per Secure Coding Practices

The core of SSDF's PW group: write code resistant to injection, the most common class of exploitable defect.

easy

SQL Injection

This is a classic security challenge where an app uses a SQL database and does not use parametrised query or ORM.

easy

Command Injection

When untrusted data is used as an argument to an external program, command injection can happen.

easy

Cross-Site Scripting

An app renders untrusted input back into the page without encoding it, letting an attacker run arbitrary script in another user's session.

easy

Insecure Deserialisation

Deserialising untrusted data can result in arbitrary code execution. In this appsec challenge, we learn how to exploit and fix insecure…

PW.7 · Review & Analyze Code

Review & Analyze Human-Readable Code

The access-control and authorization bugs that manual and automated review are meant to catch before release.

easy

Broken Object Level Authorization

An endpoint hands out any user's records if you guess the ID. Add object-level authorization checks so users can only reach their own data.

easy

Server-Side Request Forgery

In this challenge we learn how to exploit and fix Server Side Request Forgery.

easy

Broken Function Level Authorization

Administrative functions are exposed to any authenticated caller. Enforce function-level authorization on privileged endpoints.

easy

Cross-Site Request Forgery

A state-changing request has no per-session token, so a malicious page can trigger it on a logged-in user's behalf. It is exactly the kind of gap a…

PW.8 · Test Executable Code

Test Executable Code

Race conditions, resource exhaustion and other runtime failures that only show up under test, or under attack.

hard

Time-of-Check to Time-of-Use

This appsec challenge showcases a Time of Check, Time of Use (ToCToU) vulnerability, a hard-to-discover race condition.

easy

Unrestricted Resource Consumption

A single expensive request can grind this API to a halt. Add limits so resource use stays bounded.

PW.9 · Configure Software With Secure Defaults

Configure Software With Secure Defaults

Hardened configuration out of the box: no exposed secrets, no over-broad permissions, no unsafe defaults.

easy

Secret Disclosure

Secrets such as an API or encryption key are used for various security operations. Disclosure of the secret can severely undermine the security of…

easy

Insecure App Permissions

Excessive or unnecessary app permissions increase the attack surface, potentially exposing sensitive user data to misuse.

Roll it out

Turn the Standard Into a Training Program

Assign these challenges to your team as learning pathways, track verified fixes, and report NIST SSDF coverage to auditors, customers and the board, with evidence, not attendance sheets.

Book a Demo Browse challenges by language