Kryptonclaw

CI/CD Security Scanner for GitHub Actions, GitLab CI, and Jenkins

Kryptonclaw detects 30+ attack patterns in CI/CD pipelines -- the same vectors used in the HackerBot-Claw campaign (Feb 2026) that compromised workflows across Microsoft, DataDog, CNCF, and Trivy repositories. It scans workflow files via the GitHub API without cloning repos, supports org-wide batch scanning, and outputs SARIF for direct GitHub Code Scanning integration.

$ kryptonclaw scan --repo juice-shop/juice-shop

Kryptonclaw Scan Report: juice-shop/juice-shop
Scanned 12 files across 1 repos in 253ms

Findings: 29 total (Critical: 0, High: 9, Medium: 20, Low: 0)
--------------------------------------------------------------------------------
[HIGH] Remote script execution (curl|bash, wget|sh) (KC-104)
  Location: .github/workflows/ci.yml
  Pipeline downloads and executes remote scripts via curl|bash or wget|sh.
  An attacker who compromises the remote URL can execute arbitrary code.
  Fix: Download scripts, verify checksums, then execute.
  CWE: CWE-829

[HIGH] Untrusted input in workflow expression (KC-101)
  Location: .github/workflows/ci.yml
  github.head_ref used in run: step — attacker-controlled branch names
  can inject shell commands via crafted PR branch names.
  Fix: Pass untrusted input via environment variable, not direct interpolation.
  CWE: CWE-94

[MED] Mutable tag reference (KC-003)
  Location: .github/workflows/ci.yml
  Action coverallsapp/github-action@v2 uses a mutable tag.
  Fix: Pin to a full commit SHA: uses: action@<40-char-sha>
  CWE: CWE-829
...

Why Kryptonclaw

Most CI/CD security tools focus on container images or dependency scanning. They miss the pipeline itself — the YAML configuration files that define what code runs, with what permissions, and with access to what secrets.

Attackers know this. The HackerBot-Claw campaign exploited pull_request_target triggers to run malicious code with write access to base repositories. Unpinned GitHub Actions allowed supply chain poisoning through tag mutation. Workflow injection via ${{ github.event.pull_request.title }} gave attackers command execution inside trusted pipelines.

Kryptonclaw catches all of these patterns and more. It applies both regex-based detection and YAML-aware structural analysis to find vulnerabilities that simple grep-based tools miss — like a pull_request_target trigger combined with actions/checkout referencing the PR head SHA in the same job.

Key capabilities:

• API-first scanning — Fetches workflow files via GitHub Contents API. No git clone, no disk I/O, no repository checkout.
• Org-wide batch scanning — Scan every repo in a GitHub organization with a single command. Configurable concurrency, rate-limit aware.
• 30+ detection rules — GitHub Actions, GitLab CI, Jenkins, plus generic CI/CD patterns. Every rule mapped to CWE IDs with remediation guidance.
• YAML structural analysis — Parses workflows into typed structures to detect multi-step attack chains that span triggers, permissions, and steps.
• SARIF v2.1.0 output — Drop results directly into GitHub Code Scanning. Also supports JSON and human-readable text.
• MCP server — 10 tools for integration with AI assistants and automated security workflows.
• Red team mode — Optional exploit scenario generation via armyknife-llm-redteam bridge.

Installation

From crates.io

cargo install kryptonclaw

This installs both kryptonclaw (CLI) and kryptonclaw-mcp (MCP server) to ~/.cargo/bin/.

From source

git clone https://github.com/armyknife-social/kryptonclaw.git
cd kryptonclaw
cargo build --release

# Binaries at:
#   target/release/kryptonclaw       (CLI)
#   target/release/kryptonclaw-mcp   (MCP server)

Requires Rust 1.75 or later.

Add to PATH

# If installed from source:
cp target/release/kryptonclaw ~/.local/bin/
cp target/release/kryptonclaw-mcp ~/.local/bin/

Usage

Scan a single repository

# API-only scan (no clone, fast)
kryptonclaw scan --repo owner/repo

# With explicit token
kryptonclaw scan --repo owner/repo --token $GITHUB_TOKEN

Scan an entire organization

# Scan all repos in an org (default: 4 concurrent)
kryptonclaw scan --org my-company

# Higher concurrency for large orgs
kryptonclaw scan --org my-company --concurrency 8

# Only show high and critical findings
kryptonclaw scan --org my-company --min-severity high

Scan a local directory

# Scan local .github/workflows/ files
kryptonclaw scan --path /path/to/repo

# Deep scan (walks entire directory tree)
kryptonclaw scan --path /path/to/repo --deep

Output formats

# Human-readable (default)
kryptonclaw scan --repo owner/repo

# JSON (full report structure)
kryptonclaw scan --repo owner/repo --format json

# SARIF v2.1.0 (GitHub Code Scanning)
kryptonclaw scan --repo owner/repo --format sarif -o results.sarif

Upload to GitHub Code Scanning

kryptonclaw scan --repo owner/repo --format sarif -o results.sarif
gh code-scanning upload results.sarif

List detection rules

kryptonclaw rules

Rule ID    Severity   CWE          Description
--------------------------------------------------------------------------------
KC-001     HIGH       CWE-269      workflow_run trigger (privilege escalation chain)
KC-002     HIGH       CWE-829      Unpinned action reference (branch/tag instead of SHA)
KC-003     MEDIUM     CWE-829      Mutable tag ref (e.g., @v4 instead of @v4.1.1 or full SHA)
KC-004     MEDIUM     CWE-494      Artifact upload/download without verification
KC-005     CRITICAL   CWE-94       actions/github-script with user-controlled input
...

Red team mode

# Generate exploit scenarios for each finding
kryptonclaw scan --repo owner/repo --redteam

Requires armyknife-llm-redteam-mcp on PATH. When enabled, each finding is analyzed to produce a proof-of-concept attack scenario with MITRE ATT&CK mappings.

Detection Rules

Kryptonclaw ships with 30+ rules organized by CI platform. Every rule includes a CWE mapping, severity classification, and remediation guidance.

GitHub Actions

GitLab CI

Jenkins

YAML Structural Analysis

Beyond regex matching, kryptonclaw parses GitHub Actions workflows into typed structures and applies semantic checks:

• HackerBot-Claw pattern detection: Identifies pull_request_target trigger combined with actions/checkout referencing github.event.pull_request.head.sha or github.head_ref in the same job. This is the exact attack chain used in the Feb 2026 campaign.
• Composite input injection: Detects ${{ inputs.* }} interpolation in run: steps across parsed job definitions.
• Workflow dispatch input injection: Finds ${{ github.event.inputs.* }} used directly in shell commands.

Structural analysis catches patterns that span multiple YAML keys and cannot be reliably detected with single-line regex.

Additional Scanners

Kryptonclaw also includes:

• Secrets scanner — 12 credential patterns (AWS keys, GitHub PATs, Slack tokens, OpenAI keys, private keys, database passwords). Applied to all scanned files.
• Supply chain scanner — 40+ known typosquatted package names, malicious lifecycle hooks, custom registry detection, dependency confusion patterns. Covers npm, PyPI, Cargo, Go modules, RubyGems.

Supported CI/CD Platforms

Platform detection works by file path and, for ambiguous YAML files, by content heuristics (runs-on: + steps: = GitHub Actions, stages: + script: = GitLab CI).

MCP Server

Kryptonclaw includes a Model Context Protocol server with 10 tools for integration with AI assistants and automated security workflows.

# Start the MCP server
kryptonclaw-mcp

MCP Configuration

Add to your MCP client configuration:

{
  "mcpServers": {
    "kryptonclaw": {
      "type": "stdio",
      "command": "kryptonclaw-mcp",
      "args": []
    }
  }
}

Available Tools

All tools accept a token parameter or fall back to the GITHUB_TOKEN / GH_TOKEN environment variable. Output is automatically sanitized to redact credentials.

Architecture

kryptonclaw
├── cli/                    Command-line interface (clap 4)
├── core/                   Engine, findings, config, reports
├── plugins/
│   └── builtin/
│       ├── cicd/           CI/CD scanner (regex + YAML parser)
│       │   ├── github_actions.rs
│       │   ├── gitlab_ci.rs
│       │   ├── jenkins.rs
│       │   ├── parser.rs   YAML structural analysis
│       │   └── rules.rs    Rule definitions + matching engine
│       ├── secrets.rs      Credential pattern detection
│       └── supply_chain.rs Package supply chain analysis
├── platform/               GitHub API client (Contents API, org listing)
├── scan/                   API-only and batch scanning orchestration
├── mcp/                    MCP server (10 tools, rmcp 0.16)
├── output/                 Text, JSON, SARIF formatters
└── redteam/                armyknife-llm-redteam bridge

Design principles:

• API-first: Default scanning mode uses the GitHub Contents API. No git clone, no disk writes, no repository checkout. This makes org-wide scanning fast and safe.
• Defense in depth: Regex rules catch known patterns fast. YAML parsing catches structural patterns that span multiple keys. Both run on every file.
• Fail open on parsing: Malformed YAML (sometimes intentional in attack scenarios) falls back to regex-only scanning rather than skipping the file.
• Rate limit awareness: The GitHub API client tracks remaining requests via x-ratelimit-remaining headers. Scanning stops gracefully when the budget is exhausted rather than hammering a 403.
• Async throughout: Built on Tokio with async HTTP, async plugin execution, and async batch orchestration.

Environment Variables

SARIF Integration

Kryptonclaw produces SARIF v2.1.0 output compatible with GitHub Code Scanning, VS Code SARIF Viewer, and other SARIF-consuming tools.

SARIF output includes:

• reportingDescriptor entries for each rule with ID, description, severity, and CWE tags
• result entries for each finding with physical location (file path + line number)
• Severity mapping: Critical/High to error, Medium to warning, Low/Info to note

# Generate and upload to GitHub Code Scanning
kryptonclaw scan --org my-company --format sarif -o scan.sarif
gh code-scanning upload scan.sarif --ref refs/heads/main

Performance

Rate limits: Authenticated GitHub API allows 5,000 requests/hour. Each repo scan uses 2-10 API calls depending on workflow count. A 200-repo org scan uses roughly 1,000-2,000 API calls.

Real-World Test: OWASP Juice Shop

To validate detection accuracy, kryptonclaw was run against OWASP Juice Shop -- one of the most popular intentionally vulnerable web applications, maintained by the OWASP Foundation with 12 GitHub Actions workflow files.

$ kryptonclaw scan --repo juice-shop/juice-shop

Kryptonclaw Scan Report: juice-shop/juice-shop
Scanned 12 files across 1 repos in 253ms

Findings: 29 total (Critical: 0, High: 9, Medium: 20, Low: 0)

Findings Breakdown

HIGH severity (9 findings)

MEDIUM severity (20 findings)

Key Takeaways

1. Branch name injection is systemic. 7 of 12 workflows interpolate github.head_ref directly into shell commands. This is the same class of vulnerability that enabled the HackerBot-Claw campaign -- attackers control the branch name, and the branch name becomes code.

2. Remote script execution is a real supply chain risk. The Heroku CLI install via curl | sh trusts a third-party CDN to deliver unmodified code. A compromised CDN or DNS hijack gives an attacker code execution inside CI with access to deployment credentials.

3. Missing permissions declarations are pervasive. 10 of 12 workflows rely on repository defaults instead of explicitly scoping GITHUB_TOKEN permissions. The principle of least privilege is not applied.

4. Mutable action references enable silent supply chain attacks. Using @v2 or @v3 instead of pinned commit SHAs means a compromised upstream action can inject malicious code into every workflow run without any visible change in the workflow file.

5. Scan completed in 253ms via the GitHub Contents API -- no repository clone, no disk I/O, 12 files fetched and analyzed across 30+ detection rules.

Contributing

Contributions are welcome. To add a new detection rule:

1. Choose the appropriate module (github_actions.rs, gitlab_ci.rs, jenkins.rs, or rules.rs for generic patterns)
2. Add a RegexRule entry with: rule ID (KC-NNN), regex pattern, title, severity, description, remediation, CWE IDs
3. Add rule metadata to all_rules() in rules.rs
4. Add a test case in cicd/mod.rs
5. Run cargo test to verify

License

Dual-licensed under MIT and Apache 2.0. Choose whichever you prefer.