Vulnerability vs security hardening: what is the difference?
Updated
Security scanners often mix two very different things: known vulnerabilities and hardening recommendations. Treating them the same wastes time and hides the problems that need patching first.
A known vulnerability
A known vulnerability is a flaw in specific software versions that has been published, usually with a CVE identifier, a severity score and a fixed version. If you run an affected version, you fix it by patching. Example: the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) in the PHP runtime.
A hardening recommendation
Hardening is a best practice that lowers risk without a specific flaw behind it: a missing Content-Security-Policy header, version information in response headers, or TLS 1.1 still enabled. There is no CVE and no fixed version. You fix it by changing configuration.
Why scanners should not blur the two
If a scanner calls a missing header a “vulnerability”, a report full of low-value findings buries the one runtime flaw that needs an urgent upgrade. Equally, saying a site is vulnerable without evidence of an affected version misleads customers.
How devsecurity labels findings
Kind: known vulnerability, hardening recommendation, informational, or could not be verified.
Confidence: confirmed, likely, potential, unknown or not detected, always with the evidence behind it.
We never say a site is vulnerable unless the evidence supports it. When a version cannot be read remotely, the result says so and recommends a container or image scan.
Frequently asked questions
What is a CVE?
A CVE is a unique identifier for a publicly known security flaw, such as CVE-2026-109618. It points to details about affected and fixed versions.
Do I need to fix hardening items?
They are worth doing, but patch known vulnerabilities in your runtime and server first.