ds-osv
Skill20 starsChanged 46 days agoMITView on GitHub
Scan project dependencies for known vulnerabilities using OSV Scanner.
- Installs packages
In this repository52 other files it gives its agents.
- ds-dev-skill-benchSkill
- ds-agent-reviewSkill
- ds-architecture-planSkill
- ds-arenaSkill
- ds-blast-radiusSkill
- ds-blueprintSkill
- ds-bug-reviewSkill
- ds-clarity-reviewSkill
- ds-code-quality-reviewSkill
- ds-comment-reviewSkill
- ds-data-modeSkill
- ds-data-reviewSkill
- ds-debugSkill
- ds-deslopSkill
- ds-doc-quality-reviewSkill
- ds-exploreSkill
- ds-git-modeSkill
- ds-go-reviewSkill
- ds-grill-meSkill
- ds-handoffSkill
- ds-howSkill
- ds-humanizeSkill
- ds-interaction-modeSkill
- ds-java-reviewSkill
- ds-notebook-reviewSkill
- ds-onboardingSkill
- ds-perf-planSkill
- ds-project-checkpointSkill
- ds-project-resumeSkill
- ds-python-reviewSkill
- ds-quality-gateSkill
- ds-reflectSkill
- ds-retroSkill
- ds-roadmapSkill
- ds-rust-reviewSkill
- ds-security-reviewSkill
- ds-semgrepSkill
- ds-shell-reviewSkill
- dsSkill
- ds-specSkill
- ds-step-modeSkill
- ds-tdd-modeSkill
- ds-test-modeSkill
- ds-test-quality-reviewSkill
- ds-tiger-style-modeSkill
- ds-tldtSkill
- ds-ts-reviewSkill
- ds-ui-modeSkill
- ds-ui-quality-reviewSkill
- ds-verify-thisSkill
- ds-zig-reviewSkill
- ds-zoom-outSkill
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
- Very specific: line 9
If osv-scanner is not installed, show installation instructions and stop.
- Distinctive: line 13
No args: scan the current directory recursively.
- Very specific: line 20
Check for osv-scanner binary.
- Distinctive: line 27
Stop here. Do not proceed without the binary.
- Distinctive: line 78
If zero findings: report clean with ecosystem coverage summary (which manifests were scanned).
- Distinctive: line 83
Do not bump a version beyond the stated minimum fixed version — pick the minimum that resolves the CVE.
- Distinctive: line 84
If a finding has no fixed version available, report it clearly and suggest tracking the upstream issue.
≈ “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.
Files
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
- Check for
osv-scannerbinary. If missing:
Stop here. Do not proceed without the binary.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 - Run the scan:
osv-scanner --recursive --format json <path-or-.> - Parse JSON output. Group findings:
- CRITICAL / HIGH — report first, always actionable
- MEDIUM — report with context
- LOW / informational — summarize count only unless
--verbose
- 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.modrequire,package.jsondependencies/devDependencies,Cargo.toml[dependencies]/[dev-dependencies], top-level entries inrequirements.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. - 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
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.txtwith 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.- Go:
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.
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
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.

