CISA's BOD 22-01, NIST SP 800-161, and the SBOM guidance published jointly by CISA, NTIA, and NSA are not abstract policy documents.
They are the product of real incidents. Log4Shell exposed how blind most organizations were to their own dependency trees. SolarWinds proved that supply chain compromise could bypass every perimeter control. Those incidents made regulators put specific controls in writing. Most developers never read them: they read like compliance documents, not engineering problems.
They are engineering problems. Six of the controls those documents define live at the code and pipeline layer: your dependency scanner, your CI configuration, your SBOM generator. They are not your CISO's problem. They are yours.
For reference: JPMorgan's 2026 enterprise resilience framework lists the same six controls — not because JPMC invented them, but because they follow the same regulators you do. When the largest US financial institution and the federal government's cybersecurity agency agree on the same list, the controls are settled. The implementation gap is not.
This post covers the six developer-layer controls: what CISA and NIST actually require, and what implementation looks like in practice.
The six controls
All six live at the code and pipeline layer. Here's what each one requires in practice.
| Control | Authority | What it requires | CodeSlick |
|---|---|---|---|
| Dependency hygiene | CISA BOD 22-01 + KEV Catalog | Remediate known-exploited packages on SLA timelines | Dependency scanner: full lockfile, transitive tree, OSV.dev |
| SBOM generation | CISA/NTIA/NSA SBOM guidance | Machine-readable inventory of all software components | SPDX + CycloneDX export |
| Vulnerability management | CISA KEV Catalog + NIST SP 800-218 | Risk-tiered remediation, not equal treatment of all findings | 306 checks, CVSS 3.1, contextual severity tiers |
| Supply chain risk | NIST SP 800-161 Rev. 1 | Track and assess third-party software components | Malicious package detection, 66 known-bad packages, OSV.dev |
| Shift-left | NIST/CISA DevSecOps guidance | Integrate security checks into development workflow, not after | PR analysis under 30s, pre-commit hook under 5s |
| AI code validation | CISA AI security guidance (2024) | Apply same review standards to AI-generated code as human code | 164-signal AI detection, 12 MCP server checks |
Dependency hygiene
Unpatched known-exploited packages are the highest-volume initial access vector in real attacks. This is not a theoretical risk.
CISA's Binding Operational Directive 22-01 mandates remediation timelines for federal agencies because unpatched packages are actively being used in real attacks right now. The KEV Catalog is CISA's running list of CVEs with confirmed exploitation in the wild. If something is on the KEV list, it has been used to breach someone.
CISA BOD 22-01 + KEV Catalog
Remediation timelines for known-exploited vulnerabilities: 14 days for most entries, 6 months for vulnerabilities predating the directive. The KEV Catalog is updated continuously as new exploitation is confirmed.
The dependency scanner parses full lockfiles across npm, pip, Maven, and Go modules, not just the top-level manifest. On a typical Node.js project that means scanning 1,000+ packages per OSV.dev query. Results are severity-tiered. The fix is listed directly in the finding: bump from version X to version Y.
SBOM — know what's in your software
A Software Bill of Materials is a machine-readable list of every component in your software: direct dependencies, transitive dependencies, versions, licenses. Without one, you're patching blind.
When Log4Shell dropped in December 2021, organizations without SBOMs spent days figuring out if they were affected. Organizations with SBOMs knew in hours. That gap in time and confidence is what the SBOM mandate addresses.
CISA/NTIA/NSA — "The Minimum Elements for a Software Bill of Materials" (July 2021)
Established SPDX and CycloneDX as the two accepted SBOM formats. Required for software sold to or used by federal agencies. NIST SP 800-218 (Secure Software Development Framework) makes SBOM generation a requirement in the development lifecycle.
Generates SBOMs in both SPDX and CycloneDX formats from any supported codebase. Output is version-stamped and compatible with GitHub Security Tab upload. When a buyer or auditor asks for an SBOM, you export it from the same scan that runs on every PR. No separate tooling, no separate process.
Vulnerability management — severity tiers, not equal treatment
Internal cron job utility
No external input. No network exposure. Unreachable from untrusted source.
Unauthenticated public search endpoint
SQL injection. Directly reachable from the internet.
CVSS scores are a proxy for severity, not a measure of risk. CISA created the KEV Catalog specifically because CVSS scores were not getting the right things patched first. The CVSS 9.8 looks scarier. The CVSS 7.0 is the one that gets you breached.
Risk-tiered remediation means patching in order of actual exploitability and exposure, not score. NIST SP 800-218 and the KEV Catalog together define this as the required approach.
CISA KEV Catalog + NIST SP 800-218
NIST SP 800-218 (Secure Software Development Framework) requires organizations to monitor components for known vulnerabilities and respond based on exploitation likelihood and exposure, not just severity score.
306 security checks across JS, TS, Python, Java, and Go. Every finding carries a CVSS 3.1 score, CWE classification, and contextual priority weighting based on authentication layer, production context, and exposure surface. Two-tier output separates blocking findings (halt the PR) from advisory findings (review this sprint). Not everything is equally urgent, and CodeSlick does not pretend it is.
Supply chain risk — your dependencies are someone else's attack surface
The packages you import are code you ship. NIST SP 800-161 Rev. 1 makes supply chain risk management a first-class security discipline, not a subcategory of vendor assessment.
The attack pattern is established: insert a malicious payload into a widely-used package and wait for developers to install it. event-stream in 2018. ua-parser-js in 2021. New names every month. A package four levels deep in your lockfile that you have never heard of is still part of your attack surface.
NIST SP 800-161 Rev. 1 — Cybersecurity Supply Chain Risk Management
Requires organizations to identify, assess, and respond to cybersecurity risks throughout their supply chain. Third-party software components are in scope. CISA secure software practices guidance extends this to open-source dependencies and build pipelines.
Malicious package detection across 66 known-bad packages, plus behavioral heuristics for packages showing zero-day characteristics before the databases catch up. Full lockfile parsing covers the entire transitive dependency tree, not just what you explicitly installed, but what those packages installed.
Shift-left — catch it before it merges
The cost of remediating a vulnerability rises by an order of magnitude at each stage from development to production. Finding a SQL injection before the PR is merged costs minutes. Finding it in production costs a breach disclosure.
NIST and CISA's DevSecOps guidance identifies closing the gap between vulnerability introduction and detection as the primary lever for reducing security cost. Not buying more tools. Using tools earlier, in the developer's workflow, before code reaches review.
NIST DevSecOps practices + CISA Secure SDLC guidance
Integrate security testing into the development pipeline at the earliest possible stage. Security checks in CI/CD are a minimum. Checks that run before code leaves the developer's machine are the target state.
GitHub App
Runs on every PR. Results in under 30 seconds as inline PR comments, before the reviewer sees the diff.
CLI pre-commit hook
Runs in under 5 seconds on the local machine. Blocks the commit before it reaches CI.
Both surfaces (GitHub App and CLI pre-commit) run the same 306-check engine. There is no configuration gap between what the developer sees locally and what the pipeline sees. A finding caught at commit and a finding caught at PR are the same finding.
AI code validation
This is the newest of the six controls. CISA's AI security guidance was published in 2024 and the industry is still working out what "validate AI-generated code" means operationally. The concern is real; the tooling is early.
AI-generated code fails in the same ways human code fails: injection, secrets exposure, insecure crypto. It also fails in ways specific to how LLMs generate code:
- Hallucinated APIs that look syntactically correct until they hit a real request
- Framework misuse that passes type checking and breaks under concurrent load
- Security patterns that are 90% correct and fail on the edge case the model did not encounter in training
CISA's 2024 guidance is explicit: the same review standards that apply to human-authored code apply to AI-generated code. The same bar. The same checks.
CISA Guidance for Secure AI System Development (2023) + NIST AI RMF 1.0
Apply the same security review and testing standards to AI-generated code as to human-authored code. NIST AI RMF 1.0 covers secure development practices for AI systems, including the pipelines and tools they run on.
164 signals for AI-generated code: hallucination patterns, LLM fingerprints specific to GPT-4, Copilot, and Claude outputs, and framework misuse signatures. MCP Server Security adds 12 checks for AI infrastructure: prompt injection vectors, tool schema vulnerabilities, unsafe server configurations.
Honest scope: this catches structural patterns that LLMs consistently get wrong. It does not replace code review. It scans a layer that no other static analysis tool covers at this depth.
What this means in practice
These six controls are not new. CISA and NIST have published them in different forms for years. They keep appearing because they keep working: unpatched known-exploited packages remain the most common initial access vector, enterprise buyers increasingly require SBOMs before procurement decisions, and AI-generated code is now in most codebases whether teams are tracking it or not. The controls are settled. The implementation gap is not.
Static analysis and dependency scanning cover the code layer. Network controls, privilege management, and incident response are real controls that matter. They belong to your infrastructure team, not your CI configuration. The six above are the developer's share.
Related posts
Security is a risk management discipline, not a hygiene checklist.
Why CVSS scores alone fail you — and how contextual risk scoring changes the calculation.
We Got Owned by Snyk. So We Built What They Have — In One Day.
The incident that exposed how most dependency scanners only read the top-level manifest.
Run all six checks on your codebase
Free for individual developers: 1 repo, 20 PR analyses per month.
Team plan starts at €39/month for up to 5 members and 5 repos.