Scans repository dependencies for security updates using Dependabot CLI, identifying vulnerable packages from ecosystem security advisories.
Integrates with Docker to scan Docker images and Dockerfiles for vulnerabilities, misconfigurations, and secrets using Trivy.
Integrates with GitHub for automated security scanning via GitHub Actions, including SARIF upload to Code Scanning and advisory database lookups.
Provides a GitHub Action to run full security scans in CI/CD pipelines, with configurable severity thresholds and SARIF output.
Scans Node.js dependencies for known vulnerabilities using npm audit.
Scans Python dependencies for CVEs using pip-audit against the PyPI Advisory Database.
Analyzes Python code for security anti-patterns and code quality issues using Ruff.
Scans Docker images and local filesystems for OS and library vulnerabilities, misconfigurations, and secrets using Trivy.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@shieldbot scan my project for security vulnerabilities"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Shieldbot is an AI-powered security scanner that runs directly inside Claude Code. It combines deep dataflow analysis, 5,000+ static analysis rules, and advisory-database lookups with Claude's reasoning to detect vulnerabilities, hardcoded secrets, and CVE-affected dependencies — then synthesizes findings into a prioritized, actionable report.
One command. Full security audit. Zero context switching.
Scanner | What It Catches | Auto-installed |
CodeQL | Deep dataflow / taint-analysis SAST — SQL injection, XSS, path traversal, RCE, authentication flaws across 8+ languages | ✓ |
Semgrep (5,000+ rules) | OWASP Top 10, CWE Top 25, SQL injection, XSS, SSRF, command injection | |
Bandit | Python-specific security flaws (hardcoded passwords, weak crypto, shell injection) | |
Ruff | Python code quality and security anti-patterns | |
detect-secrets | API keys, tokens, passwords, private keys in source code | |
Dependabot CLI | Ecosystem-specific security updates via GitHub's Dependabot engine (security-updates-only mode, requires Docker at runtime) | ✓ |
osv-scanner | Dependency CVEs from the OSV / GitHub Advisory Database — works offline, no token required | ✓ |
Trivy | Docker image CVEs (OS packages + libraries), Dockerfile misconfigurations, and secrets baked into image layers — runs automatically when a Dockerfile is found | ✓ |
pip-audit | Python dependency CVEs (PyPI Advisory Database) | |
npm audit | Node.js dependency CVEs |
All scanners run in parallel. Findings are deduplicated, ranked by exploitability, and explained in plain English.
Auto-installed tools (CodeQL, osv-scanner, Dependabot CLI, Trivy) are downloaded automatically on first scan — no package manager or sudo required. Supports macOS and Linux on x86_64 and arm64. Trivy and Dependabot CLI require Docker at runtime (image builds / ecosystem updaters). Trivy scan strategy: (1)
docker build→ full image scan; (2)docker pull <base_image>→ base image scan if build fails; (3)trivy fsfilesystem fallback. When Docker build fails (e.g. network restrictions in CI), a prominent SCAN GAP warning is emitted and the base image is scanned directly. Pass--image <tag>/extra_imagesto scan a pre-built image directly.
Related MCP server: Claude Flow MCP
Step 1 — Add the Shieldbot marketplace:
/plugin marketplace add BalaSriharsha/shieldbotStep 2 — Install the plugin:
/plugin install shieldbotStep 3 — Reload plugins:
/reload-pluginsStep 4 — Run a scan:
/shieldbot .
/shieldbot /path/to/repo
/shieldbot . --git-historyOr just ask Claude naturally:
"scan this repo for security vulnerabilities"
"check my code for hardcoded secrets"
"audit my Python dependencies for CVEs"
Add to your MCP client config (.mcp.json or claude_desktop_config.json):
{
"mcpServers": {
"shieldbot": {
"command": "uvx",
"args": ["shieldbot-mcp"]
}
}
}Or install via pip:
pip install shieldbot-mcpCodeQL, osv-scanner, and Dependabot CLI are downloaded automatically on first scan, but you can pre-install them with the bundled CLI:
shieldbot-install # install all four
shieldbot-install --codeql # CodeQL only
shieldbot-install --osv # osv-scanner only
shieldbot-install --dependabot # Dependabot CLI only
shieldbot-install --trivy # Trivy only
shieldbot-install --force # reinstall / upgrade to latestBinaries are placed in ~/.local/bin. Add it to your shell profile if needed:
export PATH="$HOME/.local/bin:$PATH"All three tools are fully open-source and installed from their official GitHub releases — no package manager, no sudo, no API keys:
Tool | Source | License |
CodeQL CLI | MIT | |
osv-scanner | Apache-2.0 | |
Dependabot CLI | MIT | |
Trivy | Apache-2.0 |
Tool | Description |
| Run a full parallel security scan and return a structured JSON report |
| Check which scanners are installed and available |
scan_repository parametersParameter | Type | Default | Description |
| string | required | Absolute path to the repository |
| list |
| Scanners to skip — valid values: |
| bool |
| Also scan git commit history for leaked secrets |
| list |
| Pre-built Docker image names/tags to scan directly with Trivy — use when |
Shieldbot includes a command-line fixer that the agent uses to analyse and patch Dockerfiles and compose files:
# Analyse a Dockerfile and generate a fix plan from scan results
python -m shieldbot.fixers.dockerfile_fixer analyze Dockerfile shieldbot-report.json
# List all FROM stages and their detected package managers
python -m shieldbot.fixers.dockerfile_fixer list-stages Dockerfile
# List all RUN install commands and their packages
python -m shieldbot.fixers.dockerfile_fixer list-installs Dockerfile
# List all image: references in a docker-compose file
python -m shieldbot.fixers.dockerfile_fixer list-compose-images docker-compose.yml
# Check Docker Hub for a newer/patched base image tag
python -m shieldbot.fixers.dockerfile_fixer suggest-base-upgrade ubuntu:20.04Add Shieldbot to any repository in 3 lines. Findings appear in the Security > Code Scanning tab via SARIF upload.
# .github/workflows/shieldbot.yml
name: Shieldbot Security Scan
on:
push:
branches: [main, master]
pull_request:
branches: [main, master]
schedule:
- cron: '0 8 * * 1' # Weekly scan
permissions:
contents: read
security-events: write # Required for Code Scanning upload
jobs:
shieldbot:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: BalaSriharsha/shieldbot@mainAll available inputs:
Input | Default | Description |
|
| Directory to scan |
|
| Fail build if findings at or above this level |
| `` | Comma-separated scanners to skip |
|
| Scan git history for leaked secrets |
|
| Upload to GitHub Code Scanning |
|
| SARIF output path |
Outputs: total-findings, risk-score, sarif-file
See .github/workflows/shieldbot-example.yml for the full annotated example.
Code | Meaning |
| Clean — no findings above threshold |
| Medium+ findings detected |
| High+ findings detected |
| Critical findings detected |
Use exit codes to gate deployments in GitHub Actions, GitLab CI, or any pipeline.
Detect — Shieldbot profiles the repository (languages, package managers, git history)
Auto-install — Any missing scanner tools (CodeQL, osv-scanner, Dependabot CLI) are downloaded from GitHub releases for the current OS and architecture
Scan — All applicable scanners run in parallel via asyncio.gather()
Deduplicate — Findings are deduplicated by exact hash and proximity (±3 lines), with scanner priority: CodeQL → Semgrep → Bandit → detect-secrets → Dependabot/osv-scanner → pip-audit/npm-audit → Trivy
Analyze — Claude synthesizes raw scanner output into prioritized findings with context
Report — Structured output with executive summary, risk score, and remediation steps
Python 3.11+
Claude Code (for plugin mode)
Docker (optional — required at runtime for Trivy image scanning and Dependabot CLI's ecosystem updaters)
Issues and pull requests welcome at github.com/BalaSriharsha/shieldbot.
MIT — see LICENSE
Check which security scanner tools are installed and available.
Returns a JSON object mapping each tool name to its availability status and install path (or install instructions if missing).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently describes the return format: 'Returns a JSON object mapping each tool name to its availability status and install path (or install instructions if missing).' No mention of side effects, but the read-only nature is clear from the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the purpose, the second describes the output. Front-loaded and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema, the description suffices. It explains what the tool checks and what the output looks like. No additional context needed for a simple inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (baseline 4). The description does not need to add parameter semantics, and schema coverage is 100% as there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Check which security scanner tools are installed and available', specifying a clear verb 'check', resource 'security scanner tools', and outcome. It distinguishes from the sibling tool 'scan_repository' which performs scanning actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus the sibling 'scan_repository'. The description implies checking availability before scanning, but does not state this directly or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a full security scan on a repository.
Executes the following scanners in parallel:
CodeQL (deep dataflow / taint-analysis SAST, open-source CLI)
Semgrep (5,000+ OWASP/CWE rules)
bandit (Python-specific security linter)
ruff (Python quality + security patterns)
detect-secrets / gitleaks (hardcoded secrets)
osv-scanner / dependabot (dependency CVEs via OSV/GHSA advisory DB)
pip-audit (Python CVEs)
npm-audit (Node.js CVEs)
trivy (Docker image CVEs, misconfigurations, and baked-in secrets — runs when a Dockerfile is found)
Returns a JSON report with deduplicated, severity-ranked findings.
Args: repo_path: Absolute or relative path to the repository to scan. skip_scanners: Optional list of scanner names to skip. Valid values: codeql, semgrep, bandit, ruff, detect-secrets, dependabot, pip-audit, npm-audit, trivy scan_git_history: If True, scan git history for leaked secrets (requires gitleaks to be installed). extra_images: Pre-built Docker image names/tags to scan directly with Trivy. Use when docker build fails in a restricted environment. Example: ["mcr.microsoft.com/playwright:v1.50-noble"]
Returns: JSON string containing the full SecurityReport with all findings, per-scanner metadata, severity counts, and scan duration.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | ||
| skip_scanners | No | ||
| scan_git_history | No | ||
| extra_images | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses parallel execution, return format, conditions for Trivy, and parameter effects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is comprehensive but slightly lengthy; front-loaded with purpose but lists scanners in a verbose manner. Each sentence provides value, though some redundancy exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 4 parameters, and existence of output schema, description covers all necessary context: scanner list, parameter options, edge cases (Dockerfile trigger).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet description explains all parameters: repo_path, skip_scanners with valid values, scan_git_history with requirement, extra_images with example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool runs a full security scan on a repository, listing specific scanners. Distinguishes from sibling tool 'check_scanner_tools' by focusing on scanning execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the tool's role and customization via skip_scanners, but does not explicitly state when not to use it or recommend alternatives beyond the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools are completely distinct: one checks which scanners are installed, the other runs a full security scan. There is no overlap or confusion between them.
Both tool names follow a consistent verb_noun pattern (check_scanner_tools, scan_repository), making the purpose clear and predictable.
With only 2 tools, the server feels thin for the domain of security scanning. While the core actions are covered, additional tools for viewing scan history or configuring scans would be expected.
The server lacks tools for retrieving previous scan results, managing scan configurations, or listing repositories. Agents can check scanner availability and run a scan, but cannot access past reports or manage scan lifecycle.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security reviews for coding agents: diffs checked against your org policy and live infrastructure.
Threat modeling, code/cloud/pipeline scanning, shadow-AI discovery, compliance checks and fixes.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/balasriharsha/shieldbot'
If you have feedback or need assistance with the MCP directory API, please join our Discord server