Cybersec Toolkit README

    /\   /\        ______      __              _____
   (o ) ( o)      / ____/_  __/ /_  ___  _____/ ___/___  _____
    \ \_/ /      / /   / / / / __ \/ _ \/ ___/\__ \/ _ \/ ___/
  <==\   /==>   / /___/ /_/ / /_/ /  __/ /   ___/ /  __/ /__
     \ V /      \____/\__, /_.___/\___/_/   /____/\___/\___/
     /_ _\           /____/                          by 26zl
      |_|                     Toolkit

“I am a friend of virtue, not of fortune.”
— Gjergj Kastrioti · Skanderbeg (1405–1468)

A security toolkit that AI agents can drive, under rules you set. One command installs 670+ security tools on Linux or Termux. An MCP (Model Context Protocol) server lets Claude Code, Codex, Gemini CLI, OpenCode, and other MCP clients discover, recommend, and run those tools through a governed execution path, inside a disposable Kata Containers VM by default. 872 Agent Skills supply the methodology for CTF, pentest, bug bounty, DFIR, and blue-team work.

What makes it different: most toolkits stop at installing tools. Here an AI can also drive them: infer the problem type, pick tools from every module and profile, and work through the problem with you step by step. When you explicitly authorize it, the same toolchain runs an autonomous solver loop. Companion by default; autonomous only when you ask. It complements Kali, Parrot, or BlackArch rather than replacing them: it runs on the machine you already have, Termux included.

Quick start · How it works · Trust & safety · Installer · MCP server · Agent Skills · Development · License

Quick start

1. Install the tools on a supported Linux distro or on Termux:

git clone --depth 1 --branch v1.3.0 https://github.com/26zl/cybersec-toolkit.git && cd cybersec-toolkit
./install.sh --doctor             # read-only preflight: distro, prerequisites, MCP server, sandbox
sudo ./install.sh --profile ctf   # one profile; with no flags, all 18 modules

2. Connect an AI client. The tracked configs for Claude Code (.mcp.json), Codex, Gemini CLI, and OpenCode start the server through scripts/mcp-launch.sh, with external targets and script execution disabled. Choose where the tools run:

Kata needs KVM: on macOS, on Windows, and in VMs without nested virtualization, use host mode.

3. Restart the client. The 15 tools appear (/mcp in Claude Code). Then ask for what you need, for example "triage this binary" or "map the attack surface of my lab at 10.10.0.0/24".

How it works

Two entry points share one tool registry. An operator runs the bash installer to put tools on disk: on the host, or into the sandbox image at build time. An AI agent talks to the MCP server, which runs inside a Kata VM by default, to discover, recommend, and execute those tools through one governed path. tools_config.json is the single source of truth that the modules define and the MCP advisors read; CI validators keep the Python and bash sides in sync.

Solid arrows are runtime or installation actions; dashed arrows are validation and context relationships. Client configurations enter through the root-aware launcher, which boots the VM through a Sandcastle Kata provider (sandbox/kata.mjs) — or, with --local, starts the server on the host. security.py governs run_tool and run_pipeline through the allowlist, argument checks, and network policy without invoking a shell. run_script is a separate, disabled-by-default capability that runs arbitrary code. Agent Skills stay outside the execution path: .claude/skills/ is canonical, and scripts/sync-skills.sh generates .agents/skills/ for clients that read the portable mirror. Mermaid source: assets/how-it-works.mmd.

Trust & safety

What runs, and what is gated:

• Default-safe MCP. CYBERSEC_MCP_ALLOW_EXTERNAL=0 rejects network targets that do not resolve to private or loopback ranges, and CYBERSEC_MCP_ALLOW_SCRIPTS=0 disables run_script. External scopes and scripting are explicit opt-ins.
• One gate for governed execution (mcp_server/security.py): registry allowlist, no shell (create_subprocess_exec, never shell=True), argument sanitization, a per-tool blocked-flag denylist (e.g. sqlmap --os-shell, nmap -iL, file-list and target-injection flags), target and network policy, rate limiting, output caps, and timeouts. The policy knows enough CLI grammar to tell a target from a header, wordlist, output path, or target-list flag. Tool output reaches the model without terminal escape sequences or LLM control markers, and lines addressed to an AI reader are flagged.
• Tools run in a disposable VM by default. The launcher boots a Kata Containers VM with its own kernel, no host filesystem beyond an optional CYBERSEC_SANDBOX_WORKSPACE mount, no Docker socket, a non-root user with every capability dropped, and memory, CPU, and process limits. It is destroyed when the client disconnects. Startup fails closed instead of falling back to the host; --local is the explicit opt-out.
• Know the limits. The VM is not a network boundary: it reaches whatever its Docker network reaches, and CYBERSEC_MCP_ALLOW_EXTERNAL is a preflight check on resolved addresses, not a firewall (set CYBERSEC_SANDBOX_NETWORK=none or use a filtered network). Inside the VM, and on your host in --local mode, allowed tools run with the server user's permissions, and some of them spawn child processes or load plugins.
• Audit trail without leaks. Actions are logged as JSON lines to an owner-only (0600), rotating log under the user's state directory (~/.local/state/cybersec-tools-mcp/audit.log by default). Script bodies are never stored, only their SHA256 and length, and credential-shaped strings are redacted from tool arguments. A sandboxed server mirrors its records to the same host log, and records are hash-chained, so an edited or deleted record inside a chain shows up in make audit-verify (limits).
• Least privilege in the installer. It runs as root but drops to the invoking user ($SUDO_USER) for cloned-repo builds and pip/cargo/gem installs; binary releases are SHA256-verified when checksums are published.
• Dual-use tooling is gated. C2 and phishing frameworks (Sliver, Caldera, gophish, evilginx, …) are off by default and install only with --include-c2 (the redteam and full profiles set it); the MCP layer reflects this and never auto-runs them.
• Authorized use only. See SECURITY.md, the supply chain model, and the disclaimer.

Installer

Requirements

A supported Linux distro (Debian/Ubuntu/Kali/Parrot, Fedora/RHEL, Arch, openSUSE) or Termux. Runtimes (Python, Go, Ruby, Java, Rust, Node.js), dev libraries, pipx, and build tools are installed automatically. The installer does not run on macOS or native Windows; use WSL or Docker.

• Docker is needed only for --enable-docker (C2 frameworks, MobSF, BeEF, BloodHound, TheHive, Cortex). Install it yourself: Docker Engine docs.
• GitHub authentication is recommended. The installer downloads ~50 release binaries and makes ~50+ GitHub API calls; unauthenticated requests are limited to 60 per hour, authenticated ones to 5,000. It uses your gh auth login session automatically, also under sudo. Alternatively, pass a personal access token (no scopes needed) through sudo, which otherwise drops it: sudo --preserve-env=GITHUB_TOKEN ./install.sh.

Install

From the latest release (pinned; recommended):

git clone --depth 1 --branch v1.3.0 https://github.com/26zl/cybersec-toolkit.git && cd cybersec-toolkit && sudo ./install.sh

From main (newest tools and fixes, including unreleased work):

git clone https://github.com/26zl/cybersec-toolkit.git && cd cybersec-toolkit && sudo ./install.sh

With no flags, the installer covers the standard tools of all 18 modules. C2/phishing tools and Docker images stay opt-in; --profile full --enable-docker installs everything the current platform supports. To install a subset:

sudo ./install.sh --profile ctf                      # CTF tools only
sudo ./install.sh --profile redteam --enable-docker  # Red team + Docker C2
sudo ./install.sh --module web --module recon        # Specific modules
sudo ./install.sh --tool sqlmap --tool nmap          # Individual tools
sudo ./install.sh --dry-run --profile ctf            # Preview without installing
./install.sh --doctor                                # Read-only preflight; no root needed

sudo ./install.sh --help                # Full help
sudo ./install.sh --list-profiles       # Show profiles
sudo ./install.sh --list-modules        # Show modules
sudo ./install.sh --skip-heavy          # Skip large/slow packages
sudo ./install.sh --skip-pipx           # Skip all pipx (Python) installs
sudo ./install.sh --skip-go             # Skip all Go tool installs
sudo ./install.sh --skip-cargo          # Skip all Cargo (Rust) installs
sudo ./install.sh --skip-gems           # Skip all Ruby gem installs
sudo ./install.sh --skip-git            # Skip all git clone installs
sudo ./install.sh --skip-binary         # Skip all binary release downloads
sudo ./install.sh --skip-source         # Skip build-from-source, snap, npm, and curl-pipe installs
sudo ./install.sh --fast                # Skip checksum verification (see Supply chain model)
sudo ./install.sh --require-checksums   # Fail if a binary release has no checksum file
sudo ./install.sh --production          # Strict checksum preset for release downloads
sudo ./install.sh --upgrade-system      # Upgrade system packages before installing
sudo ./install.sh --list-sessions       # List install sessions and exit
sudo ./install.sh --rollback <id|last>  # Roll back tools installed in a session
sudo ./install.sh --version             # Show installer version and exit
sudo ./install.sh --enable-docker       # Pull Docker images
sudo ./install.sh --include-c2          # Include C2/phishing frameworks (Empire also needs --enable-docker)
sudo ./install.sh -j 8                  # 8 parallel install jobs (default: 4)
sudo ./install.sh -v                    # Verbose / debug output

Docker and Podman

The prebuilt image is the installer on Ubuntu, not a sandbox. Its default command is a dry run of the full profile:

docker run --rm ghcr.io/26zl/cybersec-toolkit                                  # preview only
docker run -it --name cybersec --entrypoint bash ghcr.io/26zl/cybersec-toolkit  # keep a container
sudo ./install.sh --profile ctf                                                # inside it; reattach with: docker start -ai cybersec

Build it yourself with docker build -t cybersec-toolkit ., or run a throwaway install through the bundled Compose file with docker compose run --rm installer --profile ctf. On Apple silicon, add --platform linux/amd64 to docker build and docker run. Podman works as a drop-in replacement (podman compose needs a compose provider). The image grants the toolkit user passwordless sudo so the installer can manage packages; treat code inside it as root-capable.

Termux (Android)

pkg install git
git clone https://github.com/26zl/cybersec-toolkit.git && cd cybersec-toolkit
./install.sh --profile lightweight

Profiles

Modules

Post-install scripts

All scripts support --help and need root on Linux (sudo); Termux needs no root.

--deep-clean removes the Go module/build cache, the Cargo registry, pip/pipx/npm/gem caches, orphaned pipx venvs, stale symlinks, and log files. Add --remove-deps to also purge Rustup toolchains.

Distro support

Debian/Ubuntu/Kali is the primary target and has the strongest test coverage: Kali and Parrot get the full apt set, while plain Debian/Ubuntu skip a handful of Kali-only packages. Fedora, Arch, and openSUSE skip the packages their repositories do not carry (the - entries in lib/distro_compat.tsv, several dozen per distro) and run in the integration workflow.

Supply chain model

The installer downloads and runs code from the internet. On Linux it runs as root (sudo); on Termux it runs in the app's user sandbox.

• System packages: signed by your distro's repositories (apt, dnf, pacman, zypper, pkg).
• pipx/Go/Cargo/Gem/npm: fetched from their registries without signature verification; pipx tools are isolated in venvs.
• Binary releases: SHA256-verified when the release publishes a checksum file, with a hard failure on mismatch. About half of the upstream releases publish none; --require-checksums or the --production preset fails those tools instead of installing them unverified. --fast disables all checksum verification, including for releases that publish checksums, and cannot be combined with the strict flags; keep it out of CI and production.
• Runtime bootstraps: the rustup, uv, and cargo-binstall installers and NodeSource's setup script (run as root) are fetched over HTTPS and sanity-checked before they run, but not signature-verified. cargo-binstall then downloads prebuilt Rust binaries where available; --skip-source skips its installer on a fresh host, so Rust tools compile from crates.io.
• Go SDK: SHA256-verified against go.dev when the API is reachable; strict mode fails if it is not.
• Git repos: cloned at HEAD; dependencies go into isolated venvs, and setup.py is not executed.
• Build from source: runs make, as root on Linux. Review what you build.
• MCP Python dependencies: resolved by uv with a 3-day exclude-newer window, and Dependabot waits the same 3 days. This does not apply to the security tools themselves, which follow their upstream release channels.
• Toolkit Docker images: Ubuntu and uv are digest-pinned; apt packages resolve from the current signed Ubuntu repositories, so rebuilds are not bit-for-bit reproducible.
• Optional tool images: pulled by mutable tags, several of them latest. --production does not pin or verify them.

--production does not pin Git clones, language-package registries, or build-from-source tools; those track their upstream release channels.

Windows Defender false positives

On a Windows-mounted path (e.g. C:\Users\<you>\..., or any folder visible from Windows while you work in WSL), Microsoft Defender and other AV products may quarantine individual files. IOC tables, sample obfuscated PowerShell, malware-analysis snippets, and exploit strings in .claude/skills/, writeups/, and parts of mcp_server/ contain the same byte patterns real attackers use. Common verdicts include Trojan:Script/Wacatac.B!ml, HackTool:*, and generic Heur.*. These are false positives for a security toolkit.

MCP server

The server gives MCP-capable clients read access to the 670+ tool registry, install status and recommendations, and governed execution of installed tools. The agent knows every tool, which ones are available, and how to chain them.

Supported clients

Per-client setup is in docs/AI_CLIENTS.md; coordinating several agents across any MCP client is in docs/ORCHESTRATION.md.

The server is published to the official MCP Registry as io.github.26zl/cybersec-toolkit and listed on Glama:

What the AI can do

Sandbox and host mode

scripts/mcp-launch.sh starts the server inside a Kata Containers VM unless you pass --local or set CYBERSEC_SANDBOX_MODE=local. The VM is created by a Sandcastle isolated-sandbox provider (sandbox/kata.mjs) that pins the Kata runtime; the same provider can also back a Sandcastle agent-orchestration loop instead of an MCP client. Startup fails closed: a missing runtime, sandbox image, KVM device, Node.js, or launcher dependency stops the server with the reason instead of falling back to the host. ./install.sh --doctor reports sandbox readiness. Setup, tuning, and the threat model are in docs/SANDBOX.md.

• The VM has its own tool set. The sandbox image ships the MCP server plus file, git, binutils, nmap, curl, and Python. Tools installed on the host are not visible inside it, and check_installed and the advisors report the guest's tools. Bake a profile into the image instead, and rebuild after pulling server changes, because the image carries its own copy of the server:

  Terminal

  Copy

  docker build -f sandbox/Dockerfile --build-arg TOOLKIT_PROFILE=ctf -t cybersec-toolkit-sandbox:latest .
  

• Files: the VM sees no host path unless CYBERSEC_SANDBOX_WORKSPACE names an absolute directory, which appears as /workspace (read-only with CYBERSEC_SANDBOX_WORKSPACE_RO=1). Pass guest paths to run_tool.

• Network: the VM uses Docker's default bridge. Set CYBERSEC_SANDBOX_NETWORK=none for offline analysis, or a filtered Docker network to scope egress.

• Privileges: uid 10001, all capabilities dropped, no-new-privileges, and 2 GB / 2 vCPUs / 512 processes by default. Raw-socket scans (nmap -sS, -sU, OS detection) need CYBERSEC_SANDBOX_CAP_ADD=NET_RAW.

• Host mode only: remote execution over SSH (manage_remote_hosts) and venvs under ~/.ctf-venvs/ that you created on the host.

• Audit: records leave the VM on a stderr side channel and are appended to the host log, so the trail outlives the VM.

Client setup

Claude Code reads the tracked .mcp.json:

{
  "mcpServers": {
    "cybersec-tools": {
      "command": "bash",
      "args": [
        "-lc",
        "cd \"$(git rev-parse --show-toplevel)\" && exec bash scripts/mcp-launch.sh"
      ],
      "env": {
        "CYBERSEC_MCP_ALLOW_EXTERNAL": "0",
        "CYBERSEC_MCP_ALLOW_SCRIPTS": "0"
      }
    }
  }
}

The login shell (bash -lc) picks up node and uv from your profile, so profile scripts must not print to stdout, which carries the MCP protocol. Other clients use the same launcher; from any directory:

bash /path/to/cybersec-toolkit/scripts/mcp-launch.sh           # Kata VM (default)
bash /path/to/cybersec-toolkit/scripts/mcp-launch.sh --local   # host, no VM boundary

• Codex: the project .codex/config.toml resolves the Git root first, so it works from any subdirectory. If Codex ignores project config, copy the [mcp_servers.cybersec-tools] block into ~/.codex/config.toml.
• Cursor / Continue / Cline / Goose: add the launch command in the client's MCP settings, with an absolute path if the client's working directory is not the repo root.
• LM Studio (≥0.3.17): an MCP host itself. Add the server to its mcp.json (same mcpServers shape as .mcp.json) with an absolute path. MCP over LM Studio's API needs ≥0.4.0 and an MCP-capable endpoint such as /api/v1/chat or /v1/responses.
• Ollama and other local models: a model runtime does not speak MCP. Put an MCP-capable host in front of it (OpenCode, Hermes, OpenClaw, Kit, LM Studio, Cline, Continue, Goose, or Open WebUI through an MCP→OpenAPI bridge such as mcpo) and point that host at the launcher.

Start with this one server and keep scripts and external targets off unless you have an authorized scope; prefer hosts with human-in-the-loop tool approval. Vendor-neutral repository instructions live in AGENTS.md; Claude Code reads CLAUDE.md, Gemini CLI reads GEMINI.md.

{
  "mcpServers": {
    "cybersec-tools": {
      "command": "wsl",
      "args": [
        "-d", "kali-linux",
        "bash", "-lc",
        "cd ~/cybersec-toolkit/mcp_server && uv run fastmcp run server.py --transport stdio --no-banner"
      ]
    }
  }
}

{
  "mcpServers": {
    "cybersec-tools": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "CYBERSEC_MCP_ALLOW_EXTERNAL=0", "-e", "CYBERSEC_MCP_ALLOW_SCRIPTS=0",
        "--entrypoint", "bash", "cybersec-toolkit",
        "-c",
        "cd /opt/cybersec-toolkit/mcp_server && uv run fastmcp run server.py --transport stdio --no-banner"
      ]
    }
  }
}

Script execution

run_script lets the agent write and run Python or Bash. Enable it with "CYBERSEC_MCP_ALLOW_SCRIPTS": "1" in the client's env block. Scripts get the server process's filesystem and network permissions (the VM by default, your user in --local mode), and CYBERSEC_MCP_ALLOW_EXTERNAL does not constrain them. Review generated code and scope before opting in.

Python libraries without console scripts live in named venvs under ~/.ctf-venvs/ (override with CYBERSEC_MCP_VENVS_DIR), selected per script with the venv parameter. ./install.sh --module crypto creates ~/.ctf-venvs/crypto with pycryptodome, sympy, gmpy2, numpy, z3, fpylll (+ cysignals, which fpylll needs at import time but does not declare), and cypari2, so the agent can call run_script(code, venv="crypto"). In the sandbox, venvs are guest paths: build the image with TOOLKIT_PROFILE=ctf to get crypto. Some packages need an older Python, for example pwntools:

python3.12 -m venv ~/.ctf-venvs/pwntools
~/.ctf-venvs/pwntools/bin/pip install pwntools z3-solver

Without a named venv, scripts see FastMCP and the standard library; cd mcp_server && uv sync --extra ctf-core adds requests, pycryptodome, beautifulsoup4, Pillow, and NumPy.

Reusable helpers the agent writes for you (exploits, multi-step solvers, parsers, protocol helpers) are saved under manual_scripts/. In companion mode the agent proposes a script and runs it only after you approve; in autonomous mode it writes and runs scoped helpers when tools and pipelines stop making progress. Plain recon and HTTP requests stay run_tool calls.

Test the server

cd mcp_server && uv run fastmcp dev server.py

This opens the MCP Inspector for exercising each tool interactively. mcp_server/README.md covers Claude Desktop setup and the full server reference.

Agent Skills

872 Agent Skills live in .claude/skills/, the canonical tree that Claude Code discovers directly. Skills load on demand for the task at hand instead of occupying context permanently. 31 are project-authored and 841 are curated from open-source projects, each attributed in THIRD_PARTY_NOTICES.md:

• 10 project developer skills (add-tool, validate-all, module-scaffold, writeup-template, mcp-sync-check, security-wordlists, security-payloads, guided-assessment, skill-dependency-audit, skill-curation-router)
• 4 cross-skill coordinators (finding-triage, security-comms, authorization-gate, evidence-hygiene) that route findings, communication, authorization checks, and evidence sanitization
• 7 coverage-gap anchors (GRC/privacy, AI/LLM security, IoT/embedded/hardware, mainframe, telecom/5G, SAP/ERP, supply-chain/product security)
• 6 CTF methodology skills (ctf-crypto, ctf-pwn, ctf-web, ctf-rev, ctf-forensics, ctf-stego) and 4 bug bounty methodology skills (bounty-recon, bounty-web, bounty-api, bounty-mobile)
• 754 operational how-tos from mukul975/Anthropic-Cybersecurity-Skills (Apache 2.0)
• 58 offensive methodology skills from SnailSploit Claude-Red (MIT)
• 14 code audit skills from Trail of Bits (CC-BY-SA 4.0)
• 10 bug bounty workflow skills from BugHunter (claude-bug-bounty) (MIT)
• 4 high-level workflows from Transilience (MIT)
• 1 coding-agent workflow skill from multica-ai/andrej-karpathy-skills (MIT)

Source and category index: .claude/skills/SKILLS.md. Ranking and curation: .claude/skills/CURATION.md and curation.json, regenerated with python3 scripts/curate_claude_skills.py --write.

As a Claude Code plugin. The repo doubles as a plugin marketplace, so any project can pull in the skill library without cloning:

/plugin marketplace add 26zl/cybersec-toolkit
/plugin install cybersec-toolkit@cybersec-toolkit

The plugin carries the skills only; the MCP server is configured separately (see MCP server).

In other clients. OpenCode, Codex, Gemini CLI, GitHub Copilot, Cursor, Cline, Goose, Hermes, and OpenClaw support Agent Skills through their own paths. scripts/sync-skills.sh mirrors .claude/skills/ into the git-ignored .agents/skills/ for clients that read that location (--check reports drift; make setup runs it). Continue and LM Studio do not document automatic skill discovery; give them selected skill content as rules or context instead. Details: docs/AI_CLIENTS.md.

Helper-script dependencies. Some vendored skills include helper scripts with optional Python imports, declared in .claude/skills/requirements.txt and generated from the import inventory. scripts/validate_claude_skills.py checks skill metadata, index counts, curation freshness, and helper-script syntax.

python3 scripts/audit_skill_dependencies.py --check-declared   # verify declarations
python3 -m pip install -r .claude/skills/requirements.txt      # optional, ideally in a venv

Development

Contributions are welcome: testing installs on different distros, adding missing tools, fixing package mappings, improving MCP workflows, writing example use cases, and reporting rough edges from real CTF, lab, bug bounty, pentest, DFIR, or defensive work. Open an issue for bigger changes or send a focused PR for small fixes; CONTRIBUTING.md has the validation checklist.

git clone https://github.com/26zl/cybersec-toolkit.git && cd cybersec-toolkit
make setup    # submodules, MCP deps, sandbox deps, skill mirror
make check    # lint, validators, bats, pytest, sandbox tests

make help lists every target; the raw commands are in AGENTS.md. The MCP Python project resolves dependencies with uv and exclude-newer = "3 days", so fresh releases are ignored for 72 hours to limit the blast radius of a compromised upload; Dependabot and the weekly uv update workflow use the same cooldown. Run the shell tests on Linux, macOS, or WSL: native Windows checkouts can rewrite the Bats submodules with CRLF and fail with $'\r'.

Star History

License

MIT License. See LICENSE.

The repository also redistributes third-party components under their own terms, including some under CC-BY-SA-4.0 (ShareAlike, not relicensable to MIT). If you redistribute or adapt bundled content, follow those terms; see THIRD_PARTY_NOTICES.md.

Contribution workflow: CONTRIBUTING.md. Community expectations: CODE_OF_CONDUCT.md. Vulnerability reporting: SECURITY.md.

Disclaimer

This project is provided for educational, defensive, and explicitly authorized security testing only. Use it only on systems you own or have written permission to assess, and follow all applicable laws, rules of engagement, third-party tool licenses, and service terms.

The toolkit includes dual-use offensive and defensive tools. Some commands can scan networks, execute exploits, modify systems, or trigger security alerts. MCP/AI integrations are guarded by safety policies, but users remain responsible for reviewing scope, prompts, commands, and outputs before running actions.

This repository does not redistribute the security tools themselves; it installs publicly available, open-source projects from their official upstream sources at install time. It is intended for lawful, authorized use only.

The project is provided "as is", without warranty. Maintainers are not responsible for misuse, damage, data loss, service disruption, or legal consequences from using this toolkit.

Third-party content is bundled under its original license — see THIRD_PARTY_NOTICES.md.