# Self-assessment: how exposed are you to the next CVE, and to your own coding agents? 13 questions in 5 pillars, about four minutes, for teams of roughly 10 to 200 people. Each answer scores 100, 67, 33 or 0; “Not sure” scores 0. Nothing is stored: the result is a link. To score a set of answers, open `https://agentprime.io/assessment/result/?a=` (or `https://agentprime.io/assessment/result.md?a=` for Markdown). The code is `1` followed by one letter per question, in the order below: `a`, `b`, `c` or `d` for the answers as listed, `n` for Not sure. For example `?a=1bbbbbbbbbbbbb`. ## Know what you run Every dependency in every app, pinned and listed, so a CVE can be checked against it. ### 1. Are your lockfiles committed, and do they match what you ship? A lockfile pins every package, direct and transitive. Without one, nobody can say which versions are installed. - `a` (100): Yes. Every app commits one, and CI fails when it’s out of date. _Every build installs exactly what was reviewed._ - `b` (67): Every app commits one, but nothing checks it’s current. _Close. A stale lockfile can drift from what really ships._ - `c` (33): Some apps have one, some don’t. _Apps without one install whatever is newest on the day._ - `d` (0): We don’t commit lockfiles. _Nobody can say which versions run, so no alert can be checked._ - `n` (0): Not sure. _If you can’t say, a customer asking can’t be told either._ Why it matters: A CVE names versions. Without a lockfile you can’t tell whether yours is one of them, and two builds of the same commit can install different code. What to do: Commit the lockfile in every app, and install with a frozen lockfile in CI (npm ci, pnpm install --frozen-lockfile, poetry check --lock) so a stale one fails the build. ### 2. Could you list every dependency across all your apps today? Every repository, service and script that ships, including the ones nobody has touched in a year. - `a` (100): Yes. Every lockfile is watched, and new repositories are added as they’re made. _When a CVE lands, you already know where to look._ - `b` (67): For our main apps, yes. Older services and scripts, less so. _The forgotten service is often the one on an old version._ - `c` (33): Only by asking around or opening each repository. _An hour spent searching is an hour not spent fixing._ - `d` (0): No. _You’d learn you were affected from someone else._ - `n` (0): Not sure. _Not knowing where your code is means not knowing what it runs._ Why it matters: Exposure hides in the apps nobody watches. One list of every lockfile turns “are we affected?” into a search instead of a project. What to do: Keep one list of every repository that ships, with its lockfile, and have something watch them all for new Advisories. agentprime checks a lockfile in your browser, and a free account watches up to 10 and emails you when a new Advisory matches. [Check and watch a lockfile](https://agentprime.io/check/) ## Separate signal from noise Telling which alerts affect you, acting on what attackers use, and writing down why. ### 3. When a dependency alert arrives, how do you decide whether it matters? Dependabot, npm audit and similar tools flag versions. Most flagged versions can’t be reached from your code. - `a` (100): We check whether our code uses the affected part, and act on what it does. _Effort goes where the risk is._ - `b` (67): By severity: we act on critical and high. _Sensible, but a score doesn’t know how you use the package._ - `c` (33): Whoever sees it decides. There’s no shared rule. _Two people, two answers, and nobody knows which was right._ - `d` (0): Mostly we don’t. There are too many. _When every alert is ignored, the real one is too._ - `n` (0): Not sure. _If nobody knows how alerts are handled, they probably aren’t._ Why it matters: Most alerts don’t affect your app: the affected function is never called, or the feature is off. Treating every alert the same buries the few that do. What to do: Agree one rule: for each alert, check whether your code reaches the affected function or feature, and act on those first. The agentprime plugin for Claude Code does that check and shows the file and line. [Check your code with the plugin](https://agentprime.io/plugin/) ### 4. When you decide an alert doesn’t apply, do you write down why? A dismissed alert with no reason looks the same as one nobody read. - `a` (100): Yes, with what we checked, and we look again when that code changes. _Anyone can see why, months later._ - `b` (67): Usually, as a short comment. _Good. Make sure it says what was checked, not just “n/a”._ - `c` (33): We dismiss them without a reason. _Next time, the same alert is triaged from scratch._ - `d` (0): We don’t dismiss them. They pile up. _A long list of open alerts hides the ones that matter._ - `n` (0): Not sure. _An unexplained dismissal can’t be told apart from a mistake._ Why it matters: A written reason saves the next person the same work, and it’s what a customer or auditor will ask for. Without one, a dismissed alert can’t be told apart from an ignored one. What to do: When you dismiss an alert, say what you checked and why it doesn’t apply (“we never call parseQuery; checked src/api”). GitHub’s dismissal reason and comment are enough to start. Look again when that code changes. ### 5. Do actively exploited issues jump the queue? CISA’s KEV catalogue lists CVEs that attackers are known to be using. - `a` (100): Yes. We’re told when a CVE we have is added to KEV, and it’s fixed first. _You act on what attackers actually do._ - `b` (67): We check KEV when we remember to. _Listings arrive any day. Checking by hand misses some._ - `c` (33): We know KEV exists, but we don’t use it. _A medium issue under attack can wait behind a critical one that isn’t._ - `d` (0): We don’t look at whether something is exploited. _Severity alone ranks risk in theory, not by what’s happening._ - `n` (0): Not sure. _If nobody is watching for it, a KEV listing goes unnoticed._ Why it matters: Attackers use a small share of published CVEs. Knowing which ones they’re using now is the best single signal for what to fix first. What to do: Put Matches that are in KEV, or are malicious packages, at the top of the queue with a same-day target. agentprime flags every KEV listing in its critical feed, and a watched lockfile emails you right away when one matches. [See what’s critical now](https://agentprime.io/advisories/critical/) ## Fix fast, safely Getting real fixes into production quickly, transitive ones included, without merging blind. ### 6. When a critical issue really affects you, how long until the fix is in production? From the moment you know to the moment it’s deployed. - `a` (100): A day or two at most. _A known issue rarely sits in production for long._ - `b` (67): About a week. _Fine for most issues. Too slow for one under attack._ - `c` (33): It depends who’s free. Weeks, sometimes. _The fix waits on whoever has time, not on the risk._ - `d` (0): Often months, or we don’t track it. _A known, fixable issue sits in production._ - `n` (0): Not sure. _What isn’t measured tends to drift._ Why it matters: Once a CVE is public, so is its fix, and so is what the fix changed. The time between knowing and deploying is time exposed to something anyone can read about. What to do: Set a target, say two days for anything critical that your code reaches and the same day for anything actively exploited, and track it. Keep deploys quick enough that a one-line upgrade isn’t a big release. ### 7. How are dependency bump PRs from bots and coding agents reviewed? Dependabot, Renovate and coding agents open upgrade PRs. Who checks them, and how? - `a` (100): Like any PR: tests run, someone reads the changelog for bigger jumps, and they merge within days. _Upgrades keep moving and stay reviewed._ - `b` (67): Tests run, and green ones get merged after a quick look. _Fine for patches. A major version can pass tests and still change behaviour._ - `c` (33): They pile up and get merged in batches now and then. _Batches are hard to review and hard to roll back._ - `d` (0): They’re mostly ignored, or merged without review. _Ignored bumps leave issues in place; blind merges let anything in._ - `n` (0): Not sure. _An unowned queue of bot PRs only grows._ Why it matters: A bump PR is a code change from outside your team. Left open, it leaves the issue in place. Merged blind, it trusts whatever the new version does, including a hijacked release. What to do: Auto-merge only patch updates that pass tests, review minor and major ones like any other change, and give the queue a weekly slot so it never grows. Check that a bump actually clears the Advisory it was opened for. ### 8. When the issue is in a transitive dependency, can you fix it? Most of what you install is a dependency of a dependency. Its fix often waits on someone else. - `a` (100): Yes. We force a fixed version (an override or resolution) and test it. _You don’t have to wait for a maintainer._ - `b` (67): Usually, by upgrading the direct dependency that pulls it in. _Works when that release exists. Have a plan for when it doesn’t._ - `c` (33): We wait for the direct dependency to ship a fix. _That can take weeks, and it isn’t up to you._ - `d` (0): We don’t look at transitive dependencies. _Most of what you install is out of sight._ - `n` (0): Not sure. _Most alerts are transitive, so this is most of the work._ Why it matters: Most installed packages are transitive. If the only way to fix them is to wait for each maintainer up the chain, your time to fix isn’t yours to control. What to do: Learn your package manager’s override (npm and pnpm overrides, Yarn resolutions, a direct pin in Python, a replace in Go) and use it when the parent hasn’t caught up. agentprime’s lockfile check gives the lowest version that clears each Match. [Get an upgrade plan for a lockfile](https://agentprime.io/check/) ## Guard your coding agents What your agents can install, which tools they can call, and what their credentials can reach. ### 9. Can your coding agents add new packages without anyone checking? Agents add dependencies to solve problems. A name that looks right can be brand new, a look-alike, or malicious. - `a` (100): No. A new dependency is checked before it’s added, and called out in review. _A look-alike or brand-new package gets a second look._ - `b` (67): Agents can add them, but every new dependency is called out in review. _Good, but install scripts run on the machine before review._ - `c` (33): Agents add what they need. We might notice it in the diff. _One new line in a lockfile is easy to miss._ - `d` (0): Yes, and agents run installs on their own. _A malicious package runs its install script before anyone looks._ - `n` (0): Not sure. _If you don’t know what agents may install, assume anything._ Why it matters: Coding agents pick packages by name, and some names they suggest don’t exist yet or belong to someone else. A malicious package can run code at install time, on a machine that holds your credentials. What to do: Make installs ask for approval in your agents’ settings, flag new dependencies in review, and check a package before adding it: how old it is, who maintains it, and whether it’s known to be malicious. agentprime’s MCP server lets an agent check packages against every Advisory and known malicious package before it adds them. [Connect your agent to agentprime](https://agentprime.io/mcp/) ### 10. Which MCP servers and tools can your agents use, and who decides? Every MCP server or tool you connect can read what the agent reads, and act with its access. - `a` (100): A short, reviewed list. Adding one needs approval, and we know what each can reach. _Every tool an agent can call has been looked at._ - `b` (67): There’s a shared list, but anyone can add to it. _A list helps. Without review, it only grows._ - `c` (33): Each developer picks their own. _Nobody knows the full set of tools touching your code._ - `d` (0): We don’t know which ones are connected. _A tool nobody chose may be reading your repository._ - `n` (0): Not sure. _The tools you don’t know about are the ones nobody reviewed._ Why it matters: An MCP server sees what the agent sees: code, files, sometimes secrets. What it returns can also steer the agent. One unreviewed server can reach everything the agent can. What to do: Keep a shared list of approved MCP servers and tools in the repository’s agent settings, where your agent supports it. Before adding one, check who publishes it, what it can reach, and whether it runs locally or remotely. Remove the ones nobody uses. ### 11. What credentials can your coding agents use? Tokens in the environment, cloud keys, SSH keys, a signed-in CLI: whatever the agent’s shell can reach. - `a` (100): Only short-lived, narrowly scoped ones, made for the job. _A leak would be small, and short._ - `b` (67): Developers’ own credentials, but nothing for production. _Better than most. A developer’s token can still reach a lot._ - `c` (33): Whatever is on the developer’s machine, production included. _Anything the agent runs can use them too._ - `d` (0): Long-lived, broad tokens, shared between people or tools. _One leak, and someone else holds the keys for months._ - `n` (0): Not sure. _Unknown credentials are the ones nobody rotates._ Why it matters: Anything the agent runs, an install script included, can use the credentials in its environment. Broad, long-lived tokens turn a small mistake into a big one. What to do: Give agents their own scoped, short-lived tokens (read-only where you can), keep production secrets out of developer and agent environments, and rotate anything that’s been shared. Run agents in a container or sandbox when they don’t need your machine. ## Respond when it’s real Answering “are we affected?” within the hour, and showing customers how you handle it. ### 12. When a big CVE breaks, could you say within an hour whether you’re affected? The next one like Log4Shell lands on a Friday afternoon, and someone asks: are we affected? - `a` (100): Yes. We’d search every app’s dependencies, then check whether our code uses the affected part. _You’d answer with facts, not a guess._ - `b` (67): We’d know which apps have the package. Whether it affects us would take longer. _Half the answer, fast. The other half is where the time goes._ - `c` (33): It would take a day or more of asking around. _Meanwhile, the question keeps being asked._ - `d` (0): We couldn’t say with confidence. _You’d be guessing, and so would your customers._ - `n` (0): Not sure. _Most teams find out the first time it happens._ Why it matters: The first question after a big disclosure is always the same. Answering it quickly, with evidence, is what lets you fix the real cases and reassure everyone else. What to do: Keep every lockfile watched so the package search takes seconds, then check reachability only in the apps that have it. Rehearse once: pick a recent CVE and time the answer. With agentprime’s MCP server, an agent can look the CVE up and check every lockfile it can open. [Ask your agent “are we affected?”](https://agentprime.io/mcp/) ### 13. When a customer or auditor asks how you handle dependency risk, what can you show them? Security questionnaires, SOC 2 and enterprise deals all ask. - `a` (100): Records: what we run, the alerts we had, what we decided and when we fixed it. _The answer is already written down._ - `b` (67): A written policy, and we could dig out examples. _A policy says what you intend. Records show what you did._ - `c` (33): We’d write something up when asked. _Answers written to a deadline tend to promise more than you do._ - `d` (0): Nothing yet. _Deals and audits stall on this question._ - `n` (0): Not sure. _Someone may already have answered for you._ Why it matters: Customers and auditors ask how you handle the code you didn’t write. Records you already keep (alerts, decisions with reasons, fix dates) answer that better than a policy written for the occasion. What to do: Keep the records as you go: the dependency list for each app, every alert’s decision with its reason, and fix dates. A short page with your rules (what you fix first, and how fast) plus those records answers most questionnaires. ## How the score works Each pillar’s score is the average of its answers. Your score is the average of the five pillar scores, so each pillar counts the same, rounded to a whole number. - **Exposed** (0 to 39): The next big CVE would likely find you before you found it. - **Reactive** (40 to 64): You deal with issues as they reach you, but a lot rests on who’s around. - **Managed** (65 to 84): The basics are in place, and you have a real process. - **Ahead** (85 to 100): You know what you run, act on what matters, and keep your agents in check. Your top three gaps are your lowest-scoring answers (in question order when scores tie), each with why it matters and what to do. This is a self-assessment from your own answers: a starting point, not an audit. A high score doesn’t mean you’re safe. --- The web page: . Everything for agents: .