TechnicalCollectible prompt

Dependency vulnerability audit with an update plan

Find vulnerable and abandoned packages, fix what's actually exploitable, and update in safe steps.

Claude CodeCodexGitHub Copilot

Curated by Nvoka

Nvoka wordmark logo
Nvoka wordmark logoTechnical

Dependency vulnerability audit with an update plan

Act as a senior engineer responsible for supply-chain security. Audit the dependencies in my {{tech_stack}} project. Before changing anything, read the manifests and lockfiles and tell me the package manager and how many direct and indirect dependencies we have. 1. Scan with the package manager's audit command and a second source, such as OSV-Scanner or GitHub Dependabot alerts. 2. Triage each finding instead of counting them: is the package used in production, or only in development and build tools? Is the vulnerable code reachable from how we use it? Is there a known exploit? Rank by real risk, not the scanner's label. 3. Also flag: packages unmaintained for 2 years or more, deprecated packages, unused dependencies (check with a tool like knip or depcheck), suspicious install scripts, look-alike package names, and several versions of the same library. 4. Update plan, in this order: - Patch and minor updates in one batch, then run the build and tests - Major updates one at a time: read the changelog, list breaking changes that touch our code, update, test - Replace abandoned packages, or remove ones we barely use - If no fix exists, document the workaround and when to check again 5. Keep it fixed: commit the lockfile, install from the frozen lockfile in CI, fail CI on high or critical findings in production dependencies, and set up Dependabot or Renovate for weekly grouped updates. Never run a forced audit fix blindly, never delete the lockfile to make warnings disappear, and never ignore a finding without a written reason. Return a table: package, current and target version, issue, real risk, action and status. Then the commits made, the tests run, and anything waiting on me.
Technicalnvoka.com/library/nvoka-dependency-vulnerability-audit-and-update-planScan to open
Technical

Dependency vulnerability audit with an update plan

Find vulnerable and abandoned packages, fix what's actually exploitable, and update in safe steps.

Nvoka logo

Curated by Nvoka

Claude CodeCodexGitHub CopilotCursor
Add to my library

Make it yours

Fill in the blanks and change any word. Only your copy changes, never the card.

Fill in the blanks

0 of 1 filled

Your prompt

Act as a senior engineer responsible for supply-chain security. Audit the dependencies in my {{tech_stack}} project. Before changing anything, read the manifests and lockfiles and tell me the package manager and how many direct and indirect dependencies we have. 1. Scan with the package manager's audit command and a second source, such as OSV-Scanner or GitHub Dependabot alerts. 2. Triage each finding instead of counting them: is the package used in production, or only in development and build tools? Is the vulnerable code reachable from how we use it? Is there a known exploit? Rank by real risk, not the scanner's label. 3. Also flag: packages unmaintained for 2 years or more, deprecated packages, unused dependencies (check with a tool like knip or depcheck), suspicious install scripts, look-alike package names, and several versions of the same library. 4. Update plan, in this order: - Patch and minor updates in one batch, then run the build and tests - Major updates one at a time: read the changelog, list breaking changes that touch our code, update, test - Replace abandoned packages, or remove ones we barely use - If no fix exists, document the workaround and when to check again 5. Keep it fixed: commit the lockfile, install from the frozen lockfile in CI, fail CI on high or critical findings in production dependencies, and set up Dependabot or Renovate for weekly grouped updates. Never run a forced audit fix blindly, never delete the lockfile to make warnings disappear, and never ignore a finding without a written reason. Return a table: package, current and target version, issue, real risk, action and status. Then the commits made, the tests run, and anything waiting on me.
See all