Dependency advisories, sorted by what touches you
by AGNTOfficialAgent template
An agent reads the security updates Dependabot or Renovate opens, searches your code for the affected package, and tells you which advisories actually reach code you run.
Opens in AGNT and takes about a minute.
Didn’t open? AGNT may not be installed here yet. Download AGNT free · Download the .json
- 2
- Tools connected
- ~10 min
- Setup, 4 steps
- Local
- Runs on your machine
- Per category
- You approve
- Any model
- Uses the one you have
What the agent actually does
The three that matter, out of thirty
Most advisories concern a function you never call, in a package that only runs in your test suite. The agent reads each one and checks your repository for usage, so the short list it posts is the list worth your afternoon.
Evidence, not a verdict
For each advisory you get the affected package and versions, where the package is imported, whether that code runs in production or only in development, and the CI status of the update. “No usage found” is reported as exactly that, with the search it ran.
Built on what GitHub already raises
It works from the pull requests Dependabot or Renovate open, which carry the advisory text and the fixed version. There is no separate scanner to install and no second vulnerability database to keep in sync.
The tools this job needs
GitHub
Where the work arrives. Where the code — and half the process — lives. The agent watches it and reads what turns up in full, rather than matching a rule against a subject line.
Slack
Where the result lands. Team chat where operations actually surface. Nothing is written here until the agent has formed a view and, where you asked for it, you have approved it.
The brief it works from
This is the actual instruction set the template installs — what the agent is told to do, and what it is told never to do. Every line of it is yours to edit in AGNT after install.
Read the full brief
You triage security updates so the urgent one is not buried among routine bumps.
Where advisories come from
You work from pull requests opened by Dependabot or Renovate in the repositories the user named. Their descriptions carry the advisory: package, affected versions, fixed version, severity, and often the vulnerable function. If a repository has no such pull requests, say so — do not invent advisories, and do not claim the repository is clean.
For each update
1. Read the pull request body and the changed manifest or lockfile. 2. Search the repository code for imports and uses of the affected package, and of the vulnerable function when the advisory names one. 3. Decide where those uses live: production code, build tooling, tests, examples. Use the directory guidance the user gave you. 4. Read the check runs on the pull request so you can say whether the update builds.
Rank by reachability
- Act today: the package ships in production and your code calls the affected path, or the advisory names no function and the package is used in request-handling code. - Schedule: production dependency, no direct use of the affected path found. - Routine: development or test only. State the evidence for each: file paths, the search you ran, what you could not rule out.
Search is evidence, not proof
Code search cannot see dynamic imports, reflection or transitive callers. Write "no direct usage found" — never "safe" or "not affected".
Report
Post one Slack message per run: the act-today items first, then counts for the rest, each linking its pull request. When the user has asked for it, comment the same finding on the pull request.
Boundaries
Never merge, close, approve or rebase a pull request. Never edit code, branches or manifests. Never downgrade or dispute the severity the advisory states; you add context, you do not overrule it.
Shown exactly as it ships. The agent inherits whichever model you already use.
Severity scores describe the package, not your system
A critical rating means the flaw is serious for somebody using the vulnerable code path. Whether that somebody is you depends on whether you call that function, whether the package ships in production, and whether untrusted input ever reaches it. The score cannot know any of that; a search of your own repository can begin to. That is the gap the agent fills — not by second-guessing the advisory, but by putting your code next to it.
Why update pull requests pile up
Automated update tools are good at opening pull requests and bad at explaining which ones are urgent. A queue of twenty identical-looking bumps teaches a team to merge them in bulk on a quiet day, or to ignore them altogether. Either way the one that needed same-day attention waits with the rest. Ranking them by reachability, with the reasoning written down, turns the queue back into a decision somebody can make in minutes.
Search is evidence, not proof
Code search finds imports and call sites; it cannot see reflection, dynamic requires or a transitive dependency calling the vulnerable function on your behalf. The agent says which of those it could and could not rule out. An advisory marked “no direct usage found, transitive use possible” is honest and actionable. One marked “safe” would be neither.
Common questions
Will it merge the updates?
No. It reads, searches and reports. Merging, closing or approving pull requests stays with your team, and the agent never changes the severity an advisory states.
Do I need Dependabot?
You need something that opens security update pull requests — Dependabot or Renovate. The agent reads those; it does not run its own vulnerability database.
Which languages does it handle?
Any ecosystem whose dependencies sit in a manifest the update tool understands — npm, pip, Maven, Go modules, Cargo and the rest. The usage search is a plain code search, so it works across languages.