Become a design partner
How it worksAdvisoriesSecurityPricingDocs Become a design partner

How it works

One pipeline, from disclosure to pull request.

Advisories are read once, centrally, and checked against the Apps that have the package. You don’t run monitoring, poll feeds or triage alerts. You get Verdicts, Upgrades and a weekly digest.

  1. 01

    Ingest

    Every new Advisory for Packagist and npm, from OSV and the GitHub Advisory Database, with aliases merged. Disclosures often start as a blog post or vendor page with no ID; paste the link and it becomes a Provisional profile until the OSV record exists. Withdrawn Advisories are dropped. Disputed ones are shown with the dispute.

  2. 02

    Advisory profile

    Each Advisory is analysed once, for everyone: what’s vulnerable, what must be true in an App to be affected, what the fix changed, and how to check. A person approves every profile before it’s published on this site.

    Browse profiles
  3. 03

    Match

    Your App’s installed versions are compared with the Advisory’s affected range. A Match is a fact, not a judgement, and on its own it never reaches you. Lockfile changes reach us through the GitHub App, so the comparison is always current.

  4. 04

    Assessment

    For each Match, we check the profile’s conditions against your code: is the vulnerable function called, is the extension enabled, does untrusted input reach it. The Assessment runs in a single-use worker and ends in a Verdict with file:line evidence.

  5. 05

    Upgrade

    When the Verdict can’t rule the Advisory out, we open a pull request that moves the package to a fixed version, with the Verdict and evidence in the body. Your CI runs, a person reviews, and you merge.

  6. 06

    Digest

    One weekly summary: how many Advisories were handled, how many don’t affect you and why, and which Upgrades are waiting. Real-time alerts only for a confirmed exploit or an installed malicious package.

Verdicts

What each Verdict means, and what happens next.

VerdictMeansYou get
Not affected The evidence shows the Advisory can’t be triggered in this App. The reason and its file:line evidence. Re-checked when that code changes.
Reachable – unproven Untrusted input reaches the vulnerable code. Not proven exploitable, so not a Vulnerability, but treated as affected. An Upgrade pull request with the evidence in the body.
Inconclusive We couldn’t determine it either way, for example because it depends on server config outside the repository. Exactly what we couldn’t determine, so you know the one thing to check.

Limits

What agentprime won’t do.

  • Merge for you

    Every Upgrade is a pull request. A person on your team merges it.

  • Call something a Vulnerability without proof

    Until we can prove exploitability, the strongest thing we say is Reachable – unproven.

  • Alert you about a Match

    Having a version in range isn’t news. A Verdict is.

  • Touch your running systems

    We read your code. We never send anything at your staging or production environments.

Roadmap · not available yet

Where it goes next.

Everything above works today. Everything below doesn’t yet, and we won’t describe it as if it does.

  1. Roadmap

    Proof in a Sandbox

    Run your App from source in an isolated Sandbox and prove exploitability before anything is called a Vulnerability, adding an Exploitable Verdict.

  2. Roadmap

    Retested Fixes

    For proven Vulnerabilities, a change that’s retested in the Sandbox until the exploit no longer works, including when no fixed version exists.

  3. Roadmap

    Logic flaws in your own code

    Broken access control and injection, found and proven with the same machinery.

  4. Roadmap

    More stacks

    Rails and Python, each once it holds up on real repositories.