User Story: Product Architect – Energy Sector Software #14
Description
In the form of: "As a role performing task, I struggle with problem because reason."
As a product architect for a software package serving the energy sector, performing risk assessment and vulnerability management to meet industry and regulatory requirements, I struggle with using CVE data to reliably assess and communicate software risk because the information in CVE records is incomplete, poorly correlated to real-world product names, and inconsistent with vendor advisories—forcing us to rely on manual outreach and custom scraping to verify whether our customers are affected.
Context
The energy sector operates under strict regulatory oversight and depends on reliable, timely information about vulnerabilities and vendor attestations. Our product’s mission is to help energy customers identify when they are at risk by performing a seven-step risk assessment that includes vendor data, vulnerability intelligence, and compliance with federal requirements such as OMB Memorandum M-22-18, “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices.”
OMB M-22-18 requires federal agencies to use only software from producers who attest to following NIST’s Secure Software Development Framework (SSDF) and related practices, ensuring that software is developed securely and can be trusted. As a software provider serving energy customers that operate under similar compliance expectations, we must also ensure that our product and its components meet these attestation requirements.
However, current vulnerability data sources, particularly the CVE List and NVD, lack the accuracy, correlation, and structure needed to support this work at scale.
Problem 1: CVE Data Is Unreliable and Poorly Correlated to Real-World Products
Our ability to assess risk depends heavily on CVE data, yet the records often fail to align with the actual product names, versions, and vendor contexts that our customers recognize. The CPE strings used in CVE records are cryptic and inconsistently applied, which makes it difficult to determine whether a vulnerability applies to a specific product in the field. CVE data also rarely include vendor attestations or clear indicators of affected configurations, leaving us uncertain about real-world impact.
Because the CVE records do not correlate reliably to customer environments, we must manually verify each vulnerability by reaching out to vendors or scraping their advisories for confirmation. This manual process is slow, error-prone, and undermines automation. It also makes it harder for us to deliver timely and actionable guidance to our customers, many of whom operate critical systems where delays or inaccuracies can have significant consequences.
Problem 2: Difficulty Meeting Regulatory Attestation Requirements (OMB M-22-18)
Software manufacturers are the only ones who truly know whether their products are affected by vulnerabilities, as demonstrated by the log4j case. We cannot rely solely on public CVE or NVD data and must reach out to each vendor to obtain attestation that their product is or is not affected. OMB M-22-18 requires software producers to provide attestations for use by federal agencies, but there is little standardization. Vendor responses are inconsistent, often delivered in proprietary formats, and not machine-readable. This makes automation and compliance verification time-consuming and difficult.
Problem 3: CVSS Scores Do Not Reflect Energy Sector Risk Context
The CVSS scores included in most CVE records are often subjective and fail to account for environmental realities specific to the energy sector. Critical infrastructure systems have different exposure levels, segmentation requirements, and operational constraints than enterprise IT environments. A vulnerability that appears high risk according to CVSS may pose minimal real-world threat in a segmented control system, while a lower-scored issue could have catastrophic consequences if it affects critical operational technology. As a result, CVSS data cannot be relied upon to prioritize remediation or risk management within the energy context.
Problem 4: Volume of CVE Data Makes Automation Essential but Difficult
The number of new vulnerabilities disclosed each day makes manual review impossible. There are over 100 new CVEs per day and must rely on automation to stay ahead. However, the inconsistent structure and poor data quality of CVE records make automation unreliable. Many records are incomplete, inconsistent, or delayed, forcing human review to confirm details. Without consistent, machine-readable data that maps clearly to vendor and product names, automation pipelines cannot function effectively, which slows our ability to alert customers and respond to new threats in time.
Summary of Needs
To meet regulatory and customer expectations while maintaining timely protection, we need:
- Accurate and vendor-verified CVE data that aligns with real-world product names and identifiers.
- Machine-readable vendor advisories in standardized formats suitable for automation.
- Integration between CVE, SBOM, and attestation data to enable traceability from vulnerability to affected component to vendor confirmation.
- Risk scoring methods that reflect the operational realities of the energy sector.
- Data structures and publication standards that support full automation of vulnerability detection, correlation, and alerting.