Operational Risk

JFrog Security User Guide

ft:sourceType
Ftml

Beyond security vulnerabilities and compliance issues, operational risks in software components can impact system reliability, maintainability, and overall software quality. These risks arise from outdated, deprecated, or unmaintained dependencies that may no longer receive updates, security patches, or community support.

JFrog Xray provides Operational Risk Analysis, enabling organizations to detect and mitigate risks before they affect production environments. By identifying software components with end-of-life (EOL) statuses, deprecated libraries, and maintenance concerns, teams can make informed decisions to maintain software stability and long-term viability.

What is Operational Risk in Software?

Operational risk refers to non-security-related issues that can affect a software component’s performance, reliability, or maintainability.

Common operational risks include:

  • End-of-Life (EOL) Software – Components that no longer receive updates or security patches.
  • Deprecated Dependencies – Libraries marked as obsolete or replaced by newer versions.
  • Unmaintained Open-Source Projects – Software that hasn’t been updated for a long period, increasing the risk of compatibility issues.
  • High-Impact Component Updates – Major version changes that introduce breaking changes or API modifications.
  • Abandoned Projects – Open-source components with no active contributors or maintainers.

How Xray Detects Operational Risks

Xray continuously monitors software components in repositories, builds, and release bundles, identifying key operational risks based on:

  • Version Stability – Detects if a component hasn’t been updated for an extended period.
  • End-of-Life Status – Flags software that has reached EOL and no longer receives support.
  • Community and Maintenance Health – Analyzes activity levels of open-source maintainers.
  • API and Compatibility Changes – Identifies major version changes that may introduce breaking updates.
  • License Status Changes – Notifies teams when license modifications impact compliance.

Operational Risk Workflow in Xray

  1. Create an Operational Risk Policy.
  2. Attach Policy to Watch.
  3. View Operational Risk Data in the Xray > Scans List.
  4. View Operational Risk violations generated based on the Policy rules you set

Mitigating Operational Risks with Xray

1. Monitor Dependencies Continuously

  • Apply Operational Risk Policies to repositories and builds.
  • Detect outdated and deprecated dependencies before they impact production.

2. Enforce Governance in CI/CD Pipelines

  • Configure Xray to fail builds if they contain high-risk operational components.
  • Require dependency reviews before promoting artifacts.

3. Plan for End-of-Life Transitions

  • Track EOL software and migrate to actively maintained alternatives.
  • Avoid dependencies that lack long-term maintenance support.

4. Establish a Risk Management Strategy

  • Regularly audit software dependencies for compatibility and lifecycle health.
  • Work with open-source communities to assess long-term viability.

How Xray Determines Operational Risk Severity

Xray calculates the Operational Risk as High, Medium, Low, and None (no known risk) using the following criteria. For information on how Xray calculates operational risk effective severity, see the table Calculating Operational Risk Effective Severity further below.

RiskTypeSeverityNotes
End-of-LifeBoolean

High = True

None = False

Version AgeNumber

Number of months since release / 10

High >= 4

Medium > 2 and < 4

Low > 1 and <= 2

None (no risk) <=1

Number of New VersionsNumber

Number of versions since / 2

High >= 6

Medium >= 4 and < 6

Low >= 2 and < 4

None (no risk) < 2

Health of Open Source Project
Release cadence per year

Healthy >= 2 releases

Unhealthy <= 1

This includes all releases. Including any dot releases and patch releases if they are GA releases.

When there is no data, it is presumed as healthy

Number of commits per year

Healthy >= 100 commits

Unhealthy < 100 commits

Number of committers per year

Healthy > = 5 committers

Unhealthy < 5 c ommitters

Calculating Operational Risk Effective Severity

#EOLHealth# of new versionsVersion AgeCombine SeverityRisk Reason
1HighAnyAnyAnyHighEOL
2NoneHigh RiskAnyAnyHighHealth
3NoneNo RiskHighNone, Low, Medium, HighHighNumber of new versions and Version Age (only when High)
4NoneNo RiskMediumNone, Low, MediumMediumNumber of new versions and Version Age (only when Medium)
5NoneNo RiskLowNone, LowLowNumber of new versions and Version Age (only when Low)
6NoneNo RiskNoneNoneNoneNo given reason
7NoneNo RiskNone, Low, Medium, HighHighHighVersion Age and number of new versions (only when High)
8NoneNo RiskNone, Low, MediumMediumMediumVersion Age and number of new versions (only when Medium)
9NoneNo RiskNone, LowLowLowVersion Age and number of new versions (only when Low)