本文へ移動
cccskills
無料GitHub で公開

reachability-analyzer

Runs dead-dependency analysis across JS, Python, and Rust projects using ecosystem-native static tools (`depcheck`/`knip` for JS, `vulture` for Python, `cargo-machete` for Rust), then cross-references the unused-dependency list against SCA findings to downrank vulns in code that is never loaded. Use when SCA output (from `osv-scanner`, `snyk-test`, or `npm-pip-maven-audit`) is too noisy to triage and the team needs to separate unreachable CVEs from exploitable ones before sprint planning; sibling cve-exploitability-triage ranks by EPSS/KEV exploitation signal, not code reachability.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qaスター 13(GitHub 13 + cccskills 0)

実行スコア 未検証

インストール方法を見る

含まれるファイル(3)

  • SKILL.md8.6 KB
  • .tessl-plugin/plugin.json726 B
  • references/dead-dependency-tools.md5.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

reachability-analyzer

Overview

Static vulnerability scanners report a CVE for every declared dependency that matches a vulnerable version, regardless of whether the vulnerable code is ever executed. A critical-severity finding in a test-only helper that your production build tree never reaches is a different risk level than the same CVE in a hot-path dependency. This skill operationalizes a reachability heuristic: run an ecosystem-native dead-dependency tool, produce an unused-deps.txt artifact, and feed that list into your SCA prioritization step so it can assign reachable: false and route affected findings to Fix-Backlog instead of Fix-Now.

The approach is static-analysis heuristic only. A dependency flagged unused by these tools is a strong signal to deprioritize its CVEs, not a guarantee that the vulnerable code is unreachable at runtime. Treat it accordingly.

When to use

  • After any SCA scan produces more findings than the team can triage in one sprint and you need a principled filter.
  • Before feeding findings into SCA prioritization so the reachable field is populated.
  • During dependency cleanup: the same tooling surfaces dead weight (unused packages that add attack surface and install time with no benefit).
  • When a security reviewer asks "is this CVE in something we actually use?"

How to use

  1. Run SCA first and save the findings JSON - this skill annotates existing findings, it does not replace them. See osv-scanner (or snyk-test / npm-pip-maven-audit) for full setup:

    osv-scanner scan -r . --format json --output osv.json
    
  2. Run the ecosystem-native dead-dependency tool for your stack, then extract the unused names into unused-deps.txt. Full config, flags, exit codes, and suppression per tool: references/dead-dependency-tools.md:

    # JS/TS - knip (preferred; depcheck was archived June 2025)
    npx knip --reporter json | jq -r '.dependencies[].name' > unused-deps.txt
    # Python - vulture; --min-confidence 90 targets unused imports
    vulture src/ --min-confidence 90 > vulture-report.txt
    # Rust - cargo-machete; --with-metadata catches renamed/feature-gated crates
    cargo machete 2>&1 | grep "unused dependency" | awk '{print $NF}' > unused-deps.txt
    
  3. Keep production and dev unused-dep lists separate: dev deps with CVEs can still reach production in bundled builds.

  4. Cross-reference unused-deps.txt against the SCA JSON, setting reachable: false on every finding whose package is unused (script below).

  5. Verify: assert unused-deps.txt is non-empty and every finding in the annotated JSON carries a populated reachable field before handoff. If the file is empty or a finding lacks the field, re-run the dead-dependency tool (a silent tool failure or the wrong workspace root is the usual cause) and re-annotate before proceeding.

  6. Pass the annotated JSON to your SCA prioritization step; reachable: false routes to Fix-Backlog unless the CVE is in the CISA KEV catalog.

  7. Wire steps 2-4 into CI so the annotated artifact feeds the prioritization job on every run, and still schedule each unused package for cleanup.

Cross-reference unused deps with SCA findings

Once you have an unused-deps.txt for your ecosystem, annotate the SCA JSON output before passing it to your SCA prioritization step:

import json

with open("osv.json") as f:
    findings = json.load(f)

with open("unused-deps.txt") as f:
    unused = {line.strip() for line in f}

for finding in findings.get("results", []):
    pkg = finding.get("package", {}).get("name", "")
    finding["reachable"] = pkg not in unused

with open("osv-annotated.json", "w") as f:
    json.dump(findings, f, indent=2)

Pass osv-annotated.json to your SCA prioritization step. Per the priority logic, findings with reachable: false route to Fix-Backlog regardless of severity, unless they are in the CISA KEV catalog.

CI integration

jobs:
  reachability:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: JS unused deps (knip)
        run: npx knip --reporter json | jq -r '.dependencies[].name' > unused-deps.txt
      - name: Annotate OSV output
        run: python3 ci/annotate-reachability.py osv.json unused-deps.txt
      - uses: actions/upload-artifact@v4
        with:
          name: osv-annotated
          path: osv-annotated.json

The annotated artifact is then consumed by the prioritization job.

Worked example

A team's OSV scan of a Next.js service returns 60 CVEs - too many to patch in one sprint. They run the JS dead-dependency tool (step 2), which flags 12 of the 80 declared dependencies as unused, including moment (CVE-2022-31129, CVSS 7.5). The cross-reference script sets reachable: false on the moment finding because moment appears in unused-deps.txt. Prioritization routes that CVE to Fix-Backlog instead of Fix-This-Sprint, and the team removes moment in the next dependency-cleanup PR, eliminating both the CVE and the unused weight in one change.

Anti-patterns

Anti-patternWhy it failsFix
Skip reachability; sort SCA output by CVSS onlyTeams spend sprints patching vulns in unused code while exploitable issues sit in Fix-BacklogRun the cross-reference step before triage
Treat reachable: false as safeStatic heuristic; dynamic imports and plugin systems can load code at runtimeUse as deprioritization signal only; still schedule Fix-Backlog cleanup
Run vulture at default confidence (60%)Reports unused functions/variables alongside imports; noisy for CVE mappingUse --min-confidence 90 to target imports specifically
Use depcheck on new JS projectsArchived June 2025; per github.com/depcheck/depcheck, maintainers recommend knipSwitch to knip for new setups
Skip --with-metadata in Rust monoreposRenamed crates not detected; false "used" verdictsAlways pass --with-metadata in CI
Ignore devDependencies entirelyDev deps with CVEs can reach production in bundled buildsSeparate prod/dev lists; confirm --omit=dev in audit scope

Limitations

  • All three tools use static analysis only. Dynamic imports (require(variable) in JS, importlib.import_module in Python) and compile-time proc macros in Rust can defeat detection, producing false "unused" verdicts.
  • Import-to-package mapping for Python requires manual maintenance when import names differ from PyPI package names.
  • Monorepo setups may require per-workspace runs; a dependency unused in one package may be used in another.
  • cargo-machete per github.com/bnjbvr/cargo-machete is described as "fast yet imprecise" - the trade-off is speed over recall.
  • These tools detect unused declarations; they do not trace call graphs to the vulnerable function within a used package. For function-level reachability, runtime instrumentation (e.g. Snyk's reachability analysis, CodeTF-based call-graph tools) is required.

References

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

Builds a CI gate that fails the build on **new** WCAG / a11y violations introduced by a PR while grandfathering pre-existing violations on a per-rule / per-page baseline. Aggregates verdicts from axe-core / pa11y / Lighthouse a11y / WAVE / IBM Equal Access scans. Use when a project has accumulated a11y debt and a strict "zero violations" gate would block every PR - the ratchet pattern lets the team ship while preventing regressions.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Workflow skill that builds an A/B-test validity checklist from an experiment proposal, walking the canonical design-correctness gates - pre-registered OEC/power/guardrails, randomization unit + SRM check, assignment integrity, telemetry, peeking discipline, novelty/primacy, post-experiment SRM re-check - into a per-experiment checklist + sign-off form. Use when launching, auditing, or governing an experiment. For pitfall mechanics (guardrails, peeking) see experiment-results-interpreter's references; to read an already-valid result use experiment-results-interpreter; for per-SDK harness tests use experiment-sdk-testing - this gates DESIGN, not SDK code.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

The single install-flow skill: the reference contract for the PWA install flow (installability gate fields, `beforeinstallprompt` handshake, per-platform paths - Android WebAPK / iOS Share menu / Firefox no-op - and the `display-mode` post-install signal, in references/install-flow-reference.md) plus the build-an-X workflow that emits the Add-to-Home-Screen suite. Walks the four-stage timeline, emitting one test per gate cell per [web.dev/articles/install-criteria][install-criteria], the deferred-prompt → `prompt()` → `userChoice` chain per [web.dev/articles/customize-install][customize-install], the iOS Safari manual-metadata branch (`apple-touch-icon`) per [web.dev/learn/pwa/installation][learn-pwa], and the post-install `(display-mode: standalone)` MQ assertion. Output: a Playwright spec with per-stage cells plus a coverage matrix. Use when a PWA's manifest, icons, or install handler change, when install conversion drops at an unknown stage, or when triaging a flaky install assertion.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Build-an-X workflow that uses an LLM to map existing tests to spec sections - given a spec doc + the test suite, the LLM identifies which tests cover which sections, surfaces uncovered sections (gap), and recommends specific tests to add. Output is a coverage matrix per spec ID. Scope is mapping tests that already exist and naming the gaps, not authoring tests for new acceptance criteria. Use when a spec doc and a test suite both exist but nobody can say which requirements are actually covered - before a release sign-off, an audit, or a decision about where to spend the next round of test effort.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Generates tests from natural-language specs (acceptance criteria, user stories, requirements) using an LLM, with confidence scoring per test case (LLM self-assessment plus heuristics: assertion quality, naming, completeness), batching uncertain cases for human review, and integration with the team's existing test framework. Use when the user asks to generate unit tests from acceptance criteria, convert user stories to test cases, automate test creation from requirements, or augment a spec-driven test suite with AI-generated stubs that are then curated before merge.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Configures Allure Report (test-runner adapter install, `allure-results` directory wiring, `categories.json` for failure classification, `history-trend.json` retention via the copy-history-between-runs pattern), runs the Allure CLI to convert `allure-results` to a static HTML site, and uploads the report as a CI artifact. Use when the team needs richer test reporting than JUnit XML - step-level attachments, per-test history, retry tracking, and severity / epic / feature labeling across framework-agnostic adapters (pytest, Jest, JUnit, TestNG, NUnit, Mocha). As a rich static HTML report generator, it is the open-source alternative to the sunset ExtentReports (JVM/.NET per-test HTML narrative); for hosted cross-run flakiness analytics rather than a static per-run report use currents-integration.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

testland のスキルをすべて見る

このスキルの問題を報告する