Vulnerability Scanning Basics: How to Find Vulnerabilities on Your Server
"Is my server secure?" Feelings cannot answer that. Your server runs an OS, services, and a pile of dependency libraries — any component with a publicly known vulnerability (CVE) can be an entry point. Vulnerability scanning is a "health check" for your server: it proactively asks "what ports are open, what versions are running, and are there known vulnerabilities?" This guide explains, from zero, what vulnerability scanning is, what the three scan types check, how to use common tools, and how to prioritize the results.
1. What Vulnerability Scanning Is: A Health Check for Your Server
Think of your server as a person and vulnerability scanning as an annual physical:
- Port scanning: checks "which doors are open" — which ports are reachable from outside;
- Service scanning: checks "what is behind each door" — which software and version is listening;
- Dependency scanning: checks "are the medicines in your cabinet expired" — whether libraries your code depends on have known vulnerabilities.
Scanners compare these results against a vulnerability database (CVE database) and output a "report card": which components are at risk and how severe. Note that scanning "finds problems" but does not "solve them" — you still need to review and fix based on the report. To understand the full lifecycle from a flaw's discovery to public disclosure, see Vulnerability & CVE Lifecycle.
2. Three Scan Types, Each with Its Own Purpose
Port Scanning: The Most Basic Layer
Purpose: discover which ports the server exposes to the outside. Ports that should not be open by default (database 3306, Redis 6379) being exposed is a "door left unlocked".
nmap -sV -p- your-server-ip
-sV probes versions as well, and -p- scans all 65,535 ports. When you see unexpected open ports, either stop the service or block it with the firewall. Rules are in Linux Firewall Configuration.
Service and Version Scanning: Find Software "Working While Sick"
Purpose: confirm the software and version behind each open port, then compare against the vulnerability database. For example, if Nmap finds Nginx 1.20.1, look up whether that version has known CVEs. Nmap's -sV does exactly this.
Dependency and Image Scanning: Catch "Invisible" Risks
The npm/pip/composer packages your site depends on and the system libraries inside Docker images are hot spots for vulnerabilities. Because dependencies number in the hundreds or thousands, manual review is impractical — automation is the only option. For image scanning in containerized deployments, see Container Security Best Practices.
3. Common Tools: How to Choose and Use Them
| Tool | Role | Best for | Typical usage |
|---|---|---|---|
| Nmap | Network/port/service scanning | Quickly mapping the attack surface | nmap -sV -p- ip |
| OpenVAS | Full vulnerability scanner (with vulnerability DB) | Regular comprehensive checkups | Browser interface; configure a target and scan in one click |
| Trivy | Container image/filesystem/dependency scanning | Scanning images and dependencies in CI | trivy image your-image, trivy fs . |
| Nikto | Web server misconfiguration scanning | Web site checkups | nikto -h https://your-site.com |
Selection factors: whether you need web-application scanning, CI integration, or one-off command-line checks versus scheduled full scans. A more complete tool comparison is in Vulnerability Scanner Comparison.
4. After the Results: Prioritize with CVSS
Scan reports often contain dozens or hundreds of entries. Do not try to fix everything at once; fix the most dangerous first. The industry-standard scoring system is CVSS (Common Vulnerability Scoring System), from 0 to 10:
- 9.0–10.0 (Critical): remotely exploitable with no privileges. Fix within 24 hours, ideally the same day.
- 7.0–8.9 (High): low exploitation barrier, large impact. Fix within a week.
- 4.0–6.9 (Medium): conditionally exploitable. Include in the next maintenance window.
- 0–3.9 (Low): limited impact or hard to exploit. Log it and review periodically.
Add two more dimensions when prioritizing: is it exposed to the internet (a library only on the internal network can wait even with a high score) and is there active exploitation in the wild (jump the queue for flaws already being exploited). Fixes usually fall into three kinds: upgrade the version, apply a patch, or apply mitigations (such as restricting the firewall to internal-only access or disabling the affected module).
5. Intro Workflow and Frequency Advice
- Weekly: run an Nmap port/service scan to confirm the attack surface has not changed.
- Every release: run Trivy in CI to scan images and dependencies; block the merge if problems appear.
- Monthly: run an OpenVAS full scan and produce a monthly report.
- After every scan: sort by CVSS plus exposure, update the fix plan; also read Penetration Testing Basics to understand deeper "attacker's-eye" testing beyond scanning, and when possible hire a professional team for a full penetration test.
6. Frequently Asked Questions
Q1: Will scanning affect production?
It can. Some scans (especially full-port, deep service probing) generate traffic and connections that may trigger alerts or slow services. Scan a test/staging environment first, and use low-frequency, low-concurrency settings on production.
Q2: If no vulnerabilities are found, am I safe?
No. Scanning only finds "known vulnerabilities"; it cannot catch logic flaws, misconfigurations, or zero-days. It is the lowest-barrier health check, not a security certification.
Q3: Aren't scanning tools for hackers?
No. Nmap, Trivy, and others are legitimate operations/security tools; "where you point them" determines the nature. Scanning your own assets is standard practice. Note that scanning someone else's assets without authorization is illegal in most jurisdictions.
Q4: Where can I find more security hardening content?
The Security Hardening category on this site covers system hardening, WAF, security headers, and more — complementary to scanning.