Within the vulnerability ecosystem, the CVE project / vulnerability database is certainly the most well-known. Over the past 30 years many others have come and gone, and others are still around. Some of you will recognize SecurityFocus BID, Open Sourced Vulnerability Database (OSVDB), Secunia, VulnDB, OSV, and others. Started in 1997, there is another that has spent three decades flying under most security professional’s radar, despite being one of the best free databases for almost that entire time. If you didn’t know, Internet Security Systems (ISS) began the X-Force vulnerability database almost two full years before CVE began. Almost a year and a half before SecurityFocus BID. As of August / 2006, that database was managed by IBM after the acquisition of ISS. If you find yourself wondering why you haven’t heard of it until now, that is a real shame.
Even as someone who helps run VulnDB, when there is conflicting information around a disclosure I will check to see how X-Force handles it. Over the years we tend to agree on the handling of a given disclosure. That, to me, was a sign that they had a sharp team that was wise to the nuances of disclosures and aggregation of that information. Since my days volunteering on the OSVDB, I have maintained that the X-Force VDB (later X-Force Exchange or XFE) was the second best source of vulnerability intelligence. I maintained that right up until a year ago too. Why? I have actually been holding off on writing this blog for one full year, after starting to take notes on December 30, 2024 when I noticed that something had changed there.
Around December of last year, XFE seemed to only include vulnerabilities from CVE. Over the years they had consistently added non-CVE vulnerabilities to their database. That change was a red flag to me; why would they stop? Moving into January, 2025, XFE would go weeks at a time with no updates at all. That was certainly a handful of red flags and at the time I thought we might be seeing the total demise of XFE, following suit after Broadcom shuttered the SecurityFocus/Symantec BID VDB.
On January 10 another nail in the coffin appeared. By that point IBM, which is a CVE Numbering Authority (CNA), had issued advisories with their own assignments. However, their own disclosures did not appear in IBM XFE. What would cause that I wondered. By January 13 XFE had been updated to some degree, but only containing data from CVE still. February 20 and there was a burst of information added up to the 14th, but the gap between the 14th and 20th showed no new vulnerabilities.
In the world of vulnerability intelligence, you can’t go more than a couple days without providing that information. To go almost two months with sporadic updates, multi-week silence, and not publishing your own disclosures was a bad sign. By this point it was pretty clear to me that we were seeing the transformation into a “CVE with lipstick” database. That was discouraging. XFE was one of a very few VDBs that still operated in a broader context. Rather than operating solely in the CVE ecosystem, they operated in the vulnerability ecosystem.
By February 28, there was another two week silent period where XFE saw no public updates. What was there the prior months was nothing more than CVE data. Even the Activity Timeline made it clear that CVE automation was at the helm. I frequently saw ‘New Vulnerability’ without a structured title which deviated as historically all published vulns had an XFE curated title.
Even by April 5th, I still saw ‘New Vulnerability’ with a CVE identifier meaning they had not figured a way to auto-populate titles. Before you think “how could that be hard”, let me assure you it is extremely difficult. CVE does not deliver data in a structured format. You might say “But it is, check the JSON!” Sure, we will agree there is structured content but it isn’t structured data that we can use in automation. A considerable amount of CVE IDs, to this day, come with an unstructured blob (CVE description) and references. Even ones that come with structured ‘affected products’ cannot be trusted such as CVE-2025-67722 with a product of “security-reporting”, incorrectly taken from the GitHub repo name. To automate this requires too many exceptions and one-off rules to be created. No shade can be thrown at XFE for these titles if they moved to a CVE database, especially after more than 25 years of curated titles.
The next nail in the coffin was actually in the details of the April 5 observation. Looking past titles you could see that just about every entry said there was no remediation; even for the IBM vulnerabilities. I know quite well that when IBM’s PSIRT releases an advisory it almost always comes with remediation information, typically in the form of patch or upgrade depending on the product. Along with this, another thing caught my eye that seemed odd. When a 2025 and 2021 CVE ID both came in at the same time, each had the same non-description. So even legacy disclosures were getting the new treatment.
Not that I needed to observe more nails for this coffin, but another prime example could be found in February. Looking back, CVE-2023-52925 was technically disclosed on 2023-08-16 but it wasn’t perceived to be a security issue until late 2024 or early 2025. The actual CVE was published on 2025-02-05 with a typical crappy description that did not make it clear if it was a vulnerability or not. For more on that, see my Linux CNA blog. However, IBM’s entry (snapshot) couldn’t be described as “anemic” as it didn’t even include the CVE description.
On April 24, 2025, I reached out to the XFE asking for a “Statement as to the status of [the database]“, pointing out a degradation in updates and other unspecified changes after seeing another 10+ day stall in updates. Just a day later I received a reply saying that “the issue has been resolved” which is curious, since I hadn’t even outlined the many issues I had observed.
The final nail in the coffin, in my opinion, came a month ago when Scott Moore announced on LinkedIn he was ‘retiring’, at least from IBM, after a 28 year career there. During that time he was heavily involved in not only XFE, but establishing IBM as a CNA, and a lot more. At one point in the past he was actually assigning more CVE IDs than almost any other CNA which is impressive.
So here we are, when one of the OG modern VDBs has given up and gone the way of regurgitating CVE. It’s a tragedy in the world of vulnerability intelligence and I am sad to see XFE give up. I cannot say I blame them one bit though! The time and resources required to provide a proper vulnerability intelligence feed is bad enough, and now made worse by the continued decline of CVE (in quality) along with the severe uptick in CVE volume alone. Part of that is due to irresponsible CNAs like Linux as well as the continued problem of CVE farming that no one in the CVE ecosystem seems to want to reign in.
After 27 great years, I think that it is safe to wish XFE a chance to rest in peace. You will be missed by those of us who appreciate what you accomplished and the impressive tenure you had.
Leave a Reply