Menü
Build a CodeQL database and run dataflow-backed query-suite analysis via the mantis_codeql MCP server
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
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
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
Record and advance every vulnerability finding through the tool-owned mantis_findings service instead of tracking findings in prose
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
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
Run osv-scanner via the mantis_osv_scanner MCP server for SCA (vulnerable dependency) findings
| name | codeql-audit |
| description | Build a CodeQL database and run dataflow-backed query-suite analysis via the mantis_codeql MCP server |
Use codeql_create_database then codeql_analyze (mantis_codeql MCP server) when you need dataflow-aware SAST beyond what regex/pattern tools (semgrep, ast-grep) can prove -- CodeQL's query suites trace actual source-to-sink data flow through the codebase.
Workflow:
codeql_create_database({ source_root, language, database_path }) once per target/language. This is slow (can take minutes on large repos); don't repeat it unless the source changed.codeql_analyze({ database_path, query_suite }). Default query_suite is "security-extended"; use "security-and-quality" only if the user wants broader quality findings too.candidate with a dataflow-backed path, which is stronger recall evidence than a plain grep match -- but it is still not a confirmed finding. CodeQL's own dataflow models can miss framework-specific sanitization; verify the path manually before validating.codeql reports available: false, fall back to semgrep_scan and program-analysis's source_sink_scan/ast_grep_scan for recall, and tell the user CodeQL-grade dataflow coverage wasn't available for this run.