Vuls Linux Cve Scanner

Vuls Linux CVE Scanner

Trigger / When to Use

Use this skill when the user wants Linux or FreeBSD host vulnerability scanning, agentless CVE assessment over SSH, local host scans, package patch status review, or server fleet vulnerability reporting with Vuls.

Good trigger phrases:

• "scan Linux servers for CVEs"
• "check Ubuntu host vulnerabilities"
• "agentless CVE scan over SSH"
• "scan FreeBSD packages"
• "use Vuls for patch management"
• "audit servers against NVD and OVAL"

Core Capabilities

• Agentless vulnerability scanning for Linux and FreeBSD.
• Remote scan mode through SSH from a central scanner.
• Local scan mode when SSH from the scanner is not desired.
• Fast scan mode with low target impact.
• Deep scan mode for richer package and changelog evidence.
• Vulnerability matching from NVD, OVAL, JVN, RHSA, ALAS, ELSA, FreeBSD-SA, and changelog sources depending on target OS.
• Reports for host patch prioritization and remediation planning.

Workflow

1. Confirm Authorization and Scope

Before scanning hosts, confirm:

• Hostnames or inventory source.
• SSH access method and privilege level.
• Allowed scan window.
• Whether root privileges are allowed.
• Whether the scanner may fetch vulnerability databases from the internet.
• Output handling requirements because host package inventories are sensitive.

Never scan hosts outside the user's authorized scope.

2. Choose Scan Mode

Use:

• Fast remote scan for broad, low-impact fleet checks.
• Deep scan for high-value servers where detailed package evidence matters.
• Local scan for isolated hosts or environments that cannot accept SSH from the scanner.
• Containerized Vuls setup when the user wants a quick controlled runtime.

3. Prepare Data Sources

Vuls needs vulnerability intelligence before reliable scanning. Depending on setup, prepare:

• NVD.
• JVN.
• OVAL feeds for the target distributions.
• Vendor advisories such as RHSA, ALAS, ELSA, or FreeBSD-SA.

With Vulsctl-style Docker workflows, use the official tutorial commands as the source of truth and avoid inventing feed paths.

4. Define Targets

Create a minimal target config:

[servers]

[servers.web01]
host = "web01.example.com"
port = "22"
user = "scanuser"
keyPath = "/home/scanner/.ssh/id_ed25519"

Keep credentials outside the repository. Use SSH agent or secure secret storage.

5. Run Scan

Example flow:

vuls configtest
vuls scan
vuls report

For local host workflows, follow the installed Vuls version's local scan syntax and document the exact command used.

6. Triage Findings

For each host:

• Identify OS distribution and version.
• Separate kernel, runtime library, and application package CVEs.
• Check vendor fixed package status.
• Note reboot requirements for kernel or core library updates.
• Identify exposed services and internet-facing hosts.
• Group fixes by package manager transaction when possible.

Prioritize:

1. Exploited-in-the-wild or remotely exploitable CVEs on exposed services.
2. Kernel and privilege-escalation issues on multi-user hosts.
3. CVEs with vendor-fixed packages available.
4. Unsupported OS releases with no security updates.
5. Libraries embedded in application runtimes.

Common Patterns

Debian / Ubuntu Remediation

sudo apt-get update
sudo apt-get upgrade --with-new-pkgs
sudo needrestart

RHEL-Compatible Remediation

sudo dnf update --security
sudo needs-restarting -r

Fleet Report Template

## Host CVE Scan Summary

- Scan date:
- Scanner:
- Targets:
- Critical:
- High:
- Reboot required:
- Unsupported hosts:
- Top packages to patch:
- Exceptions:

Accepted Risk Record

## Accepted Host Vulnerability

- Host:
- CVE:
- Package:
- Reason:
- Compensating control:
- Owner:
- Review date:

Interpretation Rules

• Vendor advisories often matter more than generic NVD severity for Linux packages.
• A package can be backported and safe even when the upstream version number appears old.
• Kernel findings may remain active until reboot even after package updates.
• Unsupported OS releases should be treated as a structural risk, not a normal patch queue.
• Scans should be repeated after remediation to verify installed versions and reboot state.

Boundaries

• Do not run package upgrades unless the user explicitly asks for remediation.
• Do not store SSH private keys in the repository.
• Do not scan internet ranges or third-party hosts.
• Do not assume rootless fast scans catch every issue.
• Do not publish host inventory, package lists, or vulnerability reports externally without approval.

Reference Sources

• Vuls official site: https://vuls.io/
• Vulsctl tutorial: https://vuls.io/docs/en/tutorial-vulsctl-docker.html