Obsolescence and Operational Risk

Software Composition Analysis does more than detect known vulnerabilities.

It also helps teams assess the operational risks carried by their dependencies: structural risks that carry no CVE today, but that silently erode the project’s long-term security posture.

Operational Risk is the measure of a project’s ability to react to future vulnerabilities.

Understanding the difference between a vulnerability and operational risk is fundamental:

• A Vulnerability is an Event: It is a specific flaw (CVE) discovered at a point in time. It is a “hole” in the defense that requires a reaction.
• Operational Risk is a State: It is the Loss of Maintainability. It does not appear in a security advisory and often accumulates silently without triggering alerts.

It represents the structural fragility of your foundation.

Obsolescence

Obsolescence is the primary driver of Operational Risk. It is the process by which a component transitions from a maintainable state to a brittle state.

This loss of maintainability occurs across two distinct dimensions:

Version Lag (Internal Risk)

Version Lag is the gap between the version you are using and the latest stable release.

This is essentially technical debt — the component is still supported, but your project has drifted too far from the current standard.

The further you lag, the harder it becomes to apply security patches without breaking functionality.

Lifecycle End & Ecosystem Collapse (External Risk)

Lifecycle End & Ecosystem Collapse occurs when the component itself ceases to be a viable foundation, regardless of which version you use.

This manifests in three ways:

• End-of-Life (EOL): The vendor or maintainer has officially stopped providing updates and security patches.
• Functional Abandonment: The community has stopped maintaining the code.

Obsolescence vs Vulnerability

A vulnerability is something that happens to a component.

Obsolescence is the condition that determines what happens next, it is the precondition that shapes your ability to respond.

Operational Impact & Risk Assessment

Version Lag

Assessing maintainability loss requires a different approach for each dimension. Version Lag applies to both COTS and OSS components.

Thales projects should determine the obsolescence threshold of a component by evaluating several indicators.

Teams could utilize the following frameworks to evaluate their dependencies:

Black Duck version risk

Black Duck evaluates operational risk by aggregating two dimensions, activity and version into a single score:

• Version age: how long since the current version was released
• Version delta: how many newer versions exist since the one in use
• Community activity: number of commits and contributors over the last 12 months

Understanding Operational Risk in Black Duck

JFrog Xray version risk

Xray calculates operational risk severity by combining multiple independent criteria into an effective risk level:

• EOL status: whether the component has officially reached end of life
• Version age: number of months since the current version was released
• Version delta: number of newer stable versions available since the one in use
• Release cadence: frequency of releases as an indicator of project health

Understanding Operational Risk in JFrog Xray

Practical Application

Both frameworks converge on the same core signals version age and version delta confirming that these are reliable, tool-agnostic indicators of potential lag.

That means that a component version that is significantly older than the latest stable release is generally a signal worth investigating.

The acceptable threshold varies depending on the component’s ecosystem, release cadence, and criticality — the tool frameworks above provide the necessary context to make that judgment.

Where official LTS status is available, it remains the strongest indicator of continued support and should be weighted accordingly.

Lifecycle End

Assessing Lifecycle End requires a different approach depending on the nature of the component.

COTS & Editor-Supported OSS

When a vendor or editor officially manages the component’s lifecycle, EoL and EoS dates are published and trackable. Always verify the official support status before drawing conclusions.

A useful reference for community-maintained but well-documented components is EndOfLife , which aggregates official EoL/EoS dates across a wide range of products.

Community-Only OSS

When no editor governs the lifecycle, there is no published EoL date. Assessment becomes qualitative and relies on observable signals:

• Release frequency: When was the last stable release? Has the cadence slowed significantly?
• Maintainer activity: Are pull requests being reviewed? Are security disclosures being acknowledged?
• Issue tracker health: Are critical issues accumulating without response?

Tool Selection

The Software Factory provides different levels of obsolescence detection capability.

Understanding what each tool covers allows project teams to assess which tool meets their operational risk requirements.

Comparison of Tool Capabilities

Why Blackduck for Obsolescence?

Among the available options, Black Duck provides the most comprehensive coverage for obsolescence assessment, addressing both dimensions — Version Lag and Lifecycle End & Ecosystem Collapse — across all four capability areas.

1. Operational Risk Metrics: It automatically calculates “Operational Risk” based on how many versions behind we are (directly supporting the Thales 2-year rule).
2. LTS Awareness: It distinguishes between a “stale” version and an “LTS” version, preventing false positives on supported older versions.
3. Community Health: It tracks the “Single Committer” and “Commit Activity” metrics, allowing Tech Leads to assess if a project is dying (Community Obsolescence) before a CVE even appears.