Tell a real vulnerability from a version-string false positive
Task
Run a compliance scan, then investigate one reported CVE and establish whether the host is actually vulnerable -- because a scanner comparing version strings reports fixes it cannot see. Learn the two commands that settle it.
Steps
- Run an OpenSCAP evaluation against a CIS profile and skim the results. Note the score and pick one failing rule and one reported vulnerable package.
- For the package, read its changelog:
rpm -q --changelog <pkg> | head -40. Look for a line mentioning the CVE the scanner flagged. - Cross-check with the vendor's security metadata:
dnf updateinfo info --cve CVE-XXXX-YYYY. Establish whether the fix is already present in the installed version despite the version number. - State the conclusion: is this a real exposure or a backport the scanner miscounted? Explain how you know.
- Now find something a version scanner would miss entirely: run
ss -tlnpand find a service bound to 0.0.0.0 that should be local, or a default credential. Argue why that misconfiguration is a bigger practical risk than the CVE in step 4. - Distinguish a Level 1 from a Level 2 finding in the scan output, and explain which you would apply to a production fleet without testing.
Verify
rpm -q --changelog "$PKG" | grep -i "$CVE" && echo "fix is backported into the installed version"
dnf updateinfo list --cve "$CVE" # empty means already fixed
ss -tlnp | grep -v '127.0.0.1\|::1' | grep LISTEN
If the changelog names the CVE, the host is patched and the scanner produced a false positive from the unchanged version number. If dnf updateinfo list still lists it, there is a real update to apply. One of the two must be true, and you should be able to say which.
Notes
The reachable misconfiguration in step 5 is the point that outlasts any single CVE. Exploiting a flaw needs it to be present, reachable and worth the effort; default credentials on an exposed interface need none of those. A version scanner never looks.