Security Audit

Security Audit Skill

Investigate the security status of SkiaSharp's native dependencies. Skia core is treated as the product itself (not just a dependency) and gets a deeper, commit-level resolution process. Third-party deps and Component Governance alerts are audited alongside it and combined into a single unified report.

ℹ️ This skill is read-only. To create PRs and fix issues, use the native-dependency-update skill.

Key References

• references/chrome-releases.md — Chrome Releases blog: RSS query, two-pass extraction (regex + AI review), cross-referencing with NVD
• references/milestone-schedule.md — Chromium release heads-up: main vs Beta milestone coverage, channel milestones + Skia commits
• references/skia-cve-resolution.md — Skia core CVE pipeline (NVD → Bug ID → Commit → Branch → Cherry-pick → Reachability). The Skia process is fine-grained — read this before auditing Skia.
• references/third-party-deps.md — Third-party CVE process (libpng, freetype, harfbuzz, etc.): version verification, fix-commit ancestry, known false positives
• references/cg-alerts.md — Component Governance alerts: ADO pipeline queries, Docker container CVEs, fix locations
• documentation/dev/dependencies.md — Dependency list, cgmanifest format, Skia-specific tracking notes
• references/report-template.md — Markdown format guide (used by render-security-audit-md.py)
• references/report-schema.md — JSON schema for structured output
• references/security-audit-schema.json — Machine-readable JSON Schema (Draft 2020-12)
• scripts/validate-security-audit.py — Validates report JSON against schema + semantic checks
• scripts/render-security-audit.py — Renders JSON → standalone HTML
• scripts/render-security-audit-md.py — Renders JSON → Markdown (for AI consumption)
• scripts/viewer.html — HTML template (Bootstrap 5)

Workflow

1. Search GitHub issues/PRs (all deps including Skia)
2. Query Chrome Releases blog (query-chrome-releases.py) — see Chrome Releases
3. Query Chromium release schedule (query-milestone-schedule.py) — main vs Beta heads-up + release-notes support-tier drift, see Milestone Schedule
4. Verify dependency versions from submodule/DEPS/headers (NOT cgmanifest.json)
5. Audit Skia core CVEs — see Skia CVE Resolution
6. Audit third-party dependency CVEs — see Third-Party Deps
7. Query Component Governance alerts — see CG Alerts
8. Check false positives
9. Assemble structured JSON report
10. Validate report (validate-security-audit.py)
11. Render HTML (render-security-audit.py)
12. Present markdown summary to user

Step 1: Search Issues & PRs

Search mono/SkiaSharp open issues for:

• CVE numbers (e.g., "CVE-2024")
• Keywords: "security", "vulnerability"
• Dependency names: skia, libpng, expat, zlib, webp, harfbuzz, freetype

Search PRs in both mono/SkiaSharp and mono/skia for dependency updates already in flight.

Step 2: Query Chrome Releases Blog

🔍 The Chrome Releases blog often discloses Skia CVEs before NVD processes them. This step provides early detection and cross-validation.

See references/chrome-releases.md for full details on the data source, script usage, and AI review instructions.

Run the script

python3 .agents/skills/security-audit/scripts/query-chrome-releases.py \
  --verbose --output output/ai/chrome-releases-cache.json

This takes ~10-30 seconds (fetches RSS feed pages). Cache is reused if < 24 hours old.

Two-pass review

1. Deterministic (regex): Read structured_cves[] from the JSON output. These are high-confidence CVEs extracted from the known blog format. Each has a CVE ID, severity, component, bug ID, and milestone already parsed.

2. AI review (broad): Scan posts[].text_content for anything the regex missed:

   • CVE mentions not captured by regex (format variations, line breaks)
   • Indirect Skia references ("type confusion in Rendering")
   • Wild exploitation notices (highest priority!)
   • Related component CVEs (GPU, Compositing) that may involve Skia code

Cross-reference with NVD (Step 5)

After the NVD query in Step 5, compare results:

Set the source field on each CVE object: "both", "chrome_releases", or "nvd".

Step 3: Query Chromium Release Schedule (main vs Beta Heads-Up)

🗓️ Scheduling + channel context, not a security check on its own. It tells us whether main is keeping up with the Chrome Beta milestone and how much lead time remains before the next milestone reaches stable.

main is the SkiaSharp front line and tracks the Chrome Beta milestone; as milestones graduate Beta → Stable → Extended stable, a release/<major>.<M>.x line is cut from a main that was already on M. So "where we are" = main's milestone, and the signal that matters is main_milestone >= beta_channel_milestone. See references/milestone-schedule.md for the model, endpoints, and flags.

Run the script

python3 .agents/skills/security-audit/scripts/query-milestone-schedule.py \
  --output output/ai/milestone-schedule-cache.json

This reads main's milestone + major from scripts/VERSIONS.txt, fetches the live channels and the upcoming schedule, and prints prioritized heads-up alerts:

Support-tier drift (release-notes support block)

The same run also drift-checks the release-notes support paths in scripts/infra/docs/versions.json (two hand-maintained lists, stable + preview) against the live channels — detection only, the fix is a manual edit of that file (spec §3.5). The verdict is in the support object of the JSON (status: ok | warn | drift | absent) and printed under "Support tiers (versions.json)":

This is a docs-grouping check, not a CVE — but a drift verdict means the website is mis-stating what is supported, so treat it as a finding.

Use the result

• Where we are vs what's coming — meta.status + the upcoming table answer it directly.
• Escalate Skia bump recommendations in nextSteps when status == "behind" (or a watch milestone) also carries HIGH/CRITICAL CVEs from the Chrome Releases / NVD passes; cite the target milestone's stable date as the deadline. Treat a critical heads-up as a finding even with no GitHub issue filed.
• For whether a shipped release/*.x line is missing a within-milestone Skia backport, use the Skia CVE resolution process (merge-base ancestry) — the schedule tool only covers milestone alignment.

Step 4: Verify Dependency Versions

⚠️ CRITICAL: Never trust cgmanifest.json blindly. Always verify versions against the actual submodule, DEPS file, and source headers. cgmanifest.json is manually maintained and can drift. Report any mismatches as findings.

4.1 Verify Skia milestone and upstream commit

🛑 MANDATORY: Fetching the upstream google/skia branch is required, not optional. Adding a git remote and fetching is read-only — it does not modify any tracked files. Without independent verification of the upstream merge point, the audit would trust cgmanifest.json circularly, defeating the purpose of verification.

# 1. Get the actual submodule commit
git submodule status externals/skia
# Output: 8c99e432... externals/skia (the mono/skia fork commit)

# 2. Read the REAL milestone from the source
cat externals/skia/include/core/SkMilestone.h
# Look for: #define SK_MILESTONE NNN

# 3. Find the upstream google/skia merge point
cd externals/skia
git log --oneline --merges --grep="chrome/m" -5 HEAD
# Find the merge commit that brought in chrome/mNNN

# 4. Add the upstream remote and fetch (read-only)
git remote add upstream https://github.com/google/skia.git 2>/dev/null || \
  git remote set-url upstream https://github.com/google/skia.git
git fetch upstream chrome/mNNN
git log --format="%H %s" -1 FETCH_HEAD
# This gives the independently-verified upstream_merge_commit

# 5. Confirm upstream is ancestor of our fork
git merge-base --is-ancestor FETCH_HEAD <merge-parent> && echo "VERIFIED"

Compare against cgmanifest.json and report mismatches:

4.2 Verify third-party dependency versions

See references/third-party-deps.md for the full table of header files and the googlesource mirror URL pattern. In short: read pinned commit hashes from externals/skia/DEPS, then fetch each dependency's version header at that commit and parse the version string.

4.3 Verify ANGLE and its submodules

ANGLE is a separate native component (Windows-only, for WinUI). It is NOT part of the Skia submodule.

grep ANGLE scripts/VERSIONS.txt
# Output: ANGLE    release    chromium/NNNN

ANGLE has its own submodules (third_party/zlib, jsoncpp, vulkan-deps, astc-encoder/src) that must also be tracked. See references/third-party-deps.md for details. Flag any missing from cgmanifest.json as a coverage gap.

4.4 Build the dependency overview

The versionVerification array in the JSON report must include ALL dependencies from ALL sources:

Each entry must have a source field and a cgmanifestVersion field (null if missing). Report mismatches as findings.

Step 5: Audit Skia Core CVEs

🛑 Skia is the product, not just a dependency. Every Skia CVE must be resolved to a specific fix commit, branch, cherry-pick test, and reachability assessment. Classification by milestone alone is INCOMPLETE.

See references/skia-cve-resolution.md for the full process, including:

• NVD query (keywordSearch=Skia)
• Bug ID extraction from issues.chromium.org/issues/NNNNN references
• git fetch upstream chrome/mNNN + git log --grep=<bug_id> to find fix commits
• Branch ancestry verification (our milestone? our tree?)
• Cherry-pick feasibility test
• Reachability through SkiaSharp C API
• Non-Chrome CVEs (Android / vendor bulletins)
• Required output fields per CVE

Step 6: Audit Third-Party Dependency CVEs

For libpng, freetype, harfbuzz, libexpat, brotli, zlib, libjpeg-turbo, libwebp, ANGLE submodules, etc.

See references/third-party-deps.md for:

• Web/NVD search queries
• Version verification (DEPS commit + header files)
• Fix-commit ancestry check (git merge-base --is-ancestor)
• NVD version range errors (e.g., CVE-2025-27363 / FreeType)
• Known false positives (MiniZip, FreeType's bundled zlib)