KRIs for the products you ship

When a vulnerability lands in a product you have shipped to thousands of customers, the clock starts immediately and it is not your clock. Your customers are exposed until you ship a fix, and they cannot do anything about it until you do. That is the fact that makes product security a distinct domain: the people who bear the consequence of your security posture are not on your payroll. Your patch timeline becomes their patch timeline. Your disclosure decision becomes their incident.

This is the line that separates product security from application security, and the two get conflated constantly. Application security covers the internal software development lifecycle: the code review, SAST, secrets scanning, and pipeline controls that protect the systems and operational software your own teams run. Product security covers what you ship out the door, the APIs, binaries, containers, and connected systems your customers deploy. A vulnerability in an internal HR app is an operational problem you can patch on your own schedule. The same class of bug in a product you have sold is a liability, a regulatory obligation, and a trust event happening across every customer at once. If you want the internal SDLC side, read the companion guide on KRIs for application security; this guide is about the products themselves.

These KRIs matter most for SaaS companies, software vendors, IoT manufacturers, and anyone shipping software as a product rather than running it internally. The eight signals below cover how fast you patch for customers, whether researchers can reach you, what your CVE history says about your testing, what you are shipping inside your dependencies, and whether you can prove tenant isolation holds. If you are standing up measurement from scratch, the guide to building a KRI program covers sequencing and ownership, and the KRI reference library holds the consolidated catalog with thresholds mapped to CIS Controls.

KRI inventory

Eight indicators, each with what to measure, why it matters, where the data lives, how to calculate it, and green / amber / red thresholds you can put in a policy. The thresholds here track the source intent; weight them against your own product and regulatory exposure using the broader reference library.

1. Customer-facing vulnerability mean time to patch (MTTP)

What to measure. Average number of days from vulnerability discovery (internal detection or responsible disclosure) to a patch or remediation being available to customers, measured across all product releases in the trailing 90 days.

Why it matters. Customers rely on you to ship patches before adversaries exploit the vulnerabilities you have found. MTTP is the clearest signal of how responsive your security program is to the people running your product, and to the auditors, regulators, and insurers who ask. For regulated verticals like healthcare, financial services, and critical infrastructure, patch availability timelines feed directly into compliance obligations.

Derivation sources:

• Vulnerability tracking system (internal Jira, GitHub Issues, or a dedicated VDP platform): finding creation_date vs. patch release_date
• Product release management: release dates for security patch versions. Product vulnerability scans from Qualys VMDR or Tenable.io can feed discovery dates
• Bug bounty platform (HackerOne, Bugcrowd, Intigriti): researcher submission dates vs. patch availability confirmation
• CVE database: CVE assignment date vs. advisory publication date for publicly disclosed vulnerabilities

How to calculate. For each security fix shipped, take (patch_release_date) − (discovery_or_report_date). Average across the trailing 90-day period, then segment by severity: critical, high, medium.

Status	Criteria
Green	Critical MTTP <15 days; high <30 days; defined SLAs published in security policy
Amber	Critical 15–30 days; high 30–60 days
Red	Critical >30 days, or no defined customer-facing patch SLA

2. Vulnerability disclosure program (VDP) health

What to measure. Whether a formal vulnerability disclosure program exists, the current backlog of unaddressed researcher reports, mean time to triage (MTTT) for new submissions, and researcher acknowledgment rate.

Why it matters. A VDP gives legitimate researchers a channel to report vulnerabilities in your product before going public. Organizations without one get disclosed to anyway; they just lose the private notification window. Backlog and triage time tell you whether your VDP is functional or performative.

Derivation sources:

• Bug bounty / VDP platform (HackerOne, Bugcrowd, Intigriti, Cobalt): submission queue, triage status, resolution dates
• Email / form VDP (security@yourdomain.com): submission log and response tracking
• PSIRT (Product Security Incident Response Team) records: intake and tracking
• CVE Numbering Authority (CNA) process: CVE assignment timelines as a VDP output signal

How to calculate. Track four values: VDP exists (yes/no, binary but foundational); MTTT in hours from researcher submission to initial response; backlog count of open, untriaged submissions older than 7 days; and researcher acknowledgment rate as the percentage of valid reports acknowledged within the published SLA.

Status	Criteria
Green	VDP published and accessible; MTTT <48 hours; zero reports untriaged >7 days; acknowledgment rate >95%
Amber	VDP exists but MTTT 48–120 hours, or backlog growing
Red	No published VDP, or valid reports with no response >14 days

3. Product CVE disclosure rate and severity distribution

What to measure. Number of CVEs assigned to your products in the trailing 12 months, their severity distribution (critical/high/medium/low), and the ratio of self-discovered CVEs to externally reported CVEs.

Why it matters. Enterprise buyers evaluate CVE history when making purchasing decisions, and their security teams cite it during due diligence. A high proportion of externally-reported critical CVEs signals that your internal testing is not finding issues before customers or researchers do, which is a maturity signal in itself. The self-discovered versus reported ratio measures whether your own testing is ahead of external researchers.

Derivation sources:

• NVD (National Vulnerability Database): query by CPE (Common Platform Enumeration) for your product
• CVE.org: CVE list filtered to your organization as vendor
• Product changelog / release notes: security-related fixes cross-referenced with CVE assignments
• Bug bounty platform: externally reported valid vulnerabilities that received a CVE assignment

How to calculate. Take a trailing 12-month CVE count by severity. Compute the self-discovered ratio as (CVEs from internal testing) ÷ (total CVEs) × 100. Track patch lag as the time from CVE assignment to a patched version being available.

Status	Criteria (self-discovery ratio)
Green	>70% of CVEs discovered internally before external reports; severity distribution weighted to medium/low
Amber	40–69% self-discovered; critical CVEs primarily from external reports
Red	<40% self-discovered, or repeat critical CVEs in the same product component

4. Dependency vulnerability exposure in shipped products

What to measure. Number of known exploited or critical CVEs in third-party dependencies shipped as part of your product, where customers are running the vulnerable version.

Why it matters. When Log4Shell was disclosed, millions of products shipped Log4j as a dependency. Each vendor owed its customers a fast answer: identify exposure, ship a patch, communicate it. Customers running vulnerable versions of your product are exposed through no fault of their own. SBOM programs exist specifically to enable rapid impact assessment when a dependency vulnerability is disclosed.

Derivation sources:

• SBOM (generated via Syft, CycloneDX, or SPDX): component inventory per product version in production
• SCA tools (Snyk, Black Duck, OWASP Dependency-Check): vulnerability mapping against shipped component versions. Dependency findings surfaced through GitHub Advanced Security can feed this for code you build
• Product telemetry or license data: customer version distribution, which versions are actively deployed in production
• CISA KEV catalog: cross-reference shipped components against Known Exploited Vulnerabilities

How to calculate. Count current product versions with CISA KEV vulnerabilities in dependencies. Compute customer exposure rate as (customers on versions with known critical dependency CVEs) ÷ (total active installs) × 100.

Status	Criteria
Green	Zero current product versions with CISA KEV in dependencies; SBOM generated per release
Amber	Known critical CVEs in dependencies with a patch version available and customer migration in progress
Red	Critical or exploited CVEs in shipped dependencies with no patch available, or no SBOM and no dependency vulnerability tracking

5. Security feature adoption rate

What to measure. Percentage of customers (or customer accounts) with security features enabled, including MFA/SSO enforcement, audit logging, data encryption at rest, API key rotation, and role-based access controls, as available in your product.

Why it matters. You can ship excellent security features and still have customers who never turn them on. If a customer is breached through your product because they did not enable the MFA you offered, you share the reputational and potentially legal exposure. Adoption is a product security outcome, not just a product usage metric.

Derivation sources:

• Product telemetry / analytics platform (Mixpanel, Amplitude, Segment, LaunchDarkly): feature flag status per tenant
• SaaS application database: tenant configuration tables for security feature status
• Customer success platform (Gainsight, Totango): security feature enablement in customer health scores
• Support ticket system: security-related tickets as a lagging indicator of configuration problems

How to calculate. Per security feature, take (tenants with feature enabled) ÷ (total active tenants) × 100.

Status	Criteria (example: MFA enrollment in your product)
Green	>85% of customer accounts with MFA enabled, or enforcement options surfaced prominently
Amber	60–84%
Red	<60%, or product does not support MFA

6. Product penetration test recency and finding remediation

What to measure. Days since the last product-focused penetration test, and the percentage of critical and high findings from the most recent test that are remediated in the shipping codebase.

Why it matters. Product pen tests find issues in customer-facing functionality that automated scanning misses: business logic flaws, authorization bypasses, multi-tenant isolation failures. Enterprise buyers increasingly require evidence of annual penetration testing in vendor due diligence, SOC 2 and ISO 27001 expect it, and your customers’ CISOs ask for the report by name.

Derivation sources:

• Penetration test reports: most recent product or application pen test report date and finding inventory
• Finding tracking (Jira, PlexTrac): open vs. closed findings from the pen test, by severity
• Release history: which version was pen tested vs. current version (material changes since the test reduce the value of the certificate)
• Customer trust portal (Vanta, Drata trust page, manual attestation): pen test certificate dates published to customers

Status	Criteria
Green	Product pen test within 12 months; >90% of critical findings remediated; report available for customer due diligence
Amber	12–18 months, or significant product changes since last test, or findings with extended remediation timelines
Red	>18 months since product pen test, or critical findings from the last test unresolved in shipping code

7. Multi-tenant isolation assurance

What to measure. Test coverage rate for tenant isolation, the controls that prevent one customer’s data and functionality from being reachable by another customer, measured by automated and manual testing against isolation boundaries per release.

Why it matters. Multi-tenant isolation failures are among the most catastrophic product security incidents possible. They expose one customer’s data to another, create liability across your entire customer base, and are extremely hard to remediate after the fact because the root cause is usually architectural and requires significant rework. Early, systematic testing is the only control that actually works.

Derivation sources:

• Security test suite in CI/CD: test cases targeting cross-tenant data access (query manipulation, parameter tampering, IDOR tests)
• Penetration test reports: confirmation that multi-tenant isolation was in scope
• Application logs: cross-tenant access attempts (even unsuccessful ones are a signal)
• Code review records: data access layer review for tenant scoping

Status	Criteria
Green	Automated cross-tenant isolation tests in the CI/CD pipeline; manual testing in each major release; zero confirmed cross-tenant access in the last 12 months
Amber	Manual testing only, or last isolation test >12 months ago
Red	No explicit multi-tenant isolation testing, or confirmed cross-tenant data access in any customer environment

8. Security advisory and communication SLA

What to measure. Percentage of security advisories (notifications to customers about vulnerabilities in your product) published within your committed communication SLA, measured from CVE assignment or the internal decision to disclose.

Why it matters. How you communicate product vulnerabilities is a trust signal and, in some industries, a compliance requirement. A customer who first learns about a vulnerability in your product from a public NVD feed rather than from your advisory has good reason to question your program’s maturity. Advisory timing is the kind of signal that drifts quietly before it fails; the guide on reading drift in your KRIs covers how to catch that slide early.

Derivation sources:

• Security advisory records (public security page, PSIRT communications log): advisory publication dates
• CVE assignment dates: NVD / CVE.org for comparison against advisory publication
• Customer notification records: email or portal notification timestamps to affected customers
• Defined communication SLA in your security policy

Status	Criteria
Green	>95% of advisories published within committed SLA; proactive customer notification before NVD publication for critical issues
Amber	80–94% within SLA, or customers learning from NVD before the advisory on some issues
Red	<80% within SLA, or no published security advisory process

Deriving these KRIs by source type

Most of these signals already exist somewhere in your engineering, research, and customer tooling. The work is extraction and normalization, not new instrumentation.

From product engineering infrastructure (GitHub, CI/CD, Jira)

Vulnerability tickets carrying a security label or security component in Jira give you creation_date vs. the fix version’s release date, which is your MTTP. Grep test files for tenant isolation, authentication, and authorization tests to gauge isolation coverage. Security-tagged PRs give you an audit trail of fix merge dates and deployment to production. Confirm your branch strategy lets security fixes ship as hotfixes rather than waiting for the next feature release train. For the dependency side, GitHub Advanced Security surfaces vulnerable components in code you build.

From bug bounty and VDP platforms (HackerOne, Bugcrowd, Intigriti)

Submission metrics give you time to triage, time to bounty, and time to fix straight from the platform dashboards. Severity distribution, the share of critical and high reports versus medium and low, is a product security maturity signal. Researcher reputation matters: high-reputation reports carry more confidence than new accounts. HackerOne’s Response Efficiency Rating is a useful lagging indicator of VDP health.

From product telemetry and customer data

Query your product database for security feature flags (MFA enabled, SSO enforced, audit log active) by tenant to derive adoption. API authentication patterns, key age, rotation rate, and requests with invalid credentials, signal leaked keys. Login patterns like impossible travel, concurrent sessions, and failed authentication rates are early indicators of credential compromise in customer accounts.

From SCA and SBOM tooling

Syft plus Grype (syft packages <container-image> -o cyclonedx-json | grype) produces a component vulnerability report per shipped artifact. Snyk Container scans shipped images for CVEs in the base image and application layers. Attach a CycloneDX or SPDX SBOM to each release artifact in CI/CD and automate cross-referencing against the CISA KEV catalog whenever a new KEV entry is added. Product-level scanners such as Qualys VMDR and Tenable.io add deployed-version exposure data.

From customer trust and compliance platforms (Vanta, Drata)

The trust center displays the last pen test date, which is exactly what your customers see. SOC 2 control evidence ties pen test and vulnerability management controls to concrete artifacts. The volume of customer security questionnaires requesting pen test reports is itself a demand signal for program investment.

Product security sits next to a few adjacent domains worth wiring into the same picture. The application security KRIs cover the internal SDLC that feeds your products, AI security KRIs matter if your product ships models or LLM features, and security architecture KRIs cover the design-time controls (like tenant isolation boundaries) that these runtime signals validate.