Application Management and Patching

CVE, Then and Now: Overview and Practical Integration with Application Workspace 

Topics: Application Management and Patching, Security and Compliance

History of CVE Program 

In January 1999, MITRE researchers David E. Mann and Steven M. Christey presented “Towards a Common Enumeration of Vulnerabilities” at Purdue University’s 2nd Workshop on Research with Security Vulnerability Databases. The paper outlined the need for a unified reference list for security vulnerabilities, independent of vendors, that would address the challenge caused by different naming conventions across various security tools and databases. Their concept became the foundation of today’s CVE (Common Vulnerabilities and Exposures) Program. 

CVE was not the first vulnerability database. There were other databases which were proprietary or vendor-specific, each with its own format, naming convention, and limited accessibility. This fragmented landscape made cross-referencing vulnerabilities between sources extremely difficult. Security teams had to compare findings from many vendor tools by hand, a process prone to error, overlap, and missed issues. 

CVE List 

The public CVE List launched in September 1999. It contains entries for publicly disclosed computer security vulnerabilities and exposures, each assigned a unique ID and complying with a standardized format. 

Users can search the CVE website or download the list as a JSON file. 

Typical fields include a brief description, affected versions, related CWE, CVSS severity score, any CISA KEV notes, and links to technical details, exploits, or patches. Details often remain private until a vendor releases a fix. 

CVE Numbering Authorities 

CNA stands for CVE Numbering Authorities (CNAs). CNAs include open-source projects, research groups, software vendors, bug-bounty platforms, and other coordinators authorized to assign new CVE IDs. 

The April 2025 Funding Issue 

The CVE Program falls under the Homeland Security Systems Engineering and Development Institute (HSSEDI), which is a Federally Funded Research and Development Center (FFRDC) operated by MITRE under the sponsorship of the U.S. Department of Homeland Security (DHS). As a result, the program relies on a single government funding source. 

That single-source funding model made headlines in April 2025. An internal MITRE letter revealed that DHS and CISA would not renew MITRE’s management contract. The contract was set to expire on April 16, 2025.  

Shortly after, CISA granted an 11-month contract extension. It’s still unclear whether cost-cutting at the federal level drove the decision. 

CVE 2.0 

Although the program’s future looked uncertain, the community responded quickly. Following this event, the CVE Foundation was established by CVE Board members and stakeholders. It is a non-profit organization aimed at securing the program’s independence and making it evolve once again since the 2016 CVE program crisis. 

Closing the Vulnerability Gap with Application Workspace   

Embedding CVE data in an app-management tool lets SysAdmins check vulnerabilities without leaving the packaging or patching workspace. This is the case of Recast Software’s Application Workspace. With the Setup Store connector—Recast’s curated catalog for Windows and macOS—teams get release-note links, product pages, Recast KB articles, virus-scan scores, and any related CVE reports in one view: 


This context helps teams gauge risk, then prioritize patches and remediation using up-to-date CVE scores and details. 

The CVE program may be evolving, but the job of keeping endpoints safe never slows. By weaving live CVE data straight into Application Workspace, Recast Software turns every package update into a security decision point—no extra tabs, no manual cross-checks. SysAdmins can see a risk score, click the KB article, and push the fix before the next vulnerability scan even runs. That’s how modern app management closes the gap between “known issue” and “patched device.” 

Further reading:

Back to Top