agentleFS
gleicongleicon/devskills/skills/ds-osv/SKILL.md

ds-osv

Skill20 starsChanged 46 days agoMITView on GitHub

Scan project dependencies for known vulnerabilities using OSV Scanner.

  • Installs packages

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 5 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If osv-scanner is not installed, show installation instructions and stop.

    line 9
  2. Distinctive:

    No args: scan the current directory recursively.

    line 13
  3. Very specific:

    Check for osv-scanner binary.

    line 20
  4. Distinctive:

    Stop here. Do not proceed without the binary.

    line 27
  5. Distinctive:

    If zero findings: report clean with ecosystem coverage summary (which manifests were scanned).

    line 78
  6. Distinctive:

    Do not bump a version beyond the stated minimum fixed version — pick the minimum that resolves the CVE.

    line 83
  7. Distinctive:

    If a finding has no fixed version available, report it clearly and suggest tracking the upstream issue.

    line 84

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Queries the Google Open Source Vulnerability (OSV) database against every dependency manifest found in scope. Covers Go, npm, PyPI, Cargo, Maven, RubyGems, NuGet, PHP Composer, and more. Complements /ds-security-review (code logic) — this audits what your dependencies brought in, not what you wrote.

If osv-scanner is not installed, show installation instructions and stop.

Arguments

  • No args: scan the current directory recursively.
  • <path>: scan a specific directory or lockfile.
  • --fix: after reporting, bump vulnerable direct dependencies to the minimum fixed version by driving the ecosystem's own package manager (see Process step 6). Transitive-only findings are reported but not auto-fixed — they require the intermediate package to release a patch.
  • --verbose: expand LOW / informational findings, which are otherwise summarized as a count only.

Process

  1. Check for osv-scanner binary. If missing:
    Install osv-scanner:
      macOS:  brew install osv-scanner
      Go:     go install github.com/google/osv-scanner/cmd/osv-scanner@latest
      Other:  https://github.com/google/osv-scanner/releases
    Stop here. Do not proceed without the binary.
  2. Run the scan:
    osv-scanner --recursive --format json <path-or-.>
  3. Parse JSON output. Group findings:
    • CRITICAL / HIGH — report first, always actionable
    • MEDIUM — report with context
    • LOW / informational — summarize count only unless --verbose
  4. Classify each finding as direct or transitive. A finding is direct if its package appears in the manifest's own declared dependency list — e.g. go.mod require, package.json dependencies/devDependencies, Cargo.toml [dependencies]/[dev-dependencies], top-level entries in requirements.txt. Otherwise it is transitive. Determine this by reading the manifest yourself; do not rely on a scanner field, which is not consistently populated across ecosystems.
  5. For each finding report:
    • Package name + current version
    • Vulnerability ID (OSV ID and CVE alias if present)
    • Severity + CVSS score if available
    • Fixed version (the minimum version that resolves it)
    • Whether it's a direct or transitive dependency (from step 4)
    • One-line description of the vulnerability class
  6. With --fix: for direct dependencies (per step 4) where a fixed version exists, bump to the minimum fixed version by driving the ecosystem's native package-manager command — never by hand-editing manifest text — so the manifest and lockfile stay consistent. Use the upgrade primitive native to the manifest's ecosystem, for example:

    • Go: go get <pkg>@<version>
    • npm: npm install <pkg>@<version>
    • Cargo: cargo update -p <pkg> --precise <version>
    • …and the equivalent for any other detected ecosystem (PyPI, Maven, RubyGems, NuGet, Composer).

    Where no package-manager primitive cleanly applies (e.g. a raw requirements.txt with no pip-tools), fall back to editing the manifest and instruct the user to regenerate the lockfile. Note each change. Transitive-only findings are reported, not auto-fixed.

Output

OSV scan: <N> vulnerabilities found (<C> critical, <H> high, <M> medium, <L> low)

CRITICAL / HIGH
  <package>@<version>  <OSV-ID> / <CVE>
  Severity: <score>  Fixed: <version>  Dependency: direct|transitive
  <one-line class: e.g. "arbitrary code execution via malformed input">

MEDIUM
  <package>@<version>  <OSV-ID>
  ...

LOW/INFO: <N> findings — run with --verbose to expand.

Next steps:
  Re-run your build and tests to confirm each bump is compatible.
  Re-run /ds-osv to confirm findings resolved.

If zero findings: report clean with ecosystem coverage summary (which manifests were scanned).

Rules

  • Apply fixes by driving the ecosystem's package manager, not by hand-editing files. Never hand-edit a lockfile; let the package manager update the manifest and lockfile together so they stay consistent.
  • Do not bump a version beyond the stated minimum fixed version — pick the minimum that resolves the CVE.
  • If a finding has no fixed version available, report it clearly and suggest tracking the upstream issue.
  • Transitive-only findings with no direct-dependency path to a fix should be flagged for the user to escalate to the upstream package.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.