osv-dependency-scan

星标382

分支63

更新时间2026年7月6日 18:10

Run osv-scanner via the mantis_osv_scanner MCP server for SCA (vulnerable dependency) findings

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

deonmenezes

deonmenezes/mantishack

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

相关职业SOC

基于 SOC 职业分类

软件开发工程师计算机与数学类职业·SOC 15-1252

SKILL.md

readonly

name	osv-dependency-scan
description	Run osv-scanner via the mantis_osv_scanner MCP server for SCA (vulnerable dependency) findings

Use osv_scan({ path }) (mantis_osv_scanner MCP server) for the Detect stage's SCA coverage: known-vulnerable dependencies matched against the OSV database, recursively across manifests/lockfiles under path.

Each result is a candidate keyed by package + version + advisory id (CVE/GHSA). A vulnerable dependency being present does not mean the vulnerable code path is reachable or exercised by the application -- that's a separate reachability question.
Before validating, check whether the vulnerable function/API of the dependency is actually called anywhere in the target codebase (grep/ast-grep for the relevant import or call). If it's an unused transitive dependency, note that in the rejection reason rather than dropping the finding silently.
Prefer offline: true only when the environment has no network access to query the live OSV database; note in your report that offline results may be stale.
If osv-scanner reports available: false, say so explicitly -- don't claim SCA coverage you didn't actually get.

同仓库更多 Skills

同仓库

canary-tripwire-response

deonmenezes/mantishack

What to do if a mantis_canary decoy tool ever shows up as tempting or gets called -- treat it as a security incident, not a normal tool result

2026-07-06382

codeql-audit

deonmenezes/mantishack

Build a CodeQL database and run dataflow-backed query-suite analysis via the mantis_codeql MCP server

2026-07-06382

detection-breadth

deonmenezes/mantishack

When and how to reach for the companion detectors -- bandit (Python SAST) and trivy (deps + secrets + IaC misconfig) -- alongside the core semgrep/CodeQL/osv/trufflehog toolchain

2026-07-06382

findings-spine

deonmenezes/mantishack

Record and advance every vulnerability finding through the tool-owned mantis_findings service instead of tracking findings in prose

2026-07-06382

http-evidence

deonmenezes/mantishack

Turn a captured HTTP request/response into a bounded, redacted evidence pack with a stable request-ref using the mantis_http_audit MCP server, instead of pasting raw traffic into a finding

2026-07-06382

mantis-pipeline

deonmenezes/mantishack

The master Mantis playbook -- how to run an authorized vulnerability-discovery engagement end to end, which subagent owns each stage, which MCP tool feeds it, and how findings move through the tool-owned lifecycle

2026-07-06382

name	osv-dependency-scan
description	Run osv-scanner via the mantis_osv_scanner MCP server for SCA (vulnerable dependency) findings

Each result is a candidate keyed by package + version + advisory id (CVE/GHSA). A vulnerable dependency being present does not mean the vulnerable code path is reachable or exercised by the application -- that's a separate reachability question.
Before validating, check whether the vulnerable function/API of the dependency is actually called anywhere in the target codebase (grep/ast-grep for the relevant import or call). If it's an unused transitive dependency, note that in the rejection reason rather than dropping the finding silently.
Prefer offline: true only when the environment has no network access to query the live OSV database; note in your report that offline results may be stale.
If osv-scanner reports available: false, say so explicitly -- don't claim SCA coverage you didn't actually get.