Configuring and Interpreting Scans

Optimizing Scans

Two different types of scans can be run:

1. Manual Scans: These scans are triggered by a user from their CLI or by uploading a file within the Web Report. Manual scans are helpful for a moment-in-time view of the current state of EOL for a given project. However, this approach does not scale to enterprise organizations that may have hundreds of projects for which they need continual monitoring. In this case, we recommend using Option 2 below.
2. Automated Scans: These scans are triggered within your CI/CD process, based on user-defined criteria, such as running a new build. This approach will automatically generate JSON reports, which can be saved and loaded into your preferred reporting tool. We recommend setting up a dashboard within a BI tool that can flag concerning EOL packages across multiple projects.

Analyzing your EOL scan results

Once your scan(s) are completed, there are two different types of risk we recommend identifying and using to rank your package versions by. This will enable you to focus on the EOL packages that have the highest impact on your team and company, before determining your remediation options and strategy.

Security risk: Identifying and ranking

Along with your EOL determination, we provide several data points on the potential security risks within your OSS packages that are EOL. These include the number of CVEs, the associated CVSS scores, and whether a security patch is unavailable for any of those CVEs. We recommend using these data points to rank-order your EOL report as a first step in identifying your highest-risk OSS in use.

Technical risk: Identifying and ranking

Technical risk within your EOL OSS usage falls under the “tech debt” umbrella. This risk involves the amount of effort likely required to transition away from any EOL package versions. The leading indicators you should use to determine which OSS may require the most effort to address are:

• Versions out: Number of major versions away from the next support
• Days EOL: The amount of time passed between the minor release you are using and the next supported minor release
• Next Supported: The closest supported version you would need to migrate to.
  • If empty, this indicates that the entire package is likely end-of-life, and an alternative package will need to be identified.

Upcoming Data Points Impacting Technical Risk

• Direct or Transitive Dependency
• Production or Development Dependency
• Framework or auxiliary package

Aligning End-of-Life with organizational standards

While it's ideal to have zero EOL OSS usage, it is simply not feasible for most organizations. As a result, with every isEol = true determination, we provide a list of eolReasons. This list enables users to filter EOL results to what most closely align with their own standards. These standards may be internal rules found within SCA tooling and/or third-party agreements or compliance standards. A complete list of EOL Reasons can be found here.

We recommend setting up automated scans for your most important projects and then configuring your BI tool with the filters that allow you to drill down to the EOL OSS that you care about most. In the case of organizational standards, you can use eolReason data as a mechanism for prioritization. Maintainer Attested is the strongest EOL signal available, followed by Release Line Deprecated, and finally any combination of 2 other reasons.