Blogs

Blog

The Shift to Threat-Informed Prioritization: Operationalizing CISA BOD 26-04

In this post, we examine how CISA BOD 26-04 shifts the industry away from flat CVSS scoring and details how Flashpoint bridges the critical data gaps left by public vulnerability repositories.

SHARE THIS:

Flashpoint

June 15, 2026

Table Of Contents

Table of Contents

Understanding BOD 26-04

The Data Chellenge

How Flashpoint Solves the Prioritization Gap

Prioritize Vulnerability Risk Using Flashpoint

More

subscribe to our newsletter

With the recent issuance of Binding Operational Directive (BOD) 26-04, CISA has officially shifted federal policy away from static severity scores and flat patching timelines  toward threat-informed prioritization. The move reflects a reality security teams have grappled with for years: not all critical vulnerabilities post the same risk, and not all active vulnerabilities receive the highest CVSS scores. 

Traditional vulnerability management programs have often relied on severity-based patching models that force resource-constrained teams to focus on large volumes of high-scoring vulnerabilities. Yet research consistently shows that threat actors routinely exploit a broader range of weaknesses, including lower-scoring vulnerabilities on internet-facing assets, to gain initial access and move laterally through victim environments. 

While BOD 24-04 represents a significant step forward, there are still hidden challenges organizations will face as they adopt a risk-based approach. The operational reality is that executing a truly risk-based matrix validates what Flashpoint has maintained for years: effective vulnerability prioritization requires deep, contextual threat data. Unfortunately, the needed real-world metadata for this kind of context are simply not supported by public sources of vulnerability intelligence.

Understanding BOD 26-04

BOD 26-04 evaluates the urgency of a vulnerability by cross-referencing a security flaw against four distinct operational variables:

1. Asset Exposure: Is the asset publicly accessible via the internet?
2. Known Exploited Status (KEV): Is there verifiable evidence of active exploitation in the wild?
3. Exploit Automation: Can a threat actor completely automate the weaponization and delivery of the exploit?
4. Technical Impact: Does a successful exploit result in partial disruption or total compromise of the target system?

By analyzing these variables in tandem, organizations can tier their response and execute clear, defensible SLA metrics.

Risk Priority	Real-World Matrix Conditions	Required SLA & Operational Action
P1: Immediate Risk	In KEV + Publicly Exposed + Automatable + Total Impact	3 Days (Includes Mandatory Forensic Triage)
P2: Urgent Risk	In KEV + Publicly Exposed + (Either Non-Automatable OR Partial Impact)	7 Days
P3: Elevated Risk	In KEV + Internal / Non-Publicly Exposed Asset	14 Days
P4: Standard Risk	Not in KEV + Publicly Exposed + Automatable + Total Impact	30 Days
Deferred Risk	Not in KEV + Internal Asset OR Lower Technical Impact	Next Scheduled System Upgrade / Maintenance

According to CISA, the pilot testing of this model has shown that fewer than 1% of an organization’s typical vulnerability backlog requires urgent, immediate remediation, while over 60% can be safely deferred to standard system maintenance cycles. However, implementing this framework successfully requires access to granular, real-world data points that public sources of vulnerability intelligence simply do not support. 

“Speaking with security teams in the wake of this directive, it is clear that BOD 26-04 is a major paradigm shift. While the ability to safely defer more than half of your patch backlog is an invaluable efficiency gain for modern organizations, executing that strategy effectively requires ground-truth intelligence on exploit automation and adversary intent that public registries simply cannot deliver.”

Josh Lefkowitz, CEO and Co-founder at Flashpoint

The Data Challenge

To operationalize this model successfully, organizations will require a high-fidelity intelligence pipeline that combines comprehensive threat and vulnerability intelligence into clear, context-rich insights that support prioritization and decision making. You cannot confidently defer remediation without verifiable intelligence that proves the vulnerability lacks active exploit history or automation maturity.

Unfortunately, relying on public data feeds like the CVE database or the National Vulnerability Database (NVD) to fuel this matrix creates an immediate operational bottleneck. Public repositories have historically struggled under severe analysis backlogs, leading to processing delays and missing Common Platform Enumeration (CPE) data. Furthermore, public feeds are inherently reactive; they do not monitor illicit communities where exploit code is developed, nor do they track the real-time weaponization metrics needed to meet BOD 26-04’s tight 3-day or 7-day compliance window.

How Flashpoint Solves the Prioritization Gap

Flashpoint Vulnerability Intelligence bridges the gap between public data limitations and the requirements of real-world exposure management. Independently researched and enriched, Flashpoint provides the precise contextual signals required by the CISA BOD 26-04 matrix:

• Coverage across CVE and non-CVE vulnerabilities
• Continuous tracking of exploitation activity and adversary usage
• Context on exploit maturity and remediation
• Consistent enrichment that can be integrated into operational workflows
• Over 7,000 known exploited vulnerabilities (KEV)

By integrating Flashpoint’s continuous intelligence into operational workflows, security teams can automatically validate exposure, assess automation potential, and confidently claim the operational relief that risk-based prioritization promises.

“We are convinced by Flashpoint’s superior vulnerability coverage, timeliness in the updates, and long-term monitoring of exploits. We also really appreciate Flashpoint’s proprietary CVSS rating and classifications based on expert knowledge of the standard and practical use in the industry. Having all this curated information at your fingertips is a game changer.”

Vulnerability Manager, Telecommunications

Prioritize Vulnerability Risk Using Flashpoint

CISA’s BOD 26-04 represents a critical shift away from severity-based patching and toward defensive efficiency. However, the effectiveness of this model is entirely dependent on the fidelity of your threat data.

Without best-in-class comprehensive vulnerability intelligence, security teams will be forced back into reactive patching cycles. Request a demo to learn more how Flashpoint helps security teams move beyond the constraints of static scoring and align their vulnerability management workflows with actual risk.

The post The Shift to Threat-Informed Prioritization: Operationalizing CISA BOD 26-04 appeared first on Flashpoint.

Lawmakers in both houses of Congress are demanding answers from the U.S. Cybersecurity & Infrastructure Security Agency (CISA) after KrebsOnSecurity reported this week that a CISA contractor intentionally published AWS GovCloud keys and a vast trove of other agency secrets on a public GitHub account. The inquiry comes as CISA is still struggling to contain the breach and invalidate the leaked credentials.

On May 18, KrebsOnSecurity reported that a CISA contractor with administrative access to the agency’s code development platform had created a public GitHub profile called “Private-CISA” that included plaintext credentials to dozens of internal CISA systems. Experts who reviewed the exposed secrets said the commit logs for the code repository showed the CISA contractor disabled GitHub’s built-in protection against publishing sensitive credentials in public repos.

CISA acknowledged the leak but has not responded to questions about the duration of the data exposure. However, experts who reviewed the now-defunct Private-CISA archive said it was originally created in November 2025, and that it exhibits a pattern consistent with an individual operator using the repository as a working scratchpad or synchronization mechanism rather than a curated project repository.

In a written statement, CISA said “there is no indication that any sensitive data was compromised as a result of the incident.” But in a May 19 a letter (PDF) to CISA’s Acting Director Nick Andersen, Sen. Maggie Hassan (D-NH) said the credential leak raises serious questions about how such a security lapse could occur at the very agency charged with helping to prevent cyber breaches.

“This reporting raises serious concerns regarding CISA’s internal policies and procedures at a time of significant cybersecurity threats against U.S. critical infrastructure,” Sen. Hassan wrote.

A May 19 letter from Sen. Margaret Hassan (D-NH) to the acting director of CISA demanded answers to a dozen questions about the breach.

Sen. Hassan noted that the incident occurred against the backdrop of major disruptions internally at CISA, which lost more than a third of it workforce and almost all of its senior leaders after the Trump administration forced a series of early retirements, buyouts, and resignations across the agency’s various divisions.

Rep. Bennie Thompson (D-MS), the ranking member on the House Homeland Security Committee, echoed the senator’s concerns.

“We are concerned that this incident reflects a diminished security culture and/or an inability for CISA to adequately manage its contract support,” Thompson wrote in a May 19 letter to the acting CISA chief that was co-signed by Rep. Delia Ramirez (D-Ill), the ranking member of the panel’s Subcommittee on Cybersecurity and Infrastructure Protection. “It’s no secret that our adversaries — like China, Russia, and Iran — seek to gain access to and persistence on federal networks. The files contained in the ‘Private-CISA’ repository provided the information, access, and roadmap to do just that.”

KrebsOnSecurity has learned that more a week after CISA was first notified of the data leak by the security firm GitGuardian, the agency is still working to invalidate and replace many of the exposed keys and secrets.

On May 20, KrebsOnSecurity heard from Dylan Ayrey, the creator of TruffleHog, an open-source tool for discovering private keys and other secrets buried in code hosted at GitHub and other public platforms. Ayrey said CISA still hadn’t invalidated an RSA private key exposed in the Private-CISA repo that granted access to a GitHub app which is owned by the CISA enterprise account and installed on the CISA-IT GitHub organization with full access to all code repositories.

“An attacker with this key can read source code from every repository in the CISA-IT organization, including private repos, register rogue self-hosted runners to hijack CI/CD pipelines and access repository secrets, and modify repository admin settings including branch protection rules, webhooks, and deploy keys,” Ayrey told KrebsOnSecurity. CI/CD stands for Continuous Integration and Continuous Delivery, and it refers to a set of practices used to automate the building, testing and deployment of software.

KrebsOnSecurity notified CISA about Ayrey’s findings on May 20. Ayrey said CISA appears to have invalidated the exposed RSA private key sometime after that notification. But he noted that CISA still hasn’t rotated leaked credentials tied to other critical security technologies that are deployed across the agency’s technology portfolio (KrebsOnSecurity is not naming those technologies publicly for the time being).

CISA responded with a brief written statement in response to questions about Ayrey’s findings, saying “CISA is actively responding and coordinating with the appropriate parties and vendors to ensure any identified leaked credentials are rotated and rendered invalid and will continue to take appropriate steps to protect the security of our systems.”

Ayrey said his company Truffle Security monitors GitHub and a number of other code platforms for exposed keys, and attempts to alert affected accounts to the sensitive data exposure(s). They can do this easily on GitHub because the platform publishes a live feed which includes a record of all commits and changes to public code repositories. But he said cybercriminal actors also monitor these public feeds, and are often quick to pounce on API or SSH keys that get inadvertently published in code commits.

The Private-CISA GitHub repo exposed dozens of plaintext credentials to important CISA GovCloud resources.

In practical terms, it is likely that cybercrime groups or foreign adversaries also noticed the publication of these CISA secrets, the most egregious of which appears to have happened in late April 2026, Ayrey said.

“We monitor that firehose of data for keys, and we have tools to try to figure out whose they are,” he said. “We have evidence attackers monitor that firehose as well. Anyone monitoring GitHub events could be sitting on this information.”

James Wilson, the enterprise technology editor for the Risky Business security podcast, said organizations using GitHub to manage code projects can set top-down policies that prevent employees from disabling GitHub’s protections against publishing secret keys and credentials. But Wilson’s co-host Adam Boileau said it’s not clear that any technology could stop employees from opening their own personal GitHub account and using it to store sensitive and proprietary information.

“Ultimately, this is a thing you can’t solve with a technical control,” Boileau said on this week’s podcast. “This is a human problem where you’ve hired a contractor to do this work and they have decided of their own volition to use GitHub to synchronize content from a work machine to a home machine. I don’t know what technical controls you could put in place given that this is being done presumably outside of anything CISA managed or even had visibility on.”

Update, 3:05 p.m. ET: Added statement from CISA. Corrected a date in the story (Truffle Security said it found the repo gained some of its most sensitive secrets in late April 2026, not 2025).

In a Public Service Announcement (PSA) the Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) warn the public about ongoing Russian-linked phishing campaigns that aim to gain access to messaging accounts.

Earlier this month we wrote about a large‑scale phishing campaign aimed at hijacking Signal and WhatsApp accounts belonging to senior officials, military personnel, civil servants, and journalists.

Now the FBI and CISA have joined European intelligence services in warning that the same tactics are being used in a broader campaign targeting these commercial messaging apps. The goal is not to break end‑to‑end encryption, but to walk straight around it by stealing access to individual accounts.

In our previous article, we focused on warnings from the Dutch intelligence services AIVD and MIVD, which described how Russian state‑backed actors approached high‑value targets via Signal and WhatsApp, posing as “Signal Support”, “Signal Security Bot”, or similar. The PSA demonstrates how the same groups are now running global phishing campaigns against messaging app accounts, with evidence suggesting thousands of compromised accounts worldwide.

It’s important to reiterate that the attackers have not managed to break the apps’ end-to-end encryption. Instead, they are relying on social engineering to get a device added so they can eavesdrop on accounts.

The current targets include current and former US government officials, military staff, political figures, and journalists, but there is nothing to stop the same techniques being reused against businesses and everyday users.

So, while it’s tempting to dismiss this as a problem for diplomats and generals (and the agencies issuing these alerts do mention high‑profile targets first), the techniques scale very easily. Once playbooks like these are public, they tend to be copied by cybercriminals looking for new ways to steal money or accounts.

How to protect your accounts

As the PSA puts it:

“Phishing remains one of the most unsophisticated, yet effective means of cyber compromise, often rendering other protections irrelevant”

This calls asks for basic security measures:

• Treat unsolicited messages from “Support” inside apps as suspicious by default. Legitimate support for apps like Signal and WhatsApp does not ask you, in a chat message, to send back verification codes, PINs, or passwords.​ If you receive a warning about account problems, do not follow links in the message. Open the app’s settings directly or visit the official website through other means.
• Never share SMS verification codes or app PINs. SMS codes are there to prove that you control a phone number. Anyone who has the code can pretend to be you. App‑specific PINs or passcodes are there to protect account changes. Giving them away is like handing over the keys to your account. Consider anyone asking for them to be a scammer.
• Be careful what you discuss and with whom. Both the Dutch and US advisories remind us that even with end‑to‑end encryption, some conversations are too sensitive for commercial chat apps.
• Use the extra security features these apps offer. Enable options like registration lock, registration PIN and device‑change alerts so that your account cannot be silently re‑registered without an extra secret. Store your PIN in a password manager instead of choosing something easy to guess or reusing a common code, to reduce the chance of social engineering or shoulder‑surfing.
• Another useful feature is disappearing messages. Short‑timer and disappearing messages reduce how much content is available if an attacker gets into a chat later, or if someone obtains long‑term access to a device or backup. They are not a complete solution, but they can limit the damage.

What to do if you think your account was hijacked

If you suspect an attacker has taken over your messaging account:

1. Try to re‑register your number in the app immediately to kick out other devices.
2. Revoke all linked devices and change any app‑specific PINs or lock codes.
3. Warn your contacts that someone may have impersonated you and ask them to treat recent messages with caution.
4. Review recent conversations for signs of data theft (for example, shared IDs, documents, or passwords that should now be considered exposed).
5. Report the incident to the app provider and, where appropriate, to national reporting centers such as the FBI’s Internet Crime Complaint Center (IC3) at ic3.gov or the relevant authority in your country.​

The sooner you act, the smaller the window in which attackers can exploit your account.

We don’t just report on phone security—we provide it

Cybersecurity risks should never spread beyond a headline. Keep threats off your mobile devices by downloading Malwarebytes for iOS, and Malwarebytes for Android today.

CISA is currently operating at roughly 38% capacity (888 out of 2,341 staff) due to the DHS shutdown that began February 14, 2026.

The post CISA Navigates DHS Shutdown With Reduced Staff appeared first on SecurityWeek.

Edge devices that are no longer supported have been targeted in attacks by state-sponsored hackers, the US says.

The post Organizations Urged to Replace Discontinued Edge Devices appeared first on SecurityWeek.

CISA updated 59 KEV entries in 2025 to specify that the vulnerabilities have been exploited in ransomware attacks.

The post Concerns Raised Over CISA’s Silent Ransomware Updates in KEV Catalog appeared first on SecurityWeek.

Recently, the Cybersecurity and Infrastructure Security Agency (CISA) added (along with two others) a vulnerability in ASUS Live Update to its catalog of Known Exploited Vulnerabilities (KEV).

The KEV catalog lists vulnerabilities that are known to be exploited in the wild and sets patch deadlines for Federal Civilian Executive Branch (FCEB) agencies. When CISA adds an issue to this list, it’s a strong signal that exploitation is real, ongoing, and urgent.

The ASUS Live Update Embedded Malicious Code vulnerability, tracked as CVE-2025-59374 (with a CVSS score of 9.3), affects Live Update, a utility commonly used to deliver firmware and software updates to ASUS devices.

This isn’t the first time ASUS Live Update has been linked to serious security incidents. In 2019, ASUS responded to media reports about attacks on the Live Update tool by advanced persistent threat (APT) groups, stating that:

“A small number of devices have been implanted with malicious code through a sophisticated attack on our Live Update servers in an attempt to target a very small and specific user group.”

Later investigations revealed that a sophisticated supply chain attack mounted in 2018, attributed to Chinese state-sponsored attackers, had inserted a backdoor into ASUS Live Update. The attack was particularly effective because that utility came preinstalled on most ASUS devices and was used to the automatically update BIOS, UEFI, drivers, and other components.

CISA now notes that the affected devices could be abused to perform unintended actions if certain conditions are met. Originally, the attackers reportedly targeted only around 600 specific devices, based on hashed MAC addresses hardcoded in various versions of the tool. This was despite the fact that millions of users may have downloaded the backdoored utility.

Support for the ASUS Live Update application has since been discontinued. The final intended version of ASUS Live Update was 3.6.15, but it will continue to provide software updates. This is likely why a CVE was assigned and why the vulnerability was added to the KEV catalog. There was no official “why now” statement from ASUS, MITRE, or CISA, but the timing aligns with a legacy, end-of-support product being reclassified as a vulnerability with confirmed active exploitation.

What do ASUS users need to do?

First of all, make sure you’re running a clean version of the utility. ASUS urges users to update to version 3.6.8 or later to address known security issues.

• Right-click the ASUS Live Update icon at the bottom-right corner of your Windows screen
• Click About to see the version information as the shown in the picture below.
  
• If you are on an older version, open the program and click Check update immediately
• ASUS Live Update will automatically find the latest driver and utility.
• Click Install
• After updating, recheck and ensure it shows “No updates.”

Alternatively, you can download and install the latest version manually. ASUS’ own support article describes the only official way to get the current Live Update package:​

1. Go to the ASUS Official Website (asus.com)
2. Use the search box to find your exact model (e.g., UX580GD)
3. Open the product page and click Support → Driver & Tools
4. Select your operating system (e.g., Windows 10/11 64-bit).​
5. In the Utilities section, locate ASUS Live Update and click Download

This is as close as we could get you to a “direct” official download. The URL is different for every model and ASUS does not provide a central Live Update installer directory. While this makes it harder than it maybe should be, we do recommend using this official download. Given the history of supply chain abuse involving this tool, downloading it from third-party sources is a risk not worth taking.

We don’t just report on threats—we remove them

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.