cve-repo-assessment

Newly discovered CVEs may affect the repository the repo input names. Evaluate each CVE and maintain the repository's findings report. Work from the provided data and tool evidence only.

Inputs — the values arrive in the ## Inputs block below these instructions:

• repo — the repository fullname to assess.
• cves — a JSON array of {repo, cve_id, severity, score, description, package, patched_version, url, created_at}.

Workflow:

1. For each distinct cve_id in cves, call cve_analysis__get_cve to confirm severity, score, and description. If a CVE is not found, keep the provided data and note the gap.
2. Derive the GitHub organization from the repo fullname prefix (the part before /). Call github_security__top_vulnerabilities with that org, repos= the repo fullname, and state='open' to confirm which CVEs map to open security issues, with package, manifest, and patched-version evidence. repos filters in the query, so every row returned is already this repository's — do not fetch the organization and filter the rows yourself.
3. Call reports__list and look for a report named exactly CVE Findings – followed by the repo fullname.
4. If it does not exist, call reports__create with that exact name, then continue with step 5 using the returned report_id.
5. Call reports__get for the latest config when the report already existed. Then call reports__create_version with a complete report config:
   • schema_version: 1
   • name: CVE Findings – followed by the repo fullname
   • queries: an object mapping query names to Cypher strings ({} when none; never a list). Keep any existing entries; no new queries are required.
   • rows: keep existing rows and prepend one new row named with the current date containing a single full-width markdown panel that summarizes: each evaluated CVE (id, severity, score), the affected package and patched version when known, whether an open security issue confirms exposure, and a recommended remediation order.
   • A markdown panel's content MUST be in its markdown field, exactly this shape (no config or content keys): {"type": "markdown", "w": 12, "markdown": "## Findings..."}
   • Pass a comment describing the run (for example "Automated CVE assessment").
6. Do not delete or rewrite prior findings — the report is versioned and prior rows must be preserved.

Output format:

• Finish with a concise summary for the repository: evaluated CVE count, confirmed-exposure count, the report name and version you created, and the top remediation action.
• Keep every claim evidence-backed; state explicitly when a CVE has no matching open security issue in the graph.