Fix Security Vulnerability Skill

Analyze Dependabot security alerts and propose fixes for the sentry-changelog Next.js app. Does NOT auto-commit - always presents analysis first and waits for user approval.

Input

•Dependabot URL: https://github.com/getsentry/sentry-changelog/security/dependabot/12
•Or just the alert number: 12

Workflow

Step 1: Fetch Vulnerability Details

bash

gh api repos/getsentry/sentry-changelog/dependabot/alerts/<alert-number>

Extract: package name, vulnerable/patched versions, CVE ID, severity, description.

Step 2: Analyze Dependency Tree

bash

pnpm why <package-name>

Determine if it's a direct or transitive dependency, and whether it's production or dev.

Step 3: Determine Fix Strategy

Check for pinned dependencies

Some dependencies are intentionally pinned due to compatibility constraints. Check package.json comments (the "//" field) for pin reasons before bumping.

Known pins:

•google-auth-library - Pinned to v9.x to match @google-cloud/storage's bundled version (v10.x breaks Vercel OIDC auth)

For other dependencies

Type	Action
Patch bump available	Preferred - lowest risk
Minor bump needed	Usually safe
Major bump needed	Analyze breaking changes first
Transitive dependency	Bump the parent package (see below)

Step 3a: Transitive Dependencies

If the vulnerable package is pulled in by another package:

1. Identify and check the parent:

bash

pnpm why <vulnerable-package>
npm view <parent-package>@latest dependencies.<vulnerable-package>

2. Fix approach:

Scenario	Action
Parent has newer version with fix	Bump the parent
Parent hasn't released fix	Wait, or open an issue upstream

AVOID pnpm.overrides. Forcing a transitive dependency version can break the parent package silently. Only consider overrides if:

•No upstream fix exists AND it's a production-critical vulnerability
•The forced version is a patch/minor bump (not major)
•You've manually verified compatibility

Step 4: Present Analysis

Present findings and wait for user approval before making changes:

code

## Security Vulnerability Analysis

**Package:** <name> | **Severity:** <severity> | **CVE:** <id>
**Vulnerable:** <range> | **Patched:** <version>

### Dependency Chain
<pnpm why output>

### Recommendation
<One of: Safe to bump / Intentionally pinned - do not bump / Bump parent package>

### Proposed Fix
1. Update package.json: "<package>": "<new-version>"
2. pnpm install
3. Verify with: pnpm why <package>

Proceed?

Step 5: Apply Fix (After Approval)

bash

# 1. Edit package.json
# 2. Update lockfile
pnpm install
# 3. Verify
pnpm why <package>
# 4. Run tests
pnpm test:run
# 5. Show changes
git diff

Do NOT commit - let the user review first.

Step 5 (Alternative): Dismiss Alert

For alerts that should not be fixed, offer to dismiss instead.

Always get user approval first. Present the dismissal option:

code

This alert should be dismissed rather than fixed because:
- <reason: intentionally pinned / dev-only acceptable risk / etc.>

Dismiss with reason: <suggested reason>
Comment: "<suggested comment>"

Proceed with dismissal?

After user approval, dismiss via GitHub API:

bash

gh api --method PATCH repos/getsentry/sentry-changelog/dependabot/alerts/<number> \
  -f state=dismissed \
  -f dismissed_reason=<reason> \
  -f dismissed_comment="<comment>"

Dismissal reasons:

Reason	When to use
`tolerable_risk`	Dev-only dependency, risk accepted
`no_bandwidth`	Will fix later, not urgent
`inaccurate`	False positive, not actually vulnerable
`not_used`	Vulnerable code path is not used in our code

Commands Reference

Command	Purpose
`pnpm why <pkg>`	Show dependency tree
`gh api repos/getsentry/sentry-changelog/dependabot/alerts/<n>`	Fetch alert
`gh api --method PATCH .../dependabot/alerts/<n> -f state=dismissed -f dismissed_reason=<reason>`	Dismiss alert
`npm view <pkg>@latest dependencies.<dep>`	Check transitive dep version
`pnpm test:run`	Run tests

Examples

Direct dependency - safe to bump

code

Package: contentful
Severity: moderate
Type: Production dependency (direct)

Recommendation: Safe to bump 10.15.0 → 10.16.0
- Patch version, low risk
- No breaking changes expected

Pinned dependency - dismiss instead

code

Package: google-auth-library
Severity: high

Recommendation: DISMISS (do not bump to v10.x)
This package is intentionally pinned to v9.x for compatibility
with @google-cloud/storage's bundled ExternalAccountClient.
Bumping to v10.x breaks Vercel OIDC authentication.

Proposed dismissal:
  Reason: tolerable_risk
  Comment: "Pinned to v9.x for @google-cloud/storage compat - see package.json comments"

Proceed with dismissal?

Transitive dependency - bump parent

code

Package: vulnerable-lib@1.9.0 (needs >=2.0.1)
Chain: @sentry/nextjs → @sentry/node → vulnerable-lib

Check: npm view @sentry/nextjs@latest dependencies
Result: Uses patched version ✓

Recommendation: Bump @sentry/nextjs 10.32.1 → 10.33.0
This pulls in the patched vulnerable-lib automatically.

Transitive dependency - no fix available

code

Package: deep-lib@2.9.0 (needs >=3.0.0)
Chain: next → some-pkg → deep-lib

No upstream fix available yet. Options:
1. Wait for upstream fix (preferred)
2. Accept risk if dev-only
3. Consider pnpm.overrides as last resort for production-critical issues

AVOID using overrides unless absolutely necessary.

Important Notes

•Never auto-commit - Always wait for user review
•Check pin reasons - Some deps are pinned for compatibility (see "//" in package.json)
•Dev vs Prod matters - Dev-only vulnerabilities are lower priority
•Bump parents, not transitive deps - If A depends on vulnerable B, bump A
•Avoid pnpm.overrides - They bypass the parent's dependency constraints and can cause subtle breakage
•Always verify - Run pnpm why <pkg> after fixing to confirm the patched version is installed
•Run tests - Run pnpm test:run after fixing to make sure nothing broke