Skip to content

Dependency Risk

Roster name: risk.

What it does

Every day it writes one ranked report on which known vulnerabilities in your Go dependencies your code actually reaches, and what to do about each.

  • Puts reachable advisories first.
  • Recommends an upgrade, a pin, a patch or a replacement for each advisory.
  • Names the Go version to move to for toolchain advisories.

What it reads

The machine output of Go’s call-graph-aware vulnerability scanner (govulncheck), run by core scan --json across the platform’s modules. Reachability comes from the scanner, not from the model.

What it produces

The living “Dependency risk report” issue: a one-line posture, the reachable advisories with module and fixed version, a recommendation for each advisory with no upstream fix, and the toolchain advice. When the scan is empty, it says exactly that.

Human oversight

A person schedules the upgrades. The agent changes nothing itself.

Model

Qwen3.6-35B-A3B, by Qwen, licensed Apache-2.0 (the general tier). Runink domain adaptation for this agent is planned; this release uses the base model.

Where it runs and data handling

On your Runink TIDE deployment’s own inference, on your Server or in your cloud. The scan output goes to that model plane and to no third-party AI service. The scanner itself reads the public Go vulnerability database.

Guardrails

  • It is instructed never to invent an advisory, and the scanner’s raw findings are attached to every report, so each advisory the summary names can be checked against them.
  • Reachable advisories are listed first, by the scanner’s reachability.
  • A clear split of duties: your own code changes are the Release Curator’s security audit; controls are Compliance Evidence’s.

Limitations

  • Go dependencies only, as the scanner sees them.
  • An advisory not yet in the vulnerability database cannot be reported.
  • It does not review first-party code.

Evaluation

No published evaluation scores yet.

Illustrative example

Invented scan. Seven advisories across four modules: one reachable, four not called, one with no fix, one toolchain. Posture: “1 reachable advisory needs an upgrade today.” The no-fix module gets a recommendation to replace it with a library the platform already uses.