Keep the scanner
Preserve the discovery, prioritization, ticketing, and reporting workflows your team already depends on.
Comparison guide
oxharden vs. vulnerability scanners: discovery and runtime proof do different jobs.
Use vulnerability scanning to find and prioritize risk. Use oxharden when you also need host-level evidence that a Linux fix is installed, active in the running kernel or processes, and ready to close.
oxharden complements the scanners teams already run. It adds the evidence between “the package changed” and “the vulnerable code stopped running.”
The short answer
A scanner finding and remediation proof are related, but they are not the same artifact.
Package and vulnerability findings are essential inputs. After an update, Linux can still be running the older kernel or a long-lived process can still map the pre-update library. A complete closure decision therefore needs package state and runtime state.
This comparison describes evidence shapes and workflow boundaries. It is not a claim that every vulnerability-scanning product has the same capabilities.
Evidence comparison
Where package findings end and runtime verification begins.
The useful evaluation question is not which tool has the longest feature list. It is which evidence your team needs to make a defensible closure decision.
| Question | Package/version-only workflow | oxharden evidence |
|---|---|---|
| What software is installed? | Inventory and package findings are a core input to the workflow. | Records installed package state and connects it to host, advisory, and runtime context. |
| Is the vendor-fixed package present? | A package or version result can show that the fixed build is installed. | Keeps the installed EVR and vendor-fixed EVR together as package evidence. |
| Is the fixed kernel active? | A package-state result may still need a separate running-kernel check. | Compares the installed kernel with the kernel the host is actually running. |
| Are services still using old libraries? | A package update alone does not establish which code a long-running process has mapped. | Connects running processes and mapped libraries to the restart action that remains. |
| What work is still required? | The next action is often resolved in the surrounding remediation workflow. | Separates package updates, service restarts, reboots, and evidence gaps by host. |
| What closes the finding? | A scanner-only workflow can close when the package or next-scan state changes. | Can keep the finding open until installed and live state agree. |
Example evidence shape
The package can be fixed while the service remains stale.
After a shared-library update, the package database reports the new build on disk. A long-running service may still have the replaced object mapped until it restarts. The package result is true, but it does not answer the runtime question by itself.
Read the deeper explanation in Applied vs. Live patch verification or review the practical inspection workflow in the stale Linux process guide.
Installed Fixed library package is on disk package evidence
Running Service still maps the replaced library process evidence
Action Restart the affected service, then verify again closure evidence
Evaluation framework
Use both when the closure decision matters as much as detection.
Add runtime evidence
Check active kernels, running processes, mapped libraries, exposed services, and the restart or reboot action that remains.
Close with a reason
Keep the host-level evidence that explains why the finding can close—or why it must stay open after the package update.
Scope and limitations
Evaluate the evidence, not a generic vendor label.
- Scanner capabilities vary by product, edition, configuration, and integration.
- This page does not claim that a named vendor can or cannot collect a specific signal.
- Package state, runtime state, scanner state, and workflow state should remain distinct.
- Host evidence can support a compliance workflow; it is not a compliance guarantee.
For the product scope and data flow, see What is oxharden? and the security overview.
FAQ
Vulnerability scanner comparison questions.
01 Does oxharden replace a vulnerability scanner?
No. oxharden includes Linux vulnerability management, but it is best understood as a verification and evidence layer. Teams can keep their existing scanner and use oxharden to determine whether fixes are live and what host-level action remains.
02 What is the difference between installed and live patch evidence?
Installed evidence shows that a fixed package or kernel exists on disk. Live evidence checks the active kernel and running processes to determine whether the host is still executing code that predates the update.
03 Can oxharden and an existing scanner run together?
Yes. Scanner findings can identify the risk queue, while oxharden adds package, kernel, process, exposure, restart, reboot, and host evidence that helps teams decide what remains before closure.
See the evidence
Start with one Linux host.
See package findings, runtime deltas, restart debt, and the action that remains.