Security Audit Report Schema

JSON schema for the security audit report. The AI generates this JSON as structured output from the audit, then render-security-audit.py injects it into viewer.html to produce a standalone HTML report.

Top-Level Structure

{
  "meta": {
    "date": "2026-04-10",
    "schemaVersion": "1.0",
    "skiaSubmoduleCommit": "8c99e432ff06e61c42cf99aa8f2cbe248d301b9a",
    "skiaUpstreamCommit": "9ab7c2064b2b1ab22f856a7f0a8c3b3ae4cb89c7",
    "skiaMilestone": 132,
    "upstreamVerified": true
  },
  "summary": {
    "needsAttention": 3,
    "undiscovered": 2,
    "falsePositive": 4,
    "clean": 5,
    "totalCves": 12,
    "highestSeverity": "HIGH"
  },
  "versionVerification": [ ... ],
  "findings": [ ... ],
  "cgAlerts": { ... },
  "chromeReleases": { ... },
  "nextSteps": [ ... ]
}

meta — Audit Metadata

versionVerification — Dependency Version Checks

Array of objects, one per dependency:

{
  "name": "libpng",
  "depsCommit": "02f2b4f4699f0ef9111a6534f093b53732df4452",
  "verifiedVersion": "1.6.54",
  "cgmanifestVersion": "1.6.54",
  "match": true,
  "verificationMethod": "png.h header via googlesource mirror"
}

findings — Individual Dependency Findings

Array of finding objects, sorted by priority then severity.

🛑 ONE finding per dependency. Every dependency (e.g., "skia", "libpng", "freetype") must appear as exactly ONE object in this array. All CVEs for that dependency — regardless of their status (affected, already_fixed, false_positive) — go inside that single finding's cves[] array. Use each CVE object's assessment field to distinguish affected vs. fixed vs. false positive. Do NOT create multiple finding objects for the same dependency split by status, milestone, or category. The validator enforces this as an error.

{
  "id": 1,
  "dependency": "skia",
  "status": "needs_attention",
  "currentVersion": "chrome/m132",
  "fixVersion": "chrome/m147",
  "latestVersion": "chrome/m147",
  "cves": [
    {
      "id": "CVE-2026-3931",
      "severity": "HIGH",
      "cvss": 8.8,
      "fixedIn": "m146",
      "description": "Heap buffer overflow in Skia",
      "source": "NVD (Chrome CPE)",
      "assessment": "affected",
      "evidence": "Fix milestone m146 > our m132"
    }
  ],
  "nonChromeCves": [
    {
      "id": "CVE-2025-32318",
      "severity": "HIGH",
      "cvss": 8.8,
      "description": "OOB write due to heap buffer overflow",
      "source": "Android 16 Security Bulletin",
      "assessment": "needs_review",
      "codePathCheck": "No specific file/function identified publicly",
      "evidence": "Android bulletin, shared Skia code — needs manual verification"
    }
  ],
  "issues": [],
  "prs": [],
  "action": "Merge upstream Skia to m147",
  "notes": "Recommended target: m147 for all CVEs. Minimum: m146 for HIGH CVEs."
}

Finding status Values

CVE assessment Values

CVE Fields — "Value OR Note" Principle

Every essential CVE field must be either a concrete value OR a *Note field explaining why it's missing. Silent nulls ("we couldn't find it so we left it blank") are forbidden and are rejected by the validator. This forces every CVE to be fully investigated.

Examples:

CVE Object Fields

When assessment == "affected", the resolution fields (cherryPicksCleanly, reachability, onUpstreamMilestone, inOurTree) are strictly enforced — each requires either a value or its note counterpart (with inOurTree always requiring a boolean).

CVE source Values

Examples: "NVD (Chrome CPE)", "NVD web search", "Android Security Bulletin", "Huawei HarmonyOS Bulletin", "Chromium severity rating (CVSS pending)"

nextSteps — Prioritized Actions

Array of action objects:

{
  "priority": 1,
  "severity": "HIGH",
  "action": "Merge upstream Skia to m147",
  "dependency": "skia",
  "reason": "Fixes 6 CVEs including 4× HIGH 8.8",
  "command": null
}

chromeReleases — Chrome Releases Blog Data (Optional)

When the Chrome Releases blog was queried (Step 1.5), include this section for traceability. This section is optional — omit it only if the blog query was skipped or failed.

{
  "queriedAt": "2026-04-10T14:30:00Z",
  "monthsQueried": 6,
  "postsReviewed": 12,
  "totalCvesExtracted": 45,
  "skiaRelevantCves": 8,
  "structuredCves": [
    {
      "cveId": "CVE-2026-8510",
      "severity": "Critical",
      "component": "Skia",
      "description": "Integer overflow in Skia",
      "bugId": "502636904",
      "milestone": 148,
      "blogPostUrl": "https://chromereleases.googleblog.com/...",
      "inNvd": false,
      "extraction": "regex"
    }
  ],
  "earlyDisclosures": [],
  "cacheFile": "output/ai/chrome-releases-cache.json"
}

Field Name Mapping (Script → Report JSON)

The query-chrome-releases.py script outputs snake_case fields. When building the report JSON, transform to camelCase:

Setting blogPostUrl on Findings CVEs

When a CVE in findings[].cves[] also appears in structuredCves[], copy the blogPostUrl onto the finding's CVE object. This enables the HTML viewer to link directly to the source blog post.

CVE source Field (Updated)

The source field on individual CVE objects in findings[].cves[] should indicate provenance:

CVE extraction Field (New, Optional)

For CVEs that came from Chrome Releases data, indicate how they were extracted:

This helps track reliability and identify if the regex needs updating.