1. With MITRE losing funding and the limitations of the NVD exposed, what should security teams understand about the reliability of traditional vulnerability scoring systems?
Well, first it’s important to clarify that Mitre didn’t lose its funding in the end because CISA saved the day by extending Mitre’s funding for 11 months, which restored calm for many companies around the world. However, while the crisis was narrowly avoided, it highlighted the danger of over-relying on a single authority for vulnerability management. Without CVEs, we risk losing a traditional metric that has underpinned global security coordination and response for many years.
In the world of security, companies should not rely on a scoring mechanism that uses a single data source because there is no perfect, single source of truth for CVEs. Mitre’s scoring system is an indicator of the potential risk of a vulnerability. Thus, security teams must verify, verify and then maybe trust when it comes to their own scoring systems. They should leverage mechanisms for assessing risk that use aggregated data from multiple vulnerability sources to balance risk and reduce the potential for exposure to disruptions due to a single false positive. Alternative identifiers like GHSA or PYSEC exist, but their coverage is fragmented and often ecosystem specific. In fact, our research shows 41% of PyPI vulnerabilities lack a PYSEC equivalent. These gaps make it challenging for organizations to assess risk and prioritize remediation.
Additionally, prioritizing remediation based on actual applicability and context within your unique environment is essential for helping teams reduce CVE fatigue and developer burn out.
Research shows that many CVEs rated as critical may not actually pose a critical risk. What does this mean for how teams should prioritize remediation?
Recent JFrog research has shown we continue to see a trend for over-inflated risk assessments in CVSS scores. The process of researching and validating an alert such as a CVE should involve evaluating their potential impact and applicability to the organization’s technology and deployment model. If it is determined to be applicable, the security team in conjunction with the business should develop appropriate remediation strategies. A critical success factor is ensuring that there are assigned teams and a set of vulnerability management tools. The tools need to provide a mechanism for the whole organization to keep track of these advisories, providing critical context and current tracking information. The goal of vulnerability prioritization is to ensure that high-risk vulnerabilities are addressed first, depending on where it is in your systems and whether that is internally or externally facing, allowing lower-risk vulnerabilities to be addressed later. Effective vulnerability prioritization requires a comprehensive understanding of the vulnerabilities present in an organization’s systems and applications. This involves identifying and assessing vulnerabilities based on their severity, exploitability, and potential impact. It also involves considering contextual factors such as asset information, threat intelligence, and business requirements. The prioritization process involves ranking vulnerabilities based on their risk level and assigning resources based on the level of risk. This ensures that vulnerabilities that carry the most business impact and risk are remediated first.
In the absence of comprehensive, centralized resources like MITRE, what responsibility do companies now hold in owning their vulnerability assessments?
As the future of the CVE program remains unclear, and vulnerability management tools continue to face additional challenges, it is up to each organization to gain a better understanding of what to expect from specific security solutions when entrusting them with managing the risks of their software development lifecycles.
With this in mind, organizations need to practice good cyber hygiene and institute best practices for vulnerability scanning and remediation with software supply chain tools. They should also look to vendor security advisories and get input from multiple vulnerability databases vs. a single source. Alternative identifiers like GHSA or PYSEC exist, but their coverage is fragmented and often ecosystem specific. Teams should actively incorporate data from vendor security advisories and CNAs for direct, product-specific updates, and turn to databases such as the GitHub Advisory Database, the Open Source Vulnerability (OSV) database, and the Exploit Prediction Scoring System (EPSS) for broader coverage, timely insights, and richer vulnerability context.
While these databases are not a replacement for the CVE Program, it is highly recommended to use them in conjunction with the CVE information and vulnerability management tools. This approach allows for cross-referencing information about vulnerabilities and staying informed about security risks that may not appear in the NVD.
2. How can organizations differentiate between CVEs that are exploitable and those that aren’t, especially as false positives and alert fatigue continue to rise?
Organizations can differentiate between exploitable CVEs and false positives by implementing a multifaceted approach. First, prioritize CVEs based on their CVSS (Common Vulnerability Scoring System) scores, focusing on high-severity vulnerabilities that pose immediate threats. Second, conduct contextual analysis to assess whether the vulnerability affects their specific environments, configurations, and software versions. Utilizing threat intelligence feeds and vulnerability databases helps verify if active exploits exist in the wild. Third, leverage automated tools that incorporate exploit validation, such as penetration testing or sandbox testing, to confirm exploitability. Additionally, establishing a structured triage process and integrating security orchestration, automation, and response (SOAR) platforms can reduce alert fatigue by filtering out low-risk or irrelevant alerts. Regularly reviewing and updating risk assessment strategies ensures that teams focus on vulnerabilities that present a clear, present danger, thus effectively managing false positives and streamlining remediation efforts.
3. What steps should security and DevOps teams take to assess risk at both the code and binary level?
Alarmingly, according to recent research on the state of software supply chain security, only 43% of IT professionals say their organization applies security scans at both the code and binary levels, leaving many organizations vulnerable to security threats only detectable at the binary level. This is down from 56% last year – a sign that teams still have huge blind spots when it comes to identifying and preventing software risk as early as possible.
To assess risk at both the code and binary levels, security and DevOps teams should implement continuous security practices. This begins with integrating static application security testing (SAST) during development to identify vulnerabilities early. Dynamic analysis and runtime security tools help detect issues in binaries during operation. Vetting dependencies and third-party libraries for known vulnerabilities, along with verifying binary integrity through digital signatures, is crucial. Conducting threat modeling helps identify attack vectors and prioritize risks based on impact. Security scans should be automated within CI/CD pipelines for real-time detection during deployment. Maintaining an updated inventory of code and binaries with version control ensures traceability and quick identification of unauthorized changes. Applying secure coding standards and automating security checks at each stage strengthen defenses. Regular updates and patches reduce exposure to known vulnerabilities. Establishing incident response plans ensures swift action when risks or breaches are identified. These comprehensive steps enable proactive risk management throughout the development lifecycle.
4. What impact is “this shift” having on developer workflows, and how can automation or AI help alleviate manual triage efforts?
Ultimately, the MITRE episode was a wake-up call, a diversified and well-funded vulnerability infrastructure is pivotal to modern security. The industry is still maturing in terms of how we identify and manage CVEs. Due to the sheer volume of CVEs discovered regularly, we’re moving from an era of alert fatigue to alert apathy and the communication conduct between security and developer teams is too damaged. There’s also the challenge of having a finite number of developers to fix things with a disproportionate number of CVEs being flagged daily. In fact, in 2024 security researchers globally disclosed nearly 33,000 new CVEs, an increase of 27% from 2023. This CVE deluge is having a noticeable impact on developer productivity, which makes it even more of an imperative for IT leaders to have the right solutions in place to help their developers with tools that help quickly find, fix, and fortify their systems.
5. What does the future of CVE severity assessment look like as we deal with more advanced threats and increasingly complex software supply chains?
To effectively identify and prioritize vulnerabilities that should be addressed, organizations can implement the following strategies:
Consume Vulnerability Data from Multiple Sources In days of uncertainty surrounding the CVE program, it’s more important than ever for organizations to consume vulnerability data from multiple sources and use security tools that support that. Relying solely on the CVE and NVD can leave critical gaps, especially during periods of backlog or delays. To mitigate this, teams should actively incorporate data from vendor security advisories and CNAs for direct, product-specific updates, and turn to databases such as the GitHub Advisory Database, the Open Source Vulnerability (OSV) database, and the Exploit Prediction Scoring System (EPSS) for broader coverage, timely insights, and richer vulnerability context.
Assess Applicability: In a landscape flooded with new vulnerabilities daily, the most critical step is filtering vulnerabilities based on applicability, meaning that the code and configuration necessary for exploitation is present in the scanned software. This can involve tools that support detecting CVE reachability and contextual analysis to determine if a vulnerability is reachable and exploitable in the context of a scanned software.
Rely on Severity Metrics: Utilize severity metrics like CVSS and Exploit Prediction Scoring System (EPSS) to evaluate the potential impact of vulnerabilities. Although these metrics should not stand as a single solution, they can guide organizations in prioritizing which vulnerabilities to remediate first.
6. What role can security vendors like JFrog play in helping organizations build more context-aware and intelligent remediation strategies?
As always, and regardless of the recent developments with MITRE and the CVE program, integrating security across the entire Software Development Lifecycle – from coding to production – is critical for building resilient and trustworthy systems. To identify vulnerabilities relevant to a company’s software infrastructure, organizations need to utilize Software Composition Analysis (SCA) tools and SAST tools to ensure their software products are thoroughly scanned and secured end to end. This is where vendors like JFrog and its suite of security development tools can help. JFrog security helps companies easily identify, prioritize and remediate vulnerabilities in open source software packages and binaries by performing continuous scanning of repositories, build packages, and container images throughout the development cycle. It also seamlessly integrates with developer tools, so developers can automate the protection of code with minimal impact on build times, so they can spend more time creating and less time remediating.
7. Do you think this shift in the MITRE/NVD ecosystem is a temporary disruption or a permanent turning point for the industry?
The panic surrounding MITRE’s potential cessation of CVE management stems from the critical role the CVE system plays in the application security landscape over the last 25 years.
The uncertainty regarding the renewal of MITRE’s contract with the U.S. government raised concerns about the continuity of CVE management and the threat of losing a trusted and standardized framework for identifying vulnerabilities. It also highlighted how closure of this program could lead to significant disruptions in how vulnerabilities are tracked and addressed in the industry, forcing organizations to find valid alternatives and strategies for vulnerability management. I think all companies will now reassess and take stock of their vulnerability assessment and execution strategy. It also reminds us that we need to allocate a certain amount of time to not just identifying CVEs but fixing them.
8. What’s your advice for CISOs who may be rethinking their vulnerability management strategy in light of these developments?
My advice to CISOs is to take this most recent MITRE development as a wakeup call to take stock of your vulnerability assessment strategy and execution. Organizations should not rely on a single data source. Using aggregated data from multiple vulnerability sources can help organizations maintain continuity and reduce exposure to disruptions in any single feed. We continue to find over-inflated risk assessments in CVSS scores, which appear to be an accelerating trend with CISA now contributing to enriching CVE records as the first Authorized Data Publishers. Furthermore, prioritizing remediation based on actual applicability and context within your unique environment is essential. We need to allocate a certain amount of time to fixing things – not just identifying them – and dig into the pile of data we’re sitting on about CVEs that have hit our orgs or the industry in general to help improve our security posture. If we’re not doing anything with the information we have to improve our security strategies, that’s a problem.
- About Paul Davis
- About JFrog Ltd.
Field CISO
JFrog Ltd. (Nasdaq: FROG) is on a mission to power the world with liquid software. We are replacing endless software updates with a single system of record that seamlessly delivers secure applications from developer to device. The JFrog Software Supply Chain Platform helps organisations build, manage, and distribute software quickly and securely, making applications available, traceable, and tamper-proof. Its integrated security features also help identify, protect, and remediate against threats and vulnerabilities. The Platform also brings ML models in line with all other software development processes, providing a single source of truth for all software components across Engineering, MLOps, DevOps, and DevSecOps teams so they can build and release AI applications faster, with minimal risk and less cost. JFrog’s hybrid, universal, multi-cloud platform is available as both self-hosted and SaaS services across major cloud service providers. Millions of users and 7K+ customers worldwide, including a majority of the Fortune 100, depend on JFrog solutions to securely embrace digital transformation. Once you leap forward, you won’t go back! Learn more at jfrog.com and follow us on X: @jfrog.

Techedge AI is a niche publication dedicated to keeping its audience at the forefront of the rapidly evolving AI technology landscape. With a sharp focus on emerging trends, groundbreaking innovations, and expert insights, we cover everything from C-suite interviews and industry news to in-depth articles, podcasts, press releases, and guest posts. Join us as we explore the AI technologies shaping tomorrow’s world.