rn-dependency-audit

name	rn-dependency-audit
description	Audit the dependency tree of an Expo React Native project for known CVEs, outdated packages, license compliance issues, lockfile tampering, and supply-chain risks specific to native modules. Apply ONLY when the task is a dependency-focused security or compliance review — vulnerability triage, pre-submission license check, response to a CVE disclosure, or lockfile diff review. Do NOT apply for routine `npm install`, package additions, or version bumps that are part of normal feature work.
metadata	{"owner":"rn-builder","status":"stable"}

rn-dependency-audit

Purpose

Treat the package.json + lockfile as an attack surface in its own right. RN projects pull hundreds of transitive deps; any one of them can carry a CVE, an incompatible license that blocks store submission, or a malicious post-install script. Native modules add a second layer: native code from npm runs at app launch with full app permissions.

This skill is defensive only — it triages and remediates. It does not generate malicious packages, typosquats, or supply-chain attack code.

When to Apply

Use this skill ONLY when:

• User explicitly asks for a "dependency audit", "CVE check", "license audit", or "supply chain review"
• User received a Dependabot / Snyk / GitHub Advisory alert and wants triage
• User is preparing for App Store / Play Store submission and wants a license-compliance pass
• A new native module is being added and the user explicitly asks "is this safe to add?"
• Lockfile drift in a PR review needs validation

Do NOT use this skill when:

• The task is "install package X" → just install it, no audit needed
• The task is a routine version bump → use upgrading-react-native for RN itself, otherwise just bump
• The task is a CVE in the app's own code, not deps → use ../rn-security-audit/SKILL.md
• The task is a backend dep audit → hand off to Security Engineer

Problem → Reference

Task	Read
Triage npm audit / Dependabot findings	cve-triage.md
License compliance scan before store submission	license-compliance.md
Lockfile integrity check after a PR or merge	lockfile-integrity.md
Vet a new native module before adding	native-module-vetting.md
Set up CI to catch regressions	ci-integration.md

Default Audit Order

When the user asks for a general "dependency audit":

1. CVE scan (cve-triage.md) — npm audit + osv-scanner, classify each finding by reachability.
2. License scan (license-compliance.md) — find GPL/AGPL/SSPL contamination that blocks store distribution.
3. Lockfile integrity (lockfile-integrity.md) — verify no unexplained registry/version drift.
4. Native module spot check (native-module-vetting.md) — for any native dep added since last audit.

Stop after each step and report. Do not auto-bump versions without user approval — a "fix" can break the app or shift transitive deps in unwanted ways.

Reporting Format

Finding: <package>@<version>
Type: CVE | License | Lockfile | Supply-chain
Severity: Critical | High | Medium | Low
Reachable: Yes | No | Unknown
Evidence: <CVE ID / license / registry mismatch / install script>
Impact: <what an attacker gains or what blocks shipping>
Remediation: <bump to X, replace with Y, remove, or accept with note>
Verification: <command that confirms remediation>

"Reachable" matters because a CVE in a transitive dep that the RN runtime never invokes is far lower risk than one in the auth flow. Always classify before recommending an upgrade.

What This Skill Does NOT Cover

• Yarn Berry / Bun-specific tooling — covered patterns assume npm or yarn classic, which are the EAS defaults. Flag if the project uses something else and adapt.
• iOS Pods / Android Gradle deep CVE analysis — pod outdated and Gradle's verification metadata are out of scope; the RN-native-module-vetting reference handles the entry points, but deep native-side analysis routes to Security Engineer.
• License legal interpretation — surfaces what's there. The user / legal team interprets gray areas (e.g. is your closed-source RN app "linking" LGPL dependencies in a problematic way).
• General code review of dep usage — covered by Code Reviewer agent.

Verification

Audit is complete when:

1. Every step above has been run or explicitly skipped with reason.
2. Every Critical/High finding has either a merged remediation or an explicit user acknowledgement.
3. CI is wired to prevent the same class of finding from re-appearing (see ci-integration.md).
4. The user has a summary they can attach to a security questionnaire or release checklist.