Agent Workflows

📄 Prefer offline? Download this guide as a PDF.

DepCheck earns its keep when it runs inside an agent's edit loop, not as an afterthought. This page is the playbook Cert-IX uses on its own monorepo, distilled so you can apply it to yours.

The core discipline: check before you add

The rule is simple and it is the whole game:

Before writing any dependency into a manifest — or pinning or upgrading one — check it with DepCheck. If it is vulnerable, pick the safe version instead.

Wired this way, a vulnerable version never lands in the first place. There is no "scanner caught it in CI a day later, now unwind the change" loop, because the bad version was never chosen.

The loop

Agent is about to add or bump a dependency
        │
        ▼
  check_package(ecosystem, name, version)
        │
   vulnerable? ──no──▶ write the version, done
        │yes
        ▼
  suggest_safe_version(ecosystem, name)   ← newest zero-advisory release
        │
        ▼
  write the SAFE version instead
        │
        ▼
  (after editing) scan_dependencies(manifest)  ← nothing left vulnerable?

Dropping it into an agent's instructions

The most reliable way to make an agent do this is to put the rule in its project instructions (a CLAUDE.md, .cursorrules, agent system prompt, or equivalent). This is the exact policy Cert-IX ships in its monorepo:

## Dependency safety (DepCheck — MANDATORY)

Before adding, pinning, or upgrading ANY dependency (go.mod, package.json,
Cargo.toml, requirements.txt, pyproject.toml, pom.xml, composer.json), check it
with the DepCheck MCP tools:

- `check_package(ecosystem, name, version)` BEFORE writing a new dependency
  into a manifest.
- If vulnerable, pick the version with `suggest_safe_version(ecosystem, name)` —
  never hand-pick a version with known Critical/High advisories.
- After editing a manifest (or when starting significant work in a service),
  run `scan_dependencies(manifest_path)` and fix what it reports, upgrading to
  the `upgrade_to` versions.
- `get_advisory(id)` for detail when deciding whether a finding is exploitable
  in context.
- Advisories flagged **`exploited`** ("⚠ exploited in the wild — CISA KEV / high
  EPSS") are being actively attacked — fix those FIRST, ahead of
  higher-CVSS-but-unexploited issues. `get_cve_intel(id)` gives the KEV/EPSS/CVSS
  detail for prioritisation.

Versions from ranges (`^`, `~`, `>=`) are checked at their declared minimum —
scan the lockfile for installed truth.

Adapt the manifest list and tool names to your stack; the shape is what matters.

Common plays

Adding a new dependency

"Add a Redis client to this Go service."

The agent resolves a candidate (github.com/redis/go-redis/v9 at some version), calls check_package, and — if clean — writes it. If not, it calls suggest_safe_version and writes that. You get a safe dependency on the first try.

Auditing an existing service

"Are this service's dependencies safe?"

The agent reads the lockfile and calls scan_dependencies. It comes back with just the vulnerable packages and their upgrade targets, ordered so that exploited-in-the-wild issues are first. The agent proposes the bumps; you review and apply.

Triaging a noisy result

Not every advisory matters for how your code uses a package. When a scan returns something borderline:

1. get_advisory(id) — read the CVSS vector and the affected code path. Does your usage touch it?
2. get_cve_intel(id) — is it KEV-listed or high-EPSS? If yes, it does not matter how narrow the path looks; treat it as urgent.

This keeps the team fixing the things that are actually dangerous instead of chasing every low-signal finding.

Why this beats scan-in-CI alone

CI scanning is still worth having as a backstop — but on its own it is reactive: the vulnerable version is already committed, the PR is already open, and a human has to loop back. DepCheck-in-the-loop is preventive: the agent never chooses the bad version, so there is nothing to unwind. Use both — prevent at authoring time, verify at merge time.

Honest limits to design around

• DepCheck reports what the advisory databases know at lookup time. Re-scan periodically; new advisories land for versions that were "clean" yesterday.
• It checks declared dependencies, not transitive resolution nuances beyond what the lockfile encodes, and it does not analyse your application code.
• A 0 vulnerabilities result means nothing known, not proven safe. Keep your other controls (SAST, review, least privilege) — DepCheck removes the known-bad, it does not certify the unknown.

See Security & data handling for what leaves the perimeter when the agent makes these calls.