// Audit evidence for scanner findings
When the scanner flags a version you already patched
A vulnerability scanner compares a version string with advisory ranges, so a build that carries a backported fix can still be flagged. OSSeva supplies the evidence that answers it: a VEX statement per CVE, an SBOM, a signed build and a CVE record. This page shows what each scanner reads and what to hand the auditor.
Last reviewed
Trusted globally by enterprises
Why a scanner flags a build that is already patched
A scanner can only act on what it can read: a service banner, a package-manager record or a dependency manifest. It matches that value against advisory data. A backported fix changes the code but often leaves the upstream version number in place, or adds only a suffix, as in the 5.3.39-osseva-1 of OSSeva's Spring artifacts. Each tool below deals with that in its own way, according to its own documentation.
| Scanner | What it reads | What its documentation says |
|---|---|---|
| Tenable Nessus | Network banners, plus plugin checks that read installed packages | Plugin 39521 says a web server can carry fixes applied to older code without a version change, that the version string cannot reveal them, and that banner-only checks would raise false alarms. The plugin reports for information only. |
| Qualys | Detections (QIDs) from remote, authenticated and agent scans | Qualys describes adding detections built on the operating system vendor's advisories (Red Hat and Debian are its examples) and changing the generic detection so it stops flagging backported software. Vendor-package detections rely on authenticated or agent scans. |
| Snyk Open Source | Dependencies declared in your manifests | Snyk records each vulnerability as a version interval. The interval [,3.7.2) means every version below 3.7.2. A patched build whose name and version still match a recorded interval falls inside the finding. |
| Trivy | OS packages and language packages | For OS packages Trivy uses the distribution vendor's own advisories, not upstream ones, to avoid false positives where the vendor backports a fix. Language packages use ecosystem databases. It reads VEX documents with the --vex flag. |
Two patterns repeat. Where a tool trusts the operating system vendor's advisory feed, a fix backported by that vendor stops being flagged. A patched build supplied by anyone else is not in that feed, so a version-based match can flag it again unless the scanner is handed a statement that says otherwise. That statement is a VEX. Behaviour differs by scan type, configuration and version, so run your own scanner against the evidence for one build before you rely on it.
Read on 26 October 2026 from the vendors' public documentation, listed under Sources below. OSSeva does not publish which scanners it has tested.
Which kind of audit is this?
Searches for a third-party software support audit mostly find software licence audits, where a publisher checks entitlements and usage and software asset management teams prepare. This page covers a different exercise: the compliance audit or security assessment where an auditor reads a vulnerability report and asks why a supported build still shows open CVEs.
What closes the finding: the evidence pack
Each patched build ships with the items below, so your team can run them through your own scanner and your auditor can read them.
| Item | Format | What it records | Answers |
|---|---|---|---|
| VEX statement per CVE | Machine-readable VEX (format confirmed on request) | Whether this CVE is fixed in this build, does not apply, or is still open, with the date and the author. | The scanner finding on a version number |
| SBOM for the build | CycloneDX or SPDX | The components inside the patched build, so the CVE is matched to what you actually run. | Which components the finding is about |
| Signed build | GPG, cosign, SHA-256 | That the file you installed is the one OSSeva built and has not changed. The commands are on the security page. | Whether the patched build is the real one |
| CVE record and attestation letter | Document | CVE id, CVSS, affected versions, patch delivery date and build identifier for each release. | When the fix shipped and in which build |
| Compliance documentation (Assure) | Document, under NDA | Evidence matrices and remediation records for the frameworks your auditors use. OSSeva's SOC 2 Type II report is also available under NDA. | The audit file as a whole |
What a VEX statement says
VEX was developed in the NTIA software component transparency process. The NTIA overview of 27 September 2021 gives four statuses: not affected, affected, fixed and under investigation. Suppliers publish VEX documents, and third parties can author them. A vulnerability in an included component is often not exploitable in the final product; a VEX lets the supplier say so in a form a tool can read.
CISA's Minimum Requirements for VEX (April 2023) set out what a document must hold. A statement carries one status for one vulnerability across one or more products. For not_affected it asks for a justification or an impact statement. It names CSAF, CycloneDX and OpenVEX as formats that can carry VEX, and says the author identity should be cryptographically tied to the document's signature. CISA also says the document is not official policy and does not impose compliance.
OSSeva marks a CVE fixed only when the build contains the fix. When upstream has no fix, there is nothing to backport and the CVE stays affected. Trivy's documentation for local VEX files describes filtering for not_affected, so ask your scanner vendor how it treats a fixed statement. Whatever the tool does, the statement is the record you give the auditor.
How to take it to the auditor
- 01
Export the findings for the build. Take the scanner list for the host or image that runs the patched build, with the version string it read.
- 02
Match each CVE to its statement. Look up the VEX statement and the CVE record by CVE id. A fixed status ties to a patch delivery date and a build identifier.
- 03
Verify the build you installed. Run the GPG, cosign and SHA-256 checks on the security page so the record covers the file in production.
- 04
Keep your own record. The install date, the change ticket and the approval are yours. The evidence shows what was fixed and when it shipped; your records show when you deployed it.
- 05
Leave open items open. Anything affected or under investigation stays in your risk register with its mitigation. Do not suppress it.
Questions an internal audit should ask a third-party support vendor
Compliance and internal audit teams assess a third-party software support vendor the way they assess any supplier. These questions apply to any provider, OSSeva included, and each one has a document that answers it.
| Question | What OSSeva provides |
|---|---|
| Who builds the patched software, and from which source? | Patches apply to upstream source with no fork, so the build is the upstream release plus the backported fix. |
| How do we verify what we received? | GPG signatures, cosign signatures on images and SHA-256 checksums, with the commands on the security page. |
| Which vulnerabilities does the build fix, and when? | The CVE record and the VEX statements: CVE id, CVSS, affected versions, patch delivery date, build identifier. |
| What is the response commitment? | Critical CVEs patched within 48 hours and High within 7 days, on every technology. |
| What does the supplier hold for its own assurance? | A SOC 2 Type II report, available under NDA for vendor risk review. |
| What stays with us? | Testing, deployment, approvals and the risk register. The evidence supports your assessment and does not replace it. |
How a third-party software support audit reads a patched build
Rules differ on who must supply the fix. NIST SP 800-53 Rev. 5 control SA-22 asks you to replace components when the developer, vendor or manufacturer no longer supports them, or to provide options for alternative sources of continued support. SI-2 asks you to identify, report and correct flaws and to install security-relevant updates within a period you set. A patched build with a dated record is an input to both. Whether it satisfies a given clause is for your assessor to decide.
The clause-by-clause view, with the part that stays with you, is in the compliance matrix and in audit evidence for end-of-life open source. That page owns the rule-by-rule map. This one covers the scanner finding that sends people there.
Not a fit for
- Findings in the operating system or kernel. OSSeva does not patch operating systems.
- Software licence audits. This page is about vulnerability findings, not licence entitlements or usage.
- A CVE with no upstream fix. It stays open in the VEX statement, with a mitigation documented where one exists.
- A promise that a scanner or an auditor will close a finding. OSSeva supplies evidence and does not certify that you comply with any rule.
Sources, checked 26 October 2026: Tenable, plugin 39521: Backported Security Patch Detection (WWW), Qualys, Backporting Support (knowledge base article 000007014), Snyk, Snyk vulnerability database (affected version intervals), Trivy, vulnerability scanning: data sources and detection priority, Trivy, VEX: sources and the --vex flag, Trivy, VEX: local files (OpenVEX, CSAF, CycloneDX), NTIA, Vulnerability-Exploitability eXchange (VEX): An Overview, 27 September 2021, CISA, Minimum Requirements for VEX, April 2023, NIST SP 800-53 Rev. 5, SA-22 Unsupported System Components.
Will auditors accept third-party patches?
That is your assessor's decision, and OSSeva cannot make it for you. What helps the assessor decide is a record they can check: a VEX statement per CVE, an SBOM for the build, a signed build and a CVE record with the patch delivery date and build identifier. Some rules name the source of the fix and some do not. NIST SP 800-53 SA-22, for example, asks you to replace unsupported components or provide alternative sources of continued support. Ask your assessor how the rule you are held to reads, and use the compliance matrix to see the clause next to the evidence.
What is a VEX statement?
A VEX (Vulnerability Exploitability eXchange) statement is a machine-readable assertion about one vulnerability in one product or build. The status is not_affected, affected, fixed or under_investigation. CISA's April 2023 minimum requirements describe a statement as one status for one vulnerability across one or more products, and ask for a justification or an impact statement when the status is not_affected. A supplier or a third party can author it.
How do we stop Tenable flagging a patched build?
You cannot stop a scanner reading a version string, and you should not want to switch the check off. Tenable's own plugin 39521 notes that a version string cannot show a backported fix. Keep the finding visible, attach the VEX statement, the CVE record and the signed-build verification to it, and record the decision through your scanner's exception or risk-acceptance process. The auditor then sees the finding, the fix and the reasoning together.
What if a CVE has no upstream fix?
There is nothing to backport, so the CVE stays open in the VEX statement with status affected, and the CVE record documents a configuration mitigation where one exists. A build is marked fixed only when it contains a fix. Expect that finding to remain in the scan, and list it in your own risk register.
Get a quote
See the evidence before your auditor does.
Ask what the evidence pack holds for your versions and check it against your scanner. An engineer replies within 1 business day.