mcpField
T
triage-dependencies

triage-dependencies

github.com/seqraSecurity17059 installsUpdated 1d ago
Repository

About triage-dependencies

A security skill that reviews dependencies listed in an OpenTaint project model and flags packages that may introduce attacker-controlled data. It writes the flagged package list to coverage.yaml for later source discovery.

Key features

  1. 01Read modeled project dependencies
  2. 02Assess libraries for untrusted-data sources
  3. 03Record flagged packages in coverage.yaml
  4. 04Reconcile existing coverage flags

Use cases

  1. 01Identify dependencies that may expose request data
  2. 02Prepare packages for later taint-source discovery

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/seqra/opentaint --skill triage-dependencies

After installing, type/triage-dependenciesin Claude Code to confirm it loaded.

Details

From the project README

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>

Comments

Markdown supported