Supply Chain Risk#

The software used in your organization inherently carries security risks. In particular, software that has reached its end of life (EOL) is at a higher risk of having unpatched vulnerabilities, which can lead to security incidents. Furthermore, the inclusion of malicious packages poses a significant risk that can directly lead to information leakage or system compromise. The Supply Chain Risk feature allows you to centrally manage the EOL status and malicious packages of all software used on every server in your organization, enabling a planned and systematic response.

About the Supply Chain Risk Feature#

The Supply Chain Risk feature detects supply chain risks such as End of Life (EOL) and malicious packages, and manages them centrally as tickets.

Key Features#

Comprehensive EOL Detection#

Supports a wide range of targets including Linux/Windows OS, containers, OSS libraries, third-party software, and more.
Comprehensive detection combining over 400 products listed on endoflife.date, official EOL information from OS vendors, and effective EOL (EOL-Effective) detection using FutureVuls' proprietary logic.

Centralized Management via Tickets#

A dedicated screen aggregates EOL information and malicious packages, allowing you to check status, deadlines, and affected assets.
Allows you to set response status, priority, assignee, and due dates, as well as add comments.
Manage efficiently with filtering and sorting.
Tickets are automatically closed during the next scan once the EOL issue is resolved or the malicious package is removed.

Automatic Notifications#

Real-time notifications: When a new supply chain risk is detected or when supply chain risk information is updated.
Monthly EOL report: A summary of EOLs by group and software.

What This Feature Solves#

FutureVuls addresses the supply chain risk management challenges faced by various users with different roles and responsibilities.

For System Administrators#

I want to identify all "unsupported (EOL) software" and "malicious packages" within my systems.
I want to identify software nearing its EOL to plan version upgrades and migrations systematically.
When a malicious package is detected, I want to quickly assess the impact scope and respond.
I want to determine which supply chain risks to prioritize.
I want to share and manage the status of supply chain risk responses within my team.

For Supply Chain Risk Managers in the Security Department#

I want to identify all "unsupported (EOL) software" and "malicious packages" across all company systems.
I want to identify software nearing its EOL and malicious packages, and use the UI to instruct the respective system administrators to take action.
I want to track the response status of each system administrator via the user interface.
I want to report a list of our organization's supply chain risks and their response statuses to management.

Flow from Malicious Package Detection to Resolution#

The overall response flow when a malicious package is detected is as follows.

flowchart LR
    A[Run scan] --> B[Malicious package detected<br>Matched against OSV]
    B --> C[Immediate notification<br>Email / Slack / Teams]
    B --> D[Ticket created in the<br>Supply Chain Risk tab Status: NEW]
    D --> E[Set assignee, priority,<br>and due date]
    E --> F[Take action<br>INVESTIGATING → ONGOING]
    F --> G{Package<br>removed?}
    G -- Yes --> H["Automatically closed at<br>the next scan (CLOSED)"]
    G -- No --> F

About the Scanning Procedure#

No special scanning procedure is required to detect supply chain risks. Based on the software composition information obtained from regular vulnerability scans, FutureVuls automatically matches this information with EOL information and malicious package data, then registers it as a supply chain risk ticket.

Additionally, for software that could not be detected through vulnerability scans, you can add it to the detection targets for EOL and malicious packages by manually registering its CPE/PURL.

CSIRT Plan Exclusive Feature

The Supply Chain Risk feature is currently exclusive to the CSIRT plan.

Detection Targets#

EOL Detection Targets#

The Supply Chain Risk feature provides comprehensive detection of EOL for a wide variety of software, including operating systems, containers, OSS libraries, and third-party software. You can centrally manage all EOL risks on a single platform without needing to switch between multiple tools.

There are two types of EOL: confirmed EOL (EOL-Confirmed) and effective EOL (EOL-Effective). A confirmed EOL is a state confirmed by an explicit end-of-support (EOL) declaration from the provider. An effective EOL is a state where, despite the absence of an official declaration, the software can be regarded as effectively EOL due to factors such as halted maintenance or unpatched critical vulnerabilities. Note that when a repository is merely archived or disabled without an explicit EOL declaration, it is not treated as a confirmed EOL; instead, it is visualized in Software Health according to its maintenance status.

Tickets are created as supply chain risks only for confirmed EOLs and scheduled EOLs. Effective EOLs are also detected and visualized in Software Health and the cross-group search in Group Sets, but no tickets are created for them.

Category	Scan Target	Related Scan Methods/Settings	Notes
Linux	Linux OS	Local Scan/Remote Scan/Paste Scan/Inspector Integration/SBOM Import	For Linux OS packages, the EOL is the same as the OS support deadline, so individual tickets are not created. (See About OS Packages for details)
	RHEL Application Streams	Local Scan/Remote Scan/Paste Scan/Inspector Integration/SBOM Import	・Detected because their support period differs from that of OS packages. (See About OS Packages for details) ・With Inspector integration, EOL information for some packages may not be retrievable.
	Binaries on Linux	CPE Scan Requires Manual CPE Registration	EOLs registered in vuls-saas/endoflife.date.
	Third-party Repository Packages (CPE)	CPE Scan Requires Manual CPE Registration	EOLs registered in vuls-saas/endoflife.date.
Windows	Windows OS	Local Scan/Remote Scan/Paste Scan/Inspector Integration/SBOM Import	-
	Windows Third-Party Software	CPE Scan Requires Automatic CPE Assignment or Manual CPE Registration	EOLs registered in vuls-saas/endoflife.date.
Containers	Container Image OS	Trivy/Inspector SBOM Import/SBOM	・For OS packages, the EOL is the same as the OS support deadline, so individual tickets are not created. (See About OS Packages for details) ・Detecting OS EOL for ECR requires configuring Amazon Inspector SBOM Import.
	Binaries in Container Images	Trivy+CPE Scan Requires Manual CPE Registration	・Vulnerabilities and EOL for binaries within Bitnami images can be detected automatically. Trivy's functionality identifies the PURL of Bitnami image binaries, and FutureVuls' functionality detects the EOL. Ref: Trivy/Bitnami Images ・For non-Bitnami images, vulnerabilities and EOL can be detected by manually registering the binary's CPE in FutureVuls.
OSS	OSS Libraries	Lockfile/Trivy/Inspector SBOM Import/SBOM Import	・EOLs registered in vuls-saas/endoflife.date. ・For OSS not registered in endoflife.date, effective EOL (EOL-Effective) can be detected using FutureVuls' proprietary logic. ・Detecting EOL for OSS in an AWS environment requires configuring Amazon Inspector SBOM Import.
Private EOL	In-house products, commercial software, etc., not listed on the official endoflife.date	Register EOL information via the Organization API Requires CPE/PURL Assignment for matching	Private EOL information registered per organization. It takes precedence even if official endoflife.date information exists for the same software. (See Registering Private EOL Information for details)
Other	CPE	CPE Scan Requires Manual CPE Registration	EOLs for commercial products, network devices, etc., registered in vuls-saas/endoflife.date.

Handling of OS Packages

Basic Principle

Packages for Linux OS, Windows, EPEL (Extended Package for Enterprise Linux), and Container Image OS follow the same lifecycle as their respective OS EOL. Therefore, they are not individually ticketed as supply chain risks.

Exception for RHEL Application Streams

Application Streams, introduced in RHEL (Red Hat Enterprise Linux) 8 and later, have support deadlines independent of the OS lifecycle. Therefore, they are managed as individual supply chain risks.

Application Streams (runtimes and tools like Node.js, PHP, Python, MariaDB) have their own individual Retirement Dates.

Detection Examples: nodejs:18, php:8.2, java-21-openjdk, dotnet-runtime-8.0, etc.
Data Source: Red Hat Application Streams Life Cycle

Registering Private EOL Information#

You can register EOL information for in-house products or commercial software not listed on the official endoflife.date on a per-organization basis (Private EOL). Registered private EOL information becomes a supply chain risk detection target, and even if official endoflife.date information exists for the same software, the private EOL information takes precedence.

Registration, update, deletion, and listing are performed via the FutureVuls Organization API (registration via the UI is not supported).

Notes on Usage

Use an Organization API token issued in the Organization settings (How to create a token).
Register a purlList (PURL) or cpeList (CPE) for matching against software. In either case, specify a PURL/CPE that identifies the product without including a version; version matching is performed using releaseCycle.
The software to be matched must also have an identifier assigned that matches the registered PURL/CPE. For software that is not automatically assigned one by scanning (e.g., in-house products and binaries, middleware built from source, network devices, IoT devices, etc.), configure it via Manual CPE/PURL Assignment.
The combination of productName and releaseCycle must be unique within an organization.

For specific examples of endpoints, parameters, and curl commands, see "FutureVuls API Sample: Registering Private EOL".

Malicious Package Detection Targets#

For software assigned a PURL, FutureVuls automatically detects malicious packages (packages containing malicious code) by matching them against information from OSV (Open Source Vulnerability).

Scan Methods with Automatic PURL Assignment#

To detect malicious packages, the software must have a PURL assigned. The following scan methods automatically assign PURLs.

For software detected by other scan methods, you can add them to the detection targets by setting a PURL via Manual CPE/PURL Assignment.

About Cases Where MAL-XX (MAL-ID) Appears as a CVE ID in the Vulnerabilities Tab

An ID like MAL-XX (e.g., MAL-2025-47141) may appear in the "CVE ID" column of the Vulnerabilities Tab. This is a vulnerability ID detected as a malicious package by tools like Amazon Inspector, which is imported and displayed as-is in FutureVuls.

This MAL-XX is not detected by the malicious package detection of the Supply Chain Risk feature described on this page (which matches against OSV information).

Viewing and Managing Supply Chain Risks#

Detected supply chain risks can be viewed and managed on a dedicated screen.

Supply Chain Risk List: View a list of all detected EOLs and malicious packages, and filter or sort them by status or priority.
Supply Chain Risk Details: Check detailed information for individual risks, manage their response status, and record comments.

Notification Feature#

The following notification features are available.

Real-time notifications: Email notifications when a new supply chain risk is detected or when supply chain risk information is updated.
Monthly EOL report: Monthly email notifications with a summary of EOLs by group and software.

For more details, please refer to Supply Chain Risk Notifications.