The National Institute of Standards and Technology published CSF 2.0 in February 2024, the first full revision of the Cybersecurity Framework since version 1.1 in 2018, and it added a sixth top-level function — Govern — that sits alongside the original Identify, Protect, Detect, Respond, and Recover. NIST is explicit that CSF is voluntary guidance, not a regulation, but that hasn't stopped it from becoming a de facto shared vocabulary between security teams, auditors, and boards. The framework's own structure is a hierarchy: six Functions break down into Categories, which break down into Subcategories — specific, auditable outcomes — and organizations use Tiers to describe how rigorous their risk management is and Profiles to describe where they are versus where they want to be. NIST has also published companion guidance that plugs into this structure, including NIST IR 8374 for ransomware risk profiles and NIST SP 800-70's checklist mappings to CSF 2.0. Most AppSec teams, though, only consciously map their tooling to three of the six functions — Protect (SAST/SCA gates), Detect (runtime and dependency alerts), and maybe Identify (asset inventory) — leaving Govern, Respond, and Recover as someone else's problem. This post walks through what concrete AppSec activity belongs under each of the six functions, and where tooling actually earns its keep versus where it's just a checkbox.
What does the Govern function mean for an AppSec program?
Govern is the newest CSF 2.0 function, and for AppSec it means the policies, roles, and risk-tolerance decisions that determine what "secure code" even means at your organization — before a single scanner runs. Concretely, this is where you document who owns application security risk acceptance, what severity threshold blocks a release, and how third-party/supply-chain risk (open-source dependencies, SaaS integrations) gets reviewed before adoption. NIST's own framework materials describe Govern as cutting across all the other functions rather than sitting apart from them, which is why it was added as a standalone function in 2.0 instead of being folded into Identify as it effectively was in CSF 1.1. In practice, an AppSec team's Govern artifacts are things like a documented severity-to-SLA matrix (critical CVEs fixed in 7 days, high in 30), a named accountable owner for exceptions, and a supply-chain risk policy that says which package registries and license types are acceptable before code review even starts.
What belongs under Identify for application security?
Identify is asset and risk inventory — for AppSec, that means knowing what code, dependencies, and services exist before you can decide what to protect. The core artifact here is a Software Bill of Materials (SBOM): a structured list, typically in CycloneDX or SPDX format, of every direct and transitive dependency in an application along with its version and license. Executive Order 14028, issued in May 2021, pushed SBOMs into federal software procurement requirements, and NIST's own guidance (including SP 800-161 on cyber supply chain risk management) treats dependency inventory as foundational risk data rather than a nice-to-have. Identify also covers attack-surface mapping — which services are internet-facing, which handle regulated data — and a current inventory of which repositories even have security tooling wired into CI at all, since an untracked repository is an Identify gap no scanner downstream can compensate for.
Which AppSec controls map to Protect?
Protect is where most existing AppSec tooling already lives: static analysis (SAST), software composition analysis (SCA), secrets scanning, and secure-coding standards enforced in CI before code ships. A SAST tool flags a SQL-injection pattern before merge; an SCA tool blocks a pull request that introduces a package with a known critical CVE; a pre-commit secrets scanner stops an AWS key from ever reaching a public commit. Protect subcategories in CSF 2.0 also cover identity and access management for the pipeline itself — who can approve a merge, who can push directly to a protected branch, whether CI credentials are scoped narrowly — because a perfectly scanned codebase is still exposed if the deployment pipeline that ships it has broad, unaudited write access. The distinguishing trait of Protect activities is that they're preventive and automated: they run on every commit or pull request, not on a quarterly audit cadence.
How does Detect apply once code is already running?
Detect covers the controls that catch a problem after code has shipped — runtime application self-protection (RASP), web application firewalls, anomaly detection on API traffic, and, critically for AppSec, continuous re-scanning of production dependencies against newly disclosed CVEs. A dependency that was clean at deploy time can become vulnerable the moment a new CVE is published against it, so Detect for AppSec means an ongoing feed, not a one-time gate. This is also where reachability analysis earns its place: research from multiple SCA vendors between 2023 and 2024 found that a large majority of CVEs flagged in typical application dependency trees sit in code paths that are never actually invoked at runtime, so Detect activity that can't distinguish reachable from unreachable findings tends to bury real signal under noise the team eventually starts ignoring.
What do Respond and Recover look like for a vulnerability disclosure?
Respond and Recover are the two functions AppSec teams most often treat as someone else's job — incident response's, not the security engineering team's — but a critical CVE in a production dependency is exactly the kind of event they're built for. Respond covers the mechanics of triage and communication once a vulnerability is confirmed exploitable: who gets notified, what the patch timeline is, and whether a customer-facing security advisory is required. Recover covers restoring the affected service to a known-good state and the after-action review that feeds lessons back into Govern and Protect — for example, deciding that a dependency category needs an additional pinning policy after a supply-chain incident. NIST's framework materials describe these as continuous, overlapping activities rather than a strict sequence, which matters for AppSec because a single vulnerable dependency disclosure can trigger Respond and Recover activity simultaneously across multiple services that all pulled in the same package.
How does Safeguard support NIST CSF 2.0 alignment?
Safeguard supports NIST CSF 2.0 alignment as one of its compliance framework mappings, giving security teams a dashboard view of how existing evidence — SBOMs, SCA and SAST findings, remediation timelines — lines up against CSF's Identify, Protect, and Detect subcategories without building that mapping by hand. Because Safeguard already generates CycloneDX SBOMs on every build and tracks reachability for every dependency finding, the Identify and Detect evidence a CSF assessment asks for is produced as a byproduct of the pipeline rather than a separate audit exercise. That same evidence trail — which findings were reachable, which were remediated, and how quickly — is also what turns Respond and Recover from a narrative claim in a spreadsheet into something an assessor can actually verify against your commit and deployment history.