Review vulnerability findings

Online scans send package names and exact versions to OSV.dev for advisory lookups. They also download CISA's Known Exploited Vulnerabilities (KEV) catalog. Package names and versions can reveal private dependencies. Offline scans skip these requests and remain incomplete. See privacy.

Reports retain attribution to OSV, the GitHub Advisory Database under CC-BY 4.0, and CISA KEV. Reports group identifiers for the same advisory, including when matching KEV entries. A KEV match means exploitation has been reported. It does not establish that your product was exploited.

Read the reports#

Open cra/reports/vulnerabilities.md to see which components have findings and which versions fix them. The report links to sources and shows your saved triage decisions. JSON keeps the same evidence for other tools. Coverage gaps include unknown versions and modified copies. Findings concern third-party components rather than your own code. Zero findings cannot prove the absence of vulnerabilities.

If any advisory or KEV lookup fails, Fendkit still writes reports but scan returns 11. Run fendkit doctor to check connections, then retry fendkit scan. Check also needs reports from the same scan, no older than seven days, and access to the recorded release. Its next action explains what needs fixing. A failed lookup leaves the evidence incomplete.

Decide what a finding means for this product#

Check whether your shipped copy uses the affected code. Fendkit compares numeric versions to suggest updates. For other version schemes, check the linked advisory for a suitable fix. Test updates in your product before replacing bundled libraries. Fendkit does not update libraries for you.

This example uses a finding from the demo. Replace the advisory and exact component package URL (purl) with values from your own saved report:

fendkit triage GHSA-f2wf-25xc-69c9 --component 'pkg:npm/[email protected]' --status under_investigation --reason 'Reviewing where this product uses the affected code'

Use affected with your intended response, under_investigation while checking, fixed when the finding has been addressed, or not_affected with evidence. Every decision requires a reason. not_affected also requires an OpenVEX justification: component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary, or inline_mitigations_already_exist. Keep evidence for the justification you choose.

Triage needs cra.yml and saved findings it can read. It saves your decision for that advisory and component version in the profile. It then rewrites the vulnerability reports and vex.openvex.json, without network access. A decision for one dependency version does not apply to a later version. Fendkit exports VEX only when saved triage matches current findings. VEX records whether a vulnerability affects this product. Keep decisions tied to this product rather than copying them to unrelated products.

Run check after triage. Open KEV findings in shipped or possibly shipped components fail policy. Ordinary findings still need review even when check exits 0. If exploitation or a severe incident affects your product, review incident handling; advisory discovery alone does not establish the maker's awareness time for a reportable event.