Abstract
This note introduces the Procurement Responsiveness Profile — a three-dimension framework for evaluating supply-chain component risk in connected-product procurement — and describes the methodology used to populate it from public vulnerability data. The framework lets engineering and procurement teams compare components on signal quality rather than on raw CVE count, which has known under-reporting bias.
The framework was developed from observation across Melina Security’s automotive, IoT, and robotics engagement portfolio in 2024-2025 and validated against publicly available disclosure data from the National Vulnerability Database (NVD), the Chinese National Vulnerability Database (CNVD), and major vendor product security incident response team (PSIRT) publications. The full quantified dataset is forthcoming; this note publishes the framework and the procurement implications, which are independently actionable today.
Intended audience: connected-product engineering teams, supply-chain risk owners, and procurement leads at hardware companies shipping into 2026-2027 product cycles.
1. The Procurement Responsiveness Profile
Before describing methodology, here is the framework the methodology is built to populate. The Procurement Responsiveness Profile evaluates a supply-chain component — silicon, RTOS, embedded-Linux distribution, networking stack, cryptographic library — across three dimensions:
| Dimension | What it measures | Why it matters |
|---|---|---|
| Disclosure Cadence | Frequency of vendor-coordinated CVE disclosures across the analysis window | A component with steady disclosure cadence has a functioning PSIRT process; absence of disclosures often reflects under-reporting, not absence of issues |
| Time-to-Fix | Median latency from public disclosure to fix availability | Procurement choice that minimises silicon-baked attack surface inherits a structurally faster remediation profile |
| Coverage Breadth | Proportion of supported product lines that receive fix coverage when a CVE is disclosed | Components with narrow coverage breadth produce hidden long-tail risk for fleets running older variants |
The procurement decision changes when components are compared on this profile rather than on raw CVE count. A component with 12 CVEs disclosed over 18 months, fixed within 30 days median, with coverage across all supported product lines, is a healthier procurement choice than a component with zero public CVEs over the same window — because the second component’s silence usually indicates an immature disclosure process, not absence of vulnerability.
“Engineering teams asking us about supply-chain risk almost always start with the CVE count. That’s the wrong number. The PSIRT process behind the count is what determines how much exposure you inherit when you ship that component in your product.” — Tatiana K., CEO, Melina Security
2. Methodology
The analysis draws on three public data sources and one private observation set. Public: the National Vulnerability Database (NVD), the Chinese National Vulnerability Database (CNVD), and vendor PSIRT publications for vendors representing the major silicon, RTOS, and embedded-Linux categories in scope. Private: the Melina Security engagement portfolio across automotive, IoT, and robotics work in 2024-2025, used to qualitatively validate the public-data observations.
Inclusion criteria require that the affected component be plausibly present in shipped consumer or industrial IoT firmware. We exclude desktop-only operating systems, enterprise server software not commonly embedded, and academic proof-of-concept findings without confirmed shipped-product impact.
CWE category filtering retains the categories most relevant to embedded-firmware risk:
- Authentication weaknesses: CWE-287, CWE-798
- Credential management: CWE-256, CWE-522
- Input validation: CWE-20, CWE-78
- Memory safety: CWE-119, CWE-120, CWE-125
- Cryptographic implementation: CWE-310, CWE-327
CVSS minimum threshold for the high-severity sub-analysis is 7.0; the broader corpus includes findings down to CVSS 4.0 where the affected component is reachable from a remote or local-network adversary in typical deployment posture.
The aggregation produces three views that feed the Procurement Responsiveness Profile: disclosure cadence by quarter, CWE distribution within affected-component class, and vendor disclosure-handling latency from public-disclosure date to fix-availability date.
Where a public-data observation contradicts a pattern from engagement practice, we flag the divergence and discuss the most likely explanation — typically under-reporting bias in the public data for a particular category.
3. Three structural patterns the framework surfaces
The Procurement Responsiveness Profile is built to surface three patterns we observe across the engagement portfolio. The quantitative answers appear in the forthcoming dataset publication; the patterns themselves are publishable now because they are independently consistent with public disclosure data.
3.1 The disclosure-source shift
Over 2024-2025, the proportion of IoT-component vulnerabilities first disclosed through coordinated-vendor channels has grown relative to the proportion first disclosed through external-researcher channels. The shift is positive for ecosystem health but changes how operators detect and respond — fleet-side vulnerability response increasingly depends on vendor PSIRT subscription rather than on external CVE monitoring of NVD or CNVD.
Operational implication for procurement: a component vendor without a PSIRT mailing list is increasingly a hidden-risk choice, because operators will not learn about disclosed vulnerabilities through the public channels.
3.2 The authentication-class concentration
Authentication and credential-handling weaknesses (CWE-287, CWE-798, CWE-256, CWE-522) are over-represented in shipped firmware relative to their share of the broader software-vulnerability population. This concentration is not a 2026 phenomenon — it has been observed in IoT corpora for at least a decade.
The methodology question is whether the relative proportion is moving in the right direction as the industry matures. Across our 2024-2025 IoT engagement portfolio, the authentication-class concentration remained dominant in shipped firmware even at vendors with active product security programs — suggesting the structural drivers (default credentials, weak provisioning flows, identity-handling shortcuts during development) are not yet addressed at the methodology level for most product organisations.
3.3 The remediation-pace divergence
Findings affecting silicon-baked components — secrets in mask ROM, hardware-rooted credentials, fixed key material in OTP or eFuses — remediate materially slower than findings affecting OTA-updatable firmware. This is the framework’s most consequential procurement signal because the gap compounds over a product lifecycle.
“When a customer asks why we recommend post-shipment-rotatable credentials even at modest implementation cost, the answer is silicon-baked findings remediate on the timeline of the next chip respin. That’s not a security trade-off — that’s a business risk that should sit on the procurement spreadsheet.” — Tatiana K., CEO, Melina Security
The Procurement Responsiveness Profile’s Time-to-Fix dimension captures this gap directly: components evaluated on a silicon-baked attack surface produce a substantially longer median time-to-fix than otherwise comparable OTA-updatable components.
4. Applying the framework — implications for procurement and architecture
The Procurement Responsiveness Profile translates into concrete guidance for connected-product organisations today, independent of the forthcoming dataset.
For procurement teams selecting supply-chain components
The most actionable signal is not historical CVE count but the responsiveness profile. A component with a steady CVE-disclosure cadence and rapid fix-availability is a healthier procurement choice than a component with no public CVE history and an unclear PSIRT process. The absence of public CVEs frequently reflects under-reporting rather than absence of issues.
Concrete procurement checklist:
- Is there a documented PSIRT contact and a published disclosure policy?
- What is the median time from public disclosure to fix availability across the past 18 months of CVEs?
- Is fix coverage applied across all supported product lines, or only to the active development branch?
- Does the vendor publish an SBOM at first ship?
- Is there a vendor mailing list or RSS feed for advisories?
A component that fails three or more of these checks is a high-risk procurement choice regardless of CVE count.
For product architecture decisions
The remediation-pace divergence argues for architectural choices that minimise silicon-baked attack surface. Secrets in silicon-managed key storage that cannot be rotated post-shipment carry a disproportionate share of the longest-remediation risk. Where the architecture allows, post-shipment-rotatable credentials are preferable to silicon-baked credentials even at modest implementation cost.
This implies specific architecture decisions:
- Provisioning flows that derive long-lived secrets at first-boot from a rotatable factory-provisioned seed, rather than embedding the long-lived secrets at silicon time
- Cryptographic key storage in flash with secure-boot-anchored access control, rather than in OTP / eFuses
- Separable credential domains so a compromise of one credential class does not require chip respin to remediate
For deployed-fleet operators
The disclosure-source shift means operator-side vulnerability response increasingly depends on vendor advisory subscription rather than on external monitoring. Operators should ensure they are on vendor PSIRT mailing lists for every shipped supply-chain component, and that the fleet inventory maps deployed firmware versions to component versions disclosed in advisories.
The fleet inventory data structure that produces fast remediation in practice is the inverse of the SBOM: not “what is in our product” but “which deployed devices contain this component version.” Most product organisations have the first; few have built the second.
5. Recommendations by role
For connected-product manufacturers: maintain a complete SBOM at build time (not scan time), integrate it into vendor PSIRT subscription, and budget post-launch security-update capacity that handles silicon-vendor disclosure latency. Architectural decisions that reduce silicon-baked attack surface compound favourably across the product lifecycle.
For connected-product operators: subscribe to vendor PSIRT advisories for every shipped supply-chain component, maintain a fleet inventory that maps deployed firmware versions to component versions, and ensure incident-response capacity covers vendor-side disclosure as well as field-discovered issues.
For standards bodies and regulators: the disclosure-source shift toward coordinated-vendor disclosure is a positive trend worth supporting through clearer expectations around vendor timelines. The EU Cyber Resilience Act, US Cyber Trust Mark, and UK PSTI provide useful frameworks but converge on vendor obligations more than on supply-chain transparency. Standards work that requires manufacturer SBOM publication at first ship would compound the coordinated-vendor disclosure trend.
6. Methodology limitations
The public-data corpus carries known biases that the analysis cannot fully correct. Under-reporting bias varies by component category: cryptographic libraries and popular embedded-Linux distributions are heavily researched and have correspondingly high CVE counts that overstate their risk relative to less-researched categories. Regional reporting variation produces additional noise: NVD coverage is strongest for components shipped by US and European vendors, while CNVD coverage is strongest for components shipped by Chinese vendors. Cross-database overlap is incomplete.
Vendor-publication selection effects affect the responsiveness analysis. Vendors with mature PSIRT processes publish more advisories and produce a tighter responsiveness signal; vendors with informal disclosure handling produce sparser data that may understate both their CVE count and their average response time.
Engagement-portfolio observations validate the qualitative direction of the public-data findings but cannot validate quantitative claims, because the engagement portfolio is non-random with respect to the underlying universe of deployed connected products.
7. Frequently asked questions
Why publish the framework before the dataset?
The Procurement Responsiveness Profile is independently useful for procurement decisions today, before any specific quantitative findings. Teams making a vendor selection this quarter need a decision frame; the dataset adds calibration but does not change the structure of the decision.
How does the Procurement Responsiveness Profile differ from a vendor scorecard?
A vendor scorecard rates a vendor across many dimensions (technical capability, support quality, commercial terms). The Procurement Responsiveness Profile rates a component across three dimensions specific to security risk. A vendor with strong commercial fit can still ship a component with a weak responsiveness profile, and procurement decisions should evaluate both.
Does this framework apply to open-source components?
Yes — open-source components have PSIRT-equivalent processes maintained by the project (Linux kernel security team, OpenSSL security policy, etc.). The framework’s three dimensions apply directly: how often does the project publish security advisories, how quickly do they patch, and across how many supported branches does the fix land.
What about components with no historical CVEs?
Treat zero historical CVEs as a yellow flag, not a green one. The most common cause of zero historical CVEs in IoT components is under-reporting, not absence of vulnerability. Look for the disclosure-policy signals (published PSIRT contact, advisory mailing list, SBOM publication) before treating a CVE-silent component as low-risk.
Is the dataset publication going to change the framework?
No. The dataset will quantify the patterns the framework is built to surface — disclosure cadence by component class, median Time-to-Fix by component category, Coverage Breadth distribution. The framework structure is stable; the dataset provides calibration values for each dimension.
Related
- Service: IoT & Embedded Security
- Solution: Supply-Chain Security
- Glossary: SBOM · CWE · CVE · CVSS
- Case study: Prompt-injection and tool-misuse in a RAG-backed assistant — companion analytical frame for AI-system supply chain