Network Scanning with nmap and Trivy

Legal and ethical note (read this first)

Only scan networks and hosts you own or have explicit permission to scan. Port scanning a network you don't control, even a "just checking" scan, can violate computer misuse laws and a target's acceptable-use policies -- this guide is written entirely for scanning your own homelab. Scanning someone else's infrastructure without permission is out of scope for this guide, full stop.

What you'll build and why

nmap tells you what's actually reachable and listening on your network -- not what you think is exposed, what actually is. Trivy scans container images for known vulnerabilities (CVEs) in the packages baked into them, before you run them. Together, these answer two different questions this guide covers separately: "what's open on my network" and "what's vulnerable in what I'm running."

Don't build this if: you have no interest in periodically checking your own attack surface -- but given every other Build guide in this section adds another exposed service, this is worth doing at least once after you've built up a real homelab, to see the accumulated picture rather than each piece in isolation.

How it works

  nmap: scans your network's IP range
│
▼
Reports: open ports, likely services, versions
where detectable -- your actual external
surface, not your assumptions about it
─────────────────────────────────────
Trivy: scans a container image's layers
│
▼
Reports: known CVEs in OS packages and language
dependencies baked into that image,
with severity ratings

nmap answers "what's reachable" from the network's perspective; Trivy answers "what's vulnerable" from inside a specific image, before it's ever deployed. Neither replaces the other.

Before you start

Decision: scan scope. Start with your own LAN's IP range for nmap (e.g. 10.0.20.0/24 if that's your homelab VLAN from the segmentation guide elsewhere in this section) -- not your whole home network indiscriminately if you have devices you don't want probed (some IoT devices respond poorly to scanning). For Trivy, start with the images you've actually deployed across this section's other guides.

Steps

Step 1: Install nmap and Trivy

$ sudo apt install nmap

Trivy, per its official install method:

$ sudo apt-get install wget gnupg
$ wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo gpg --dearmor -o /usr/share/keyrings/trivy.gpg
$ echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
$ sudo apt-get update && sudo apt-get install trivy

(Check trivy.dev's current install docs -- Trivy's install method has changed across versions.)

Step 2: Run a basic nmap scan of your own network

$ nmap -sV <your-lan-range-e.g.-10.0.20.0/24>

Expected output: a per-host list of open ports and, where nmap can determine it, the service and version listening on each (-sV enables version detection). This will likely surprise you the first time -- services you forgot were still running, or exposed on an interface you didn't expect.

Step 3: Run a more thorough scan against one specific host

$ nmap -A <host-ip>

-A enables OS detection, version detection, script scanning, and traceroute -- more thorough and slower, worth running against individual hosts you actually care about rather than a whole subnet.

Step 4: Scan a container image with Trivy

$ trivy image <image-name>:<tag>

Expected output: a table of found CVEs by severity (Critical/High/Medium/Low), the affected package, installed vs. fixed version. Run this against images from this section's other guides (Pi-hole, Jellyfin, Home Assistant, and the rest) to see their real current vulnerability picture.

Step 5: Filter Trivy output to what actually matters

$ trivy image --severity CRITICAL,HIGH <image-name>:<tag>

Most images will show some Medium/Low findings essentially always -- filtering to Critical/High first keeps you focused on what's actually worth acting on, rather than overwhelmed by volume.

Verify it works

• The nmap scan (Step 2) completes and lists at least the ports you know are intentionally open (e.g. your reverse proxy's 443, if applicable)
• The nmap scan also surfaces at least one port you didn't immediately expect -- this is normal and is the actual value of running the scan (confirming, not just assuming)
• Trivy (Step 4) successfully scans a real image and produces a CVE table
• The actual point of this guide: pick one Critical or High finding from a Trivy scan, and actually investigate it -- is a fixed version available? Does your deployed service need to be updated? This guide isn't complete until you've acted on at least one real finding, not just generated a report and moved on

Secure it

(This guide's very purpose is verifying security elsewhere -- the points below are about the scanning practice itself.)

• Only scan what you own or have permission to scan -- restated from the top of this guide because it's the one rule that actually matters here.
• A clean scan result is a snapshot, not a guarantee: new CVEs are disclosed continuously -- a Trivy scan run today tells you about today's known vulnerabilities in that image, not next month's. This is why Go further covers running scans periodically, not once.
• Findings you can't immediately fix: if a Trivy finding has no fixed version yet available, document it and monitor rather than panicking -- not every CVE is practically exploitable in your specific deployment context, but don't dismiss findings without actually checking.

Back it up and maintain it

What matters: if you script these scans (Go further), the script itself is worth version-controlling; the scan results are a point-in-time snapshot, not something to preserve indefinitely -- keep recent ones for comparison, not every scan forever.

Update cadence: nmap and Trivy both update independently and fairly often (Trivy's vulnerability database in particular updates continuously) -- Trivy specifically should be updated or at minimum have its vulnerability database refreshed (trivy image --download-db-only) close to scan time, since a stale local database misses recent CVEs.

What to monitor: nothing runs continuously by default in this guide -- see Go further for turning this into a scheduled practice rather than a one-time check.

Troubleshooting

Logs: both tools' own CLI output is the primary diagnostic; nmap has no separate log by default.

Undo

No persistent state to undo -- removing the tools (sudo apt remove nmap trivy) is the only cleanup, and has no effect on anything they previously scanned.

Go further

• Schedule periodic scans (a weekly cron job comparing results to the previous run) rather than a one-time check -- pairs naturally with the observability guides elsewhere in this section for alerting on new findings
• Integrate Trivy into a CI pipeline if you're building your own images, catching vulnerable base images before deployment rather than after
• Explore nmap's scripting engine (--script vuln) for more targeted vulnerability checks against specific discovered services, beyond basic port/version detection

Resources

Official documentation:

• nmap documentation -- verified this session
• Trivy documentation -- verified this session

Source and releases:

• nmap source
• aquasecurity/trivy releases

Community:

• r/netsec

Related DaemonPress projects:

• A Linux Server Hardening Baseline -- do this first; scanning is how you verify it worked
• Building a Router/Firewall with OPNsense

Last verified: 2026-09-21, checked against official nmap and Trivy documentation.