About Scanning in FutureVuls#
What This Page Covers#
- What a FutureVuls "scan" actually does (the big picture)
- Where scan results appear on the screen
- What scanning methods are available and how to choose one
How Scanning Works#
A "scan" in FutureVuls is executed in two stages:
- (A) Upload of configuration information: The scanner collects the server's configuration information (OS, installed packages, etc.) and uploads it to FutureVuls.
- (B) Matching: The uploaded configuration information is matched against the latest vulnerability data.
The matching results (detected vulnerabilities) are automatically reflected on the FutureVuls screen. Detected vulnerabilities are listed on the "CVE" tab, and a response ticket (Task) is automatically created for each "server x vulnerability" combination. In other words, once scanning is set up, you can find the vulnerabilities that need attention just by checking the "Task" tab.
graph LR
%% Style Definitions
classDef serverStyle fill:#4a90e288,stroke:#4a90e2,stroke-width:2px
classDef scannerStyle fill:#ff6b3588,stroke:#ff6b35,stroke-width:2px
classDef vulnStyle fill:#fdcb6e88,stroke:#fdcb6e,stroke-width:2px
classDef processStyle fill:#6bb6ff88,stroke:#6bb6ff,stroke-width:2px
classDef resultStyle fill:#66bb6a88,stroke:#4caf50,stroke-width:2px
%% Node Definitions
Server["Server to be Scanned<br>OS & Package Info"]:::serverStyle
Scanner["Vuls Scanner"]:::scannerStyle
FutureVuls["FutureVuls"]:::processStyle
VulnDB["Vulnerability Database<br>(Latest Information)"]:::vulnStyle
CveTab["'CVE' tab<br>List of detected vulnerabilities"]:::resultStyle
TaskTab["'Task' tab<br>Response tickets created automatically"]:::resultStyle
%% Flow
Server -->|"(A) Collect Configuration Info"| Scanner
Scanner -->|"Upload Configuration Info"| FutureVuls
VulnDB -->|"Vulnerability Information"| FutureVuls
FutureVuls -->|"(B) Matching Process"| CveTab
FutureVuls -->|"(B) Matching Process"| TaskTabFor how to read the detection results, see "CVE Tab" and "Task Tab".
Types of Scanning Methods#
FutureVuls offers multiple scanning methods depending on what you want to manage (servers, containers, network devices, and so on). An overview of each scanning method is as follows. For details, please refer to the manual for each scanning method.
| Scanning Method | Overview |
|---|---|
| Local Scan | The standard method of installing the scanner directly on the server |
| Remote Scan | A method of scanning via a jump server |
| Paste Scan | A registration method without using a scanner, suitable for closed networks |
| Docker Scan (Trivy) | A method to scan Docker container images using Trivy |
| Docker Scan (ECR/GAR) | A method to scan container images registered in ECR/GAR |
| Application Scan | A method to scan applications such as language libraries |
| CPE Scan | A method to register network devices or software not managed by a package manager |
| Inspector Integration | A method to manage information by importing it from Amazon Inspector into FutureVuls |
| SBOM Import | A method for vulnerability management by importing SBOM files |
| WordPress Scan | A method to manage vulnerabilities in WordPress environments, including core, plugins, and themes |
| Integrate into CI/CD Pipeline | A method to scan container images and libraries by integrating into a CI/CD pipeline |
If you are unsure which scanning method to choose, see "How to Choose a Scanning Method". It explains which scanning method to choose for each type of managed target, with flowcharts.
When Scans Run#
The above (A) and (B) are executed at the following times:
| Scan Classification | Process Executed | Execution Method and Frequency |
|---|---|---|
| Agent Scan | (A) + (B) | The Vuls scanner installed on the target server (or on a remote scanning server) runs at the cron schedule configured during installation. Manual execution is also possible. |
| Scheduled Automatic Scan | (B) only | Applies to all servers on the CSIRT plan and some servers on the Standard plan. Runs once daily, between 00:00 and 08:00 JST. |
| Manual Scan | (B) only | Launched when "Manual Scan" is clicked in the FutureVuls UI. |
| Automatic Re-matching When Threat Information Changes | (B) only | Automatically re-matches eligible servers when a previously detected vulnerability is added to KEV or its SSVC Exploitation changes to active. |
| Automatic Re-matching When CPE Detection Conditions Are Added | (B) only | Automatically re-matches pseudo-servers for eligible vulnerabilities when new CPE detection conditions are added. |
"Upload of configuration information (A)" is performed only during an agent scan. Scheduled automatic scans, manual scans, and automatic re-matching re-run only "Matching against the latest vulnerability data (B)", using the configuration information that has already been uploaded. This re-run matters because even if nothing changes on the server, new detections can occur through (B) alone when new vulnerabilities are published.
About the Targets of Scheduled Automatic Scans
For details on which servers are targeted by scheduled automatic scans, execution timings, skip conditions, and more, please refer to "Scheduled Automatic Scans".
About the FutureVuls Scanner
For convenience, we have referred to the component that collects configuration information in FutureVuls (the scanner) as an "agent," but this scanner is actually a binary built in Go (approximately 200MB in size). While the term "agent" may give the impression of a resident process that is always running and could burden the server, FutureVuls simply executes this binary on a schedule. Therefore, it is only launched as a temporary process, and the server load is minimal.
Manual scans can be initiated from the server details page (per server) or Group Settings > Manual Scan of All Servers (per group).
Running Scans in Quick Succession
If you run server-level manual scans, paste scans, or SBOM registrations and updates in quick succession, they may be queued per organization, which can slow down responses. With the FutureVuls API, processing continues even if a call times out while waiting in this queue. Do not resend the same request. For details, see "Queuing for Scans and SBOM Registration".
Automatic Re-matching When Threat Information Changes#
When a previously detected vulnerability is newly added to KEV, eligible servers are automatically re-matched using their previous scan results.
The same mechanism also re-matches servers when a vulnerability's SSVC Exploitation changes to active (actively exploited) based on information other than KEV.
No new configuration information is collected from the servers.
Eligible Servers#
| Server type | Eligible organizations |
|---|---|
| Servers other than scanner, paste, and SBOM servers (pseudo-servers, container images, etc.) | All plans |
| Scanner, paste, and SBOM servers | Organizations subscribed to the CSIRT / PSIRT Plan |
In the following cases, changes are reflected as before, at the next scan (import).
- Scanner, paste, and SBOM servers in organizations that are not subscribed to the CSIRT / PSIRT Plan
- Servers whose previous scan results are no longer available
- When a vulnerability that has not yet been detected is added to KEV
- Vulnerabilities detected by Amazon Inspector in groups that have enabled Amazon Inspector SBOM import
Update Timing and Details#
CISA KEV / VulnCheck KEV / ENISA KEV are checked every 15 minutes.
Changes are typically reflected within 1 hour of a vulnerability being added to KEV.
If there are many eligible servers, it may take until the next morning, depending on the time of day.
When Exploitation changes to active based on information other than KEV, servers are re-matched within a few hours after that information is reflected in the vulnerability database.
As with scheduled automatic scans, each re-match is recorded in the scan history with the scan type "Vulnerability Scan" and the scanner name "FutureVulsAuto".
Re-matches are also counted in the server's "Successful Scans This Month" and update its "Last Detection Time". The "Last Configuration Sync" does not change.
Vulnerabilities added to KEV are reflected in tasks as actively exploited vulnerabilities when the servers are re-matched. The security alerts in the Vulnerability List and Vulnerability Details, and the display and filtering of exploit code, are updated when we check KEV, without waiting for the re-match. For organizations with SSVC enabled, re-matching also updates the SSVC Priority and due date. If you have set up SSVC-based auto triage, its actions (such as changing the task status or priority) are also executed at the time of re-matching.
Groups that have enabled notifications for actively exploited vulnerabilities are notified at the point of re-matching.
Vulnerabilities whose Exploitation changes to active based on information other than KEV do not trigger this notification.
Tasks whose SSVC Priority becomes Immediate as a result of re-matching trigger an Immediate task notification.