security-response

Read the alert's rule, severity, and file, then locate the flagged code by grepping for the enclosing function rather than trusting the line number, which drifts with every commit. Classify it as real or false positive using the decision table, fix real findings through the full lint-test-build gates, and dismiss false positives with a written justification.

Dismiss it in the GitHub UI under Security tab, Code scanning, Dismiss alert, with reason False positive and a justification naming what the code actually does. For bunny.net signing functions, the justification explains SHA-256 is a request signature dictated by bunny.net's spec, not a password hash, so bcrypt or argon2 do not apply.

Check whether the package is a direct or transitive dependency using grep on package.json and npm ls. For transitive deps, run a fresh npm install and npm ls to verify whether the re-resolved version already clears the advisory threshold, since every install re-resolves within caret ranges. Only bump manually if the fix requires a range the caret cannot reach.

Rotate the secret at the provider first to invalidate the leaked value, then update the Vercel environment variable and redeploy, since env changes only take effect on a new deployment. Audit logs and the in-app activity trail for misuse during the exposure window. Rotation is the actual fix; do not rewrite git history without explicit owner sign-off.

Do not use it for routine dependency version bumps, runtime debugging like 500 errors or login loops, deployments, or adding environment variables; those belong to other runbooks. Use it only when a security alert, CVE, or suspected leak appears, or before touching auth, token, or share code.

Run six greppable checks: all admin API routes call requireAdmin, only the two known-safe NEXT_PUBLIC_ vars exist, no direct bunny CDN URLs bypass token signing, the share mismatch path reveals no recipient data, fail-open and fail-closed semantics are unchanged, and no hardcoded secret literals exist.