Overview
JFrog Xray's Operational Risk feature provides you with additional data on OSS components that will help you gain insights into the risk level of the components in use.
What is Components Operational Risk?
Components Operational Risk is the risk of using outdated or inactive open source software components in your projects.
How Does This Feature Help Identify the Risk?
This feature helps you identify the operational risk your projects may have by using outdated open source software components. It can also work as an early indicator of any slowness in open source project activity or projects that may not be actively maintained.
How Does it Work?
JFrog Xray tracks the following Operational Risk data for a given open-source component:
End-of-Life (EOL): Determines whether the OSS component in use is obsolete or declared end-of-life by the author.
Version Age: The age of the OSS component in use in months.
Number of New Versions: Number of new versions released after the current version. For example, if you are using version 2.3.4 and there have been three new releases 2.3.5, 2.4.1 and 2.4.2, the value would be 3.
Health of the OSS Project: A boolean value that shows whether the OSS project is healthy or not. This is computed using the following parameters:
Release cadence per year: Number of GA releases including patches, dot releases, and so on.
Number of commits per year: Total number of commits in the last 12 months.
Number of committers per year: Total number of committers in the last 12 months.
Important Notes Regarding Operational Risk
This feature requires Artifactory version 7.37.x and above.
This feature requires JFrog CLI version 2.15.x and above.
This feature is only supported for npm and Maven packages.
How Does Xray Determine the Operational Risk Severity?
Xray calculates the Operational Risk as High, Medium, Low and None (no known risk) using the following criteria:
Risk | Type | Severity | Notes |
|---|---|---|---|
End-of-Life | Boolean | High = True None = False | |
Version Age | Number | Number of months since release / 10 High >= 4 Medium > 2 and < 4 Low > 1 and <= 2 None (no risk) <=1 | |
Number of New Versions | Number | 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
# | EOL | Health | # of new versions | Version Age | Combine Severity | Risk Reason |
|---|---|---|---|---|---|---|
1 | High | Any | Any | Any | High | EOL |
2 | None | High Risk | Any | Any | High | Health |
3 | None | No Risk | High | None, Low, Medium, High | High | Number of new versions and Version Age (only when High) |
4 | None | No Risk | Medium | None, Low, Medium | Medium | Number of new versions and Version Age (only when Medium) |
5 | None | No Risk | Low | None, Low | Low | Number of new versions and Version Age (only when Low) |
6 | None | No Risk | None | None | None | No given reason |
7 | None | No Risk | None, Low, Medium, High | High | High | Version Age and number of new versions (only when High) |
8 | None | No Risk | None, Low, Medium | Medium | Medium | Version Age and number of new versions (only when Medium) |
9 | None | No Risk | None, Low | Low | Low | Version Age and number of new versions (only when Low) |
Workflow
Step 1 Create Operational Risk Policy
An additional Policy type was added to support Operational Risk rules. The rules are based on the risk types determined by Xray. Violations are generated based on the rule criteria you select. For more information on Xray Policies, see Creating Xray Policies and Rules.
Step 2 Attach Policy to Watch
Attach the Operational Risk Policy to a Watch or Watches to apply it on your resources. For more information on Xray Watches, see Configuring Xray Watches.
Step 3 View Operational Risk Data
View Operational Risk Data for your components in the Xray Data tab in Artifactory.
Step 4 View Violations
View Operational Risk violations that were generated based on the Policy rules you set.
Note
Take note that Xray does not perform impact analysis for operational risk updates. The Operational Risk tab will always be updated. The Violations data is updated up to the latest scan (or the latest package download).
Creating Operational Risk Policy
An Operational Risk Policy type includes rules that are based on the risk criteria determined by Xray. To create a Policy, do the following:
In the Administration module, select Watches & Policies and from the Policies tab click New Policy.
Select Policy type as Operational Risk, and click New Rule.
Select the rule criteria. You can do one of the following:
According to minimal risk level; low, medium or high.
According to specific values of the sub-criteria under Custom Conditions. The Custom Conditions are based on the available Xray Operational Risk data. The relationship between the conditions is Or/And.
For more information on creating Policies, see Creating Xray Policies and Rules. After creating the Policy, you can proceed to attach it to a Watch, as described in Configuring Xray Watches.
Viewing Operational Risk Data
The Xray Data tab in Artifactory now includes an additional tab for Operational Risk data. Each component is listed along with the Operational Risk information for each component. To access this data, see Analyzing Resource Scan Results.
 |
Operational Risk Violations
A new type of violation, Operational Risk, is now listed under the Violations tab under Xray Data. The violations are generated according to the rules you have set in the Policy. The violation includes the Operational Risk component data.
 |
When you select a violation, the Operational Risk data is displayed.
 |
Ignoring an Operational Risk Violation
You can create an Ignore Rule to ignore an Operational Risk Violation. To create the Ignore Rule, click the Ignore Violation icon. For more information on Ignore Rules, see Ignore Rules.
 |
Upgrading Xray with Operational Risk Feature Support in Offline Mode
If you are working in an offline mode, you need to manually sync the database to download components data and enable Operational Risk detection.
Do the following:
In the Administration module, go to Xray Security and Compliance and select Database Sync.
Select the Offline sync mode and click Generate Download Command.
A command is generated similar to this:
jfrog xr offline-update --license-id=<LICENSE_ID> --version=<XRAY_VERSION>
If the command includesFromandToparameters, remove them so the command looks like the example above.
Copy the command and run it in the CLI.
The CLI will download 2 files: comp_0.zip and vuln_0.zip
Unzip the components file, for example, comp_{NUMBER}.zip. It contains additional zip files such as:
2022-03-22__onboardingf__comp2801_2803__.zip
Place the extracted components zip files under the following folder in Xray server.
${XRAY_HOME}/var/work/server/updates/data_migration/public_comps_operational_risk_files/Trigger the components operational risk persistence migration:
[post] <XRAY_URL>/api/v1/migration/trigger/public_comps_operational_risk Content-Type : application/json
Use the migration values REST API to monitor the operational risk migration process. To learn more about running Xray commands, see Xray REST API.
Once the migration is completed, the migration status will be set to finished. In case of any other status that contains failure information, check the logs and or contact JFrog's customer support.
[GET] <XRAY_URL>/api/v1/migration/data/value?key=public_comps_operational_risk
Sample Response:
{ "key": "public_comps_operational_risk", "value": "finished" }
REST API Support
The following REST APIs have been updated to support the Operational Risk feature: