triage-dependencies
Skill172 starsChanged 2 months agoApache-2.0View on GitHub
Mark which of a project's dependency libraries could introduce taint sources. Use to start source discovery
In this repository15 other files it gives its agents.
- analyze-external-methodsSkill
- analyze-findingsSkill
- appsec-agentSkill
- assemble-lib-rulesSkill
- build-projectSkill
- create-dataflow-modelSkill
- create-pass-through-modelSkill
- create-ruleSkill
- create-test-projectSkill
- debug-ruleSkill
- discover-attack-surfaceSkill
- generate-pocSkill
- orchestrate-stageSkill
- report-analyzer-issueSkill
- run-scanSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
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
- Distinctive: line 12
Read the project's dependency libraries and flag the ones that can introduce a taint source — a place untrusted data enters
- Very specific: line 24
Read .opentaint/project/project.yaml — the dependencies list under each per-language projects entry is every third-party dependency the …
- Very specific: line 32
Write in .opentaint/tracking/coverage.yaml (per Tracking) a flat list of the flagged libraries' packages
≈ “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
Skill: Triage Dependencies
Read the project's dependency libraries and flag the ones that can introduce a taint source — a place untrusted data enters
Inputs
Provided by the caller, fall back to the default value when omitted. Ask back only when a required input is missing and has no sensible default
project-root(optional) — root of the target project. Opentaint keeps all analysis artifacts under the fixed<project-root>/.opentaint/directory, so every.opentaint/...path below resolves there. Default: current directory
Workflow
1. List the dependencies
Read .opentaint/project/project.yaml — the dependencies list under each per-language projects entry is every third-party dependency the model resolved. Resolve each to the library it is. Most of a large project's dependencies are transitive infrastructure
2. Mark each library
For each library decide: could it introduce an attacker-controlled source — a method returning untrusted data (HTTP/RPC request data, message-broker payloads, deserialized untrusted input and so on)? Judge by the library's identity itself, read sources to get overviews, docs
3. Write the flag list
Write in .opentaint/tracking/coverage.yaml (per Tracking) a flat list of the flagged libraries' packages
When coverage.yaml already exists from a prior run, reconcile rather than overwrite: keep every listed package and add any dependency newly added to the model that could introduce a source. A flagged package whose usage shifted (new call sites, a version bump) needs no re-open — source discovery automatically plans any used member not yet verdicted. When unsure whether a package belongs, list it: an over-flag only costs one discovery pass, a missed library loses its sources on every later stage
4. Verify before returning
Re-check the full dependency list against your flags: confirm every dependency was judged, then re-read the ones you did NOT flag and make sure none of them can actually introduce a source. A library left out here loses its sources on every later stage and the run can't recover it. Add any package you missed to the list. This is a re-read of what you already wrote — simple grep or re-read is fine, no need to use some scripts.
Output
Short and concise report of what was done
Artifacts:
.opentaint/tracking/coverage.yaml— the flagged packages list
Summary:
- one line per flagged package: the package and why it was flagged
Tracking
.opentaint/tracking/coverage.yaml — a flat list of the dependency packages flagged to drill for taint sources. Keep it clear from comments
packages:
- <dependency-package-a>
- <dependency-package-b>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.

