Vulnerability management the impact of the new CISA directive 22-01

CISA 22-01 Mandate resolution timeline for vulnerabilities

Vulnerability management has been lagging a bit behind, but recent, the US government has ramped up several regulations. 

Vulnerability resolution time and prioritization of specific vulnerabilities have driven much-needed changes in this field. 

Since 2021, with the appointment of a new director, the U.S. government’s Cybersecurity and Infrastructure Security Agency (CISA) has been making a name for itself with big moves like its new “Hack DHS” bug bounty program and the creation of a cybersecurity advisory committee made up of industry representatives.

July 2021 CISA “Cyber actors continue to exploit publicly known—and often dated—software vulnerabilities,” 

CISA has introduced CISA directive 22-01 that takes more drastic action on the vulnerabilities that need to be addressed. 

Now the policy does not mandate resolution time but is strict on executing a plan for internal vulnerability management procedures.

a. Establish a process for ongoing remediation of vulnerabilities that CISA identifies, through inclusion in the CISA-managed catalogue of known exploited vulnerabilities, as carrying significant risk to the federal enterprise within a timeframe set by CISA under this directive;

Without tracking those metrics is difficult to know which asset is falling behind patching or resolution. 

This resolution follows the previous order by the White House on software security and supply chain management. Executive order on Improving the Nation’s Cybersecurity. 

This binding operational directive (BOD) is mandatory for all U.S. “federal civilian agencies” to solve the problem and reduce U.S. government exposure to today’s swarm of vulnerabilities.

The challenge is that CISA directive does not specify context or risk vulnerability resolution. It just mentions the resolution plan.

The common vulnerability actions are specified in the KEV repository (known exploited vulnerabilities). https://cisa.gov/known-exploited-vulnerabilities 

The smart teams are already focusing on prioritizing vulnerabilities with resolution time technologies like EPSS and other Cyber Threat intelligence to focus on the more exploitable vulnerabilities.

Relax. In this post, we’ll cover everything you need to know about CISA directive 22-01, with some guidelines on prioritising vulnerabilities and keeping the focus on team burnout and compliance.

What Does CISA Directive 22-01 Say?

What Does CISA Directive 22-01 Say?

CISA was formed in 2018 to “lead the national effort to understand, manage, and reduce risk to our cyber and physical infrastructure.” CISA focuses on collaboration and disclosing which vulnerabilities are more exploitable under the KEV; nonetheless, the procedures under which the new vulnerabilities are integrated and deprioritized are obscure. 

This latest BOD is an add-on to the earlier BOD 19-02, which called for an increased effort toward vulnerability remediation: “[I]t is more critical than ever for federal agencies to rapidly remediate vulnerabilities that otherwise could allow malicious actors to compromise federal networks through exploitable, externally-facing systems.”

The BoD is also known as “Reducing the Significant Risk of Known Exploited Vulnerabilities” and is the first CISA attempt to tackle prioritization under the mostly exploitable Vulnerabilities. 

Is the high exploitation factor the only factor you should consider when analysing which vulnerabilities to fix? 

Is one of the elements, but not the only one; some examples to consider are:

Probability of exploitation

  • The severity of a vulnerability (CVE, CWE, CVSS and CWSS)
  • The locality of an asset, also known as Context
  • Exploitability of a vulnerability, based on the availability of Proof of concept or code snippet
  • Probability of an attacker targeting the vulnerability
  • Active exploitation of the vulnerability from threat actors groups 
  • Discussion on Twitter, Linkedin, Reddit and other forums
  • The freshness of vulnerability (in the first 40 days, vulnerabilities are exploited/targeted more frequently) 

Nonetheless, the BOD 19-02 only focuses on the known exploited vulnerabilities. catalog of about 300 “known vulnerabilities,”. BOD 19-02 and 20-02 are a move forward with more due diligence when handling high-risk vulnerabilities and putting some governance around resolution time. 

Companies that do business with the U.S. government need to remediate any listed vulnerabilities by the corresponding due dates (which are set according to the date the vulnerability was discovered and its severity). 

CISA plans to update this list from time to time as due dates pass and new vulnerabilities emerge.

Additionally, all compliant organizations must report their progress to CISA as they work toward these deadlines.

Organizations failing to comply by the due dates listed will presumably face administrative penalties and potentially lose important U.S. government contracts. But the repercussions go much further—and could affect you no matter your industry.

Vulnerability remediation plan and do You Need to Comply with CISA Directive 22-01?

The answer is probably yes at a certain point in time. With UK and USA ties strengthening and CISA opening a new office in the UK there is a high chance that the NCSC will start mandating the same form of regulatory compliance. 

The short answer to this question is you probably don’t unless you’re working for the U.S. government. But in reality, you probably shouldn’t ignore it, either.

According to CISA, this BOD 22-01 “applies to all software and hardware found on federal information systems managed on agency premises or hosted by third parties on an agency’s behalf.” This includes the federal and executive branch departments and agencies of the United States.

But the U.S. government is also strongly recommending this standard even for private businesses, as is clear from CISA director Jen Easterly’s tweet: “The BOD applies to federal civilian agencies; however, ALL organizations should adopt this Directive and prioritize mitigating vulnerabilities listed on our public catalogue, which are being actively used to exploit public and private organizations.”

The Tweet makes sense but also highlights the focus and overwhelm on any exploitable vulnerability regardless of where it is. A less likely vulnerability not on the CISA list or cloud misconfiguration might be as dangerous, if not more dangerous, depending on where it manifests. 

Nonetheless, this regulation is a step forward to focus on what’s more important to fix first. 

  • The vulnerability exploited in the wild is real. Even if you are not doing business with the US government, one of those vulnerabilities will likely be exploited. 
  • You may need to comply soon. Other governments and large enterprises will likely follow CISA’s lead and make complying with BOD 22-01 or similar standards mandatory for doing business with them. This might include NCSC and other Cyber essential regulations in the UK
  • Prioritization of Exploitability is not the only factor: prioritizing based on exploitability alone is not the only factor, and the list is static. The risk of vulnerabilities is dynamic and changes over time see Vulnerability Prioritization Blog here 

Even if you don’t have to comply, you definitely should. And it may be simpler than you think.

How can you prioritize vulnerabilities and prevent burnout from CISA Directive 22-01?

The U.S. government has put BOD 22-01 in place because today’s businesses are struggling to keep up. The reason is simple, there is no contextual monitoring of vulnerabilities and teams are stretched. 

This regulation takes us a step further in due diligence and prioritization for Vulnerabilities.

According to a CISA report, “Focusing scarce cyber defence resources on patching those vulnerabilities that cyber actors most often use offers the potential of bolstering network security while impeding our adversaries’ operations.” 

Patching is the first line of defence, but don’t forget other vulnerabilities and misconfiguration comes in place. 

That’s easier said than done. Patching, remediating vulnerability at scale and deciding which vulnerability to fix first can be difficult, regardless of the mandated compliance. 

CISA also has new Cybersecurity Incident and Vulnerability Response Playbooks, explaining, “Existing patch and asset management tools are critical and can be used to automate the detection process for most vulnerabilities.” 

Threat intelligence and automation can greatly help in fixing vulnerabilities. 

It also introduces the concept of Business criticality in vulnerability remediation. 

Risk and remediation are probably the best tools to select which vulnerability to solve. 

Risk = Probability (Likelihood of exploitation, Locality)  * Severity * Impact 

For more details on leveraging risk-based contextualization and prioritization to tackle CISA KEV mandated and other vulnerabilities and misconfiguration, refer to WHY PRIORITIZE VULNERABILITY? A CASE FOR RISK AND CONTEXTUAL-BASED PRIORITIZATION FOR APPLICATION SECURITY AND CLOUD SECURITY

Phoenix Security has introduced auto-tagging and automatic selection of KEV-mandated CISA vulnerabilities. 

Leveraging threat intelligence and business impact assessment also easy to prioritize automatically the vulnerabilities that matter most. 

In other words, automation and intelligent patching are crucial to meet evolving modern regulatory standards like CISA’s BOD 22-01.


Get a demo today: https://staging-appsecphoenixcom.kinsta.cloud/demo/ 

Francesco is an internationally renowned public speaker, with multiple interviews in high-profile publications (eg. Forbes), and an author of numerous books and articles, who utilises his platform to evangelize the importance of Cloud security and cutting-edge technologies on a global scale.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

Learn how to predict ransomware risks and vulnerability exploitation using a threat-centric approach. Explore data-driven insights, verified exploit trends, and methods for assessing the likelihood of attacks with key references to CISA KEV, EPSS, and Phoenix Security’s 4D Risk Formula.
Francesco Cipollone
Remote Code Execution flaws continue to undermine Kubernetes ingress integrity. IngressNightmare (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974) showcases severe threat vectors in NGINX-based proxies, leading to cluster-wide exposure. ASPM, robust remediation tactics, and strong application security solutions—like Phoenix Security—mitigate these vulnerabilities before ransomware groups exploit them.
Francesco Cipollone
Remote Code Execution flaws continue to undermine Kubernetes ingress integrity. IngressNightmare (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974) showcases severe threat vectors in NGINX-based proxies, leading to cluster-wide exposure. ASPM, robust remediation tactics, and strong application security solutions—like Phoenix Security—mitigate these vulnerabilities before ransomware groups exploit them.
Francesco Cipollone
The recent Google acquisition of Wiz for $32 billion has sent shockwaves through the cybersecurity industry, particularly in the realm of Application Security Posture Management (ASPM). This monumental deal highlights the critical importance of cloud security and the growing demand for robust ASPM solutions. While the acquisition promises potential benefits for Google Cloud users, it also raises concerns about vendor lock-in and the future of cloud-agnostic security. Explore the implications of this acquisition and discover how neutral ASPM solutions like Phoenix Security can bridge the gap in multi-cloud environments, ensuring continuous, collaborative, and comprehensive security from code to cloud.” – Find Assets/Vulns by Scanner – Detailed findings Location information Risk-based Posture Management – Risk and Risk Magnitude for Assets – Filter assets and vulnerabilities by source scanner Integrations – BurpSuite XML Import – Assessment Import API Other Improvements – Improved multi-selection in filters – New CVSS Score column in Vulnerabilities
Alfonso Eusebio
The team at Phoenix Security pleased to bring you another set of new application security (ASPM) features and improvements for vulnerability management across application and cloud security engines. This release builds on top of previous releases with key additions and progress across multiple areas of the platform. Application Security Posture Management (ASPM) Enhancements • New Weighted Asset Risk Formula – Refined risk aggregation for tailored vulnerability management. • Auto-Approval of Risk Exceptions – Accelerate mitigation by automating security approvals. • Enhanced Risk Explorer & Business Unit Insights – Monitor and analyze risk exposure by business units for better prioritization. Vulnerability & Asset Management • Link Findings to Existing Tickets – Seamless GitHub, ServiceNow, and Azure DevOps integration. • Multi-Finding Ticketing for ADO – Group multiple vulnerabilities in a single ticket for better workflow management. • Filter by Business Unit, CWE, Ownership, and Deployment Environment – Target vulnerabilities with precision using advanced filtering. Cyber Threat Intelligence & Security Enhancements • Cyber Threat Intelligence Premium – Access 128,000+ exploits for better exploitability and fixability metrics. • SBOM, Container SBOM & Open Source Artifact Analysis – Conduct deep security analysis with reachability insights. • Enhanced Lacework Container Management – Fetch and analyze running container details for better security reporting. • REST API Enhancements – Use asset tags for automated deployments and streamline security processes. Other Key Updates • CVE & CWE Columns Added – Compare vulnerabilities more effectively. • Custom Status Management for Findings – Personalize security workflows with custom status configurations. • Impact & Risk Explorer Side Panel – Gain heatmap-based insights into vulnerability distribution and team risk impact. 🚀 Stay ahead of vulnerabilities, optimize risk assessment, and enhance security efficiency with Phoenix Security’s latest features! 🚀
Alfonso Eusebio
Discover CVE-2025-30066 tj-actions/changed-files GitHub Action has been compromised, exposing secrets in CI/CD pipelines and posing a major software supply chain security risk. Attackers injected malicious code into all versions (V1–V45), repointing existing tags to a compromised commit that exfiltrated credentials via GitHub Actions logs. Immediate remediation is required—organizations must scan their repositories, rotate secrets, and replace the action to mitigate risk. Learn how Phoenix Security’s ASPM can automate threat detection and enhance GitHub Actions security.
Francesco Cipollone
Derek

Derek Fisher

Head of product security at a global fintech

Derek Fisher – Head of product security at a global fintech. Speaker, instructor, and author in application security.

Derek is an award winning author of a children’s book series in cybersecurity as well as the author of “The Application Security Handbook.” He is a university instructor at Temple University where he teaches software development security to undergraduate and graduate students. He is a speaker on topics in the cybersecurity space and has led teams, large and small, at organizations in the healthcare and financial industries. He has built and matured information security teams as well as implemented organizational information security strategies to reduce the organizations risk.

Derek got his start in the hardware engineering space where he learned about designing circuits and building assemblies for commercial and military applications. He later pursued a computer science degree in order to advance a career in software development. This is where Derek was introduced to cybersecurity and soon caught the bug. He found a mentor to help him grow in cybersecurity and then pursued a graduate degree in the subject.

Since then Derek has worked in the product security space as an architect and leader. He has led teams to deliver more secure software in organizations from multiple industries. His focus has been to raise the security awareness of the engineering organization while maintaining a practice of secure code development, delivery, and operations.

In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

Jeevan Singh

Jeevan Singh

Founder of Manicode Security

Jeevan Singh is the Director of Security Engineering at Rippling, with a background spanning various Engineering and Security leadership roles over the course of his career. He’s dedicated to the integration of security practices into software development, working to create a security-aware culture within organizations and imparting security best practices to the team.
In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

James

James Berthoty

Founder of Latio Tech

James Berthoty has over ten years of experience across product and security domains. He founded Latio Tech to help companies find the right security tools for their needs without vendor bias.

christophe

Christophe Parisel

Senior Cloud Security Architect

Senior Cloud Security Architect

Chris

Chris Romeo

Co-Founder
Security Journey

Chris Romeo is a leading voice and thinker in application security, threat modeling, and security champions and the CEO of Devici and General Partner at Kerr Ventures. Chris hosts the award-winning “Application Security Podcast,” “The Security Table,” and “The Threat Modeling Podcast” and is a highly rated industry speaker and trainer, featured at the RSA Conference, the AppSec Village @ DefCon, OWASP Global AppSec, ISC2 Security Congress, InfoSec World and All Day DevOps. Chris founded Security Journey, a security education company, leading to an exit in 2022. Chris was the Chief Security Advocate at Cisco, spreading security knowledge through education and champion programs. Chris has twenty-six years of security experience, holding positions across the gamut, including application security, security engineering, incident response, and various Executive roles. Chris holds the CISSP and CSSLP certifications.

jim

Jim Manico

Founder of Manicode Security

Jim Manico is the founder of Manicode Security, where he trains software developers on secure coding and security engineering. Jim is also the founder of Brakeman Security, Inc. and an investor/advisor for Signal Sciences. He is the author of Iron-Clad Java: Building Secure Web Applications (McGraw-Hill), a frequent speaker on secure software practices, and a member of the JavaOne Rockstar speaker community. Jim is also a volunteer for and former board member of the OWASP foundation.

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.

The IKIGAI concept
x  Powerful Protection for WordPress, from Shield Security
This Site Is Protected By
ShieldPRO