CONTEXT(CLONE)
Sign in

Dependency advisory watch with reachability evidence

For: Application security engineer or platform owner handling vulnerability advisories across many repositories

Pattern: WatchtowerNeeds a connectorDesigned for 10 to 400 agents
Get early accessSign in to use

The pain today

Advisories arrive daily and most do not matter, because the vulnerable function is never called. Every one still costs a triage, and the one that matters waits in the queue with the rest.

The ask

“Watch the advisory feeds for the packages in our connected repositories. When a new advisory lands, tell me which services pull in the affected version and whether our code calls the affected part, and show the lines. Only redo the services it touches.”

Plain words, as you would say it to a colleague. Edit it to fit your case before you send it.

What you attach or connect

  • Vulnerability advisory feeds
  • Repositories and lockfiles through source control
  • Service ownership and internet exposure map
  • Severity and patching policy

The unit of work

One worker task per one advisory against one service using the package.

Why a swarm fits

Advisories and services form independent pairs. A new advisory invalidates only the services that resolve that package, so most of the estate is never re-read.

Not for

One repository with a handful of packages: the built-in scanner alerts are enough.

The decision tree

5 typed decisions, each with an action for every answer

At fixed moments in a run, the engine puts one narrow question to a decision model. The decision model never writes text: it answers yes or no with a probability, picks from listed options, or gives a score, about a small slice of the material. The engine then does exactly what this tree says, which is what makes the run auditable. The thresholds are the template's design values, not measured results.

  1. Run control, between rounds

    Another round?Yes or no, with a probability

    Between rounds

    Has this service's lockfile entry for the package, or the advisory's text, changed since the pair was last checked?

    Sees only: The previous and current lockfile entry and advisory revision for one pair

    Why: Unchanged pairs are not re-read, which is what keeps a daily watch affordable.

    • Yes: 0.50 or higherthenContinue
    • Unsure: 0.20 up to 0.50thenContinue
    • No: below 0.20thenStop

  2. Planner, while planning

    Scope checkA choice among options

    Before work starts on a unit

    Does this service's lockfile resolve the advisory's package, and inside the affected version range?

    Sees only: The service's lockfile lines for the package and the advisory's affected range

    Why: Most advisories never touch most services; an unreadable lockfile is reported, not assumed clear.

    • Resolved inside the affected rangethenAccept
    • Resolved outside the rangethenSkip this unit
    • Package absent from the lockfilethenSkip this unit
    • Lockfile missing or unparseablethenMark unresolved

  3. Before workers, before a task runs

    Small worker or strong modelYes or no, with a probability

    Before a task runs

    Does the advisory name a specific function, class or configuration condition that a small worker can search the service for?

    Sees only: The advisory's description and affected-component text

    Why: Vague advisories need a strong reader to work out what to look for.

    • Yes: 0.60 or higherthenAccept
    • Unsure: 0.30 up to 0.60thenEscalate to a strong model
    • No: below 0.30thenEscalate to a strong model

  4. After workers, the judge checks

    Evidence checkA choice among options

    After a worker answers

    Do the cited call sites reach the function the advisory names?

    Sees only: The cited lines from the service and the advisory's affected function and conditions

    Why: Absence of evidence is reported as not found and never as safe.

    • Cited lines call the affected functionthenAccept
    • Only other parts of the package are calledthenMark unresolved
    • No call sites were foundthenMark unresolved
    • Citation does not match the advisorythenReject and retry

  5. Accountable person, before anything is settled

    Person decidesYes or no, with a probability

    Before anything is reported as settled

    Is this service internet-facing or handling customer data according to the exposure map, with the affected version resolved?

    Sees only: The service's exposure map row and the verified version finding

    Why: Accept, patch or mitigate is the security engineer's call; reachability notes are advice.

    Accountable: The security engineer owns the accept, patch or mitigate decision; 'not reachable' is advice, not clearance.

    • Yes: 0.35 or higherthenAsk a person
    • Unsure: 0.10 up to 0.35thenAsk a person
    • No: below 0.10thenAccept

The fleet: who does what

Model tiers by role, not brands: you choose the models. Strong reasoning models plan and reconcile, small fast models do the wide work, and the judge is a decision model from a different family, so it does not share the workers' blind spots.

  1. Planner

    A strong reasoning model turns each advisory into the affected versions, functions and conditions to look for.

    Decisions here:2. Scope check

  2. Workers

    Small fast workers from an open-weight family each check one service for the version and for calls to the affected part.

    Designed for 10 to 400 agents, one worker task per one advisory against one service using the package. Each worker receives only its own unit.

    Decisions here:3. Small worker or strong model

  3. Judge, from a different model family

    A decision model from a different family checks the cited lines really reach the affected function.

    Decisions here:4. Evidence check

  4. Reconciler

    A strong reasoning model ranks affected services by exposure and keeps 'cannot tell' apart from 'not affected'.

    Decisions here:1. Another round?

  5. Accountable person

    The security engineer owns the accept, patch or mitigate decision; 'not reachable' is advice, not clearance.

    Decisions here:5. Person decides

Checked before anything is accepted

  • Affected-version claims cite the lockfile line
  • Reachability claims cite call sites; absence is reported as not found, never as safe
  • The advisory text is quoted for the affected function and conditions
  • Re-checks run only where the lockfile or the advisory changed, and the reason is logged

What comes back

  • Per advisory: affected services with lockfile and call-site evidence
  • Services needing a person because reachability is unclear
  • Upgrade target with the relevant changelog notes
  • Log of what was re-checked and why

What to measure

  • Advisories closed as not reachable and later overturned
  • Time from advisory to owner notified
  • Triage hours per advisory
  • Cost per advisory and service pair

Names of measures only. No result is claimed for this template.

Templates open in the workspace chat with the ask filled in. Nothing runs until you send it.

Get early accessSign in to use

More in Software engineering

Dependency and licence audit across a monorepo

For: Engineering lead or open-source compliance owner preparing a release, a sale or a customer audit

A monorepo pulls in a very long list of direct and transitive packages, each with its own licence text.

Pattern: Map, verify, reduceNeeds scale5 decisionsDesigned for 40 to 600 agents

Migration impact map across services

For: Staff engineer or platform lead planning a framework, database or shared-library migration

A breaking upgrade touches modules owned by many teams.

Pattern: Hierarchical decompositionNeeds a connector6 decisionsDesigned for 30 to 800 agents

Test case tournament for a module that must not break

For: Quality lead or engineer owning a payment, pricing or permissions module with thin tests

The module that must not break has happy-path tests only.

Pattern: TournamentNeeds a connector6 decisionsDesigned for 20 to 300 agents