* refactor: standardize packaging across all components - Standardize Python version to >=3.12,<3.13 for all components - Migrate from [project.optional-dependencies] to modern [dependency-groups] (PEP 735) - Standardize ruff line-length to 120 characters across all components - Add consistent project metadata: - AGPL-3.0 license field - Repository and Issues URLs - Improved, descriptive description fields - Fix email addresses to include .com domain This improves consistency, maintainability, and follows modern Python packaging best practices with uv/pip standards. * fix: address PR review comments - Move requires-python field to standard position (after license) in seed-gen - Update all components to use latest ruff version (>=0.12.8) - Ensure consistent dependency ordering across all components * refactor: standardize dependency pinning strategy Apply consistent dependency versioning across all components: - Use ~= (compatible release) for core dependencies: - Infrastructure: redis, pydantic, fastapi, uvicorn, sqlalchemy - AI/LLM: openai, langchain-community, langgraph-checkpoint - Parsing: tree-sitter, tree-sitter-language-pack - Web: requests, urllib3, pyyaml - Utils: python-dotenv, unidiff, argon2-cffi, pymongo, six - Keep >= for stable dev tools: - pytest, mypy, ruff, flake8 (want latest versions) - types-* packages (want latest type definitions) - rich, beautifulsoup4 (stable, backwards compatible) - Keep exact pins for known issues: - protobuf (narrow range for compatibility) - openlit==1.32.12 (documented issue with 1.33) - clusterfuzz==2.6.0 (complex, version-sensitive) This provides predictable builds with automatic patch updates while preventing unexpected breaking changes from major/minor version bumps. * feat: add project metadata for discoverability Add comprehensive metadata to all components: Keywords: - common: cybersecurity, crs, utilities, protobuf, redis, telemetry - fuzzer: fuzzing, oss-fuzz, libfuzzer, vulnerability-discovery, coverage - orchestrator: orchestration, task-management, scheduler, api, fastapi - patcher: patching, vulnerability-repair, llm, ai, code-generation - program-model: static-analysis, codequery, tree-sitter, semantic-analysis - seed-gen: test-generation, input-generation, fuzzing, seed-corpus, llm Classifiers: - Development Status :: 4 - Beta (all components) - License :: OSI Approved :: GNU Affero General Public License v3 - Programming Language :: Python :: 3.12 - Topic :: Security (all components) - Component-specific topics (Testing, AI, Distributed Computing, etc.) - Operating System :: POSIX :: Linux URLs: - Added Documentation URL pointing to README for all components This improves package discoverability, provides clear metadata for tools, and gives the project a more professional appearance. * Standardize tool configurations across all components - Add pytest.ini_options configuration to all components - Add coverage configuration with consistent exclude patterns - Standardize ruff configuration with target-version and lint rules - Fix missing readme field in fuzzer/pyproject.toml - Fix python-dotenv spacing inconsistency in seed-gen - Standardize all dev dependencies to use ~= operator for consistency * Fix trailing whitespace and line length issues - Remove trailing whitespace from tree-sitter query strings - Remove trailing whitespace from test output strings - Fix line length issues in logger.info() calls by splitting format strings - Fix line length in datetime formatting by extracting variables - Split long Pydantic Field descriptions and docstrings - Leave test data strings unchanged to avoid breaking tests * Fix dependency resolution issues - Update argon2-cffi from ~=21.0.0 to ~=21.3.0 (21.0.x doesn't exist on PyPI) - Update langgraph-checkpoint from ~=2.0.25 to ~=2.1.0 to match langgraph requirements - Standardize spacing around ~= operators in all dependency specifications - All components now successfully resolve dependencies with uv * Apply ruff auto-fixes across project - Fix import sorting (I001) in fuzzer, orchestrator, and patcher - Update to PEP 585 type annotations (List->list, Dict->dict, etc.) - Update to PEP 604 union syntax (Optional[X] -> X | None) - Remove unnecessary UTF-8 encoding declarations - Remove redundant file open modes - Modernize type annotations throughout the codebase Remaining issues are primarily line length (E501) which require manual review * Fix line length issues in program-model component - Break up long Java code strings in test assertions using implicit concatenation - Split long constructor and method definitions across multiple lines - Add noqa: E501 comment for 10,977 character struct definition test data - All program-model line length issues resolved * fix: revert protobuf enum type annotations to Optional Protobuf enums (EnumTypeWrapper) don't support the | operator for type unions. The ruff UP035 rule converted Optional[ProtobufEnum] to ProtobufEnum | None, but this causes TypeError at runtime. Reverted these specific changes while keeping the modern type union syntax for regular Python types. * chore: add ruff protection for protobuf enum type annotations - Configure ruff to ignore UP045 rule in test_submissions.py - Add inline noqa comments to document why Optional is needed - Protobuf enums (EnumTypeWrapper) don't support the | operator - This prevents future automated fixes from breaking the code * fix: modernize Python syntax and fix formatting issues - Convert printf-style formatting to f-strings (UP031) - Remove trailing whitespace from blank lines (W293) - Use PEP 695 generic class syntax for Python 3.12+ (UP046) - Use PEP 695 type alias syntax with 'type' keyword (UP040) These changes modernize the codebase to use Python 3.12+ features and fix formatting inconsistencies detected by ruff. * fix: resolve undefined MsgType reference after PEP 695 conversion When converting to PEP 695 generic class syntax, the MsgType TypeVar was removed but was still referenced in overloaded method signatures. Changed the generic fallback overload to use Message directly. * fix: resolve line length violations across entire codebase Applied Black formatter and manual fixes to resolve E501 line length violations: - Fixed 178 line length issues across common, fuzzer, orchestrator, patcher, and program-model components - Used Black formatter for automatic reformatting where possible - Manually split long strings, function calls, and complex expressions - All files now comply with 120-character line limit 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * fix: revert PEP 695 type alias syntax in node_local.py The PEP 695 syntax (type X = Y) creates TypeAliasType objects that cannot be used as constructors at runtime. Since node_local.py uses NodeLocalPath and RemotePath as constructors (e.g., NodeLocalPath(path)), we must use the old TypeAlias syntax to maintain runtime functionality. Added noqa comments to prevent ruff from attempting to modernize these aliases in the future. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * chore: configure ruff to ignore UP040 for node_local.py Added per-file configuration to prevent ruff from attempting to convert TypeAlias annotations to PEP 695 syntax in node_local.py. This protects the runtime functionality that relies on these type aliases being usable as constructors. Also removed redundant inline noqa comments since the ignore is now configured at the project level. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * fix: correct MsgType reference in static method decorator The _ensure_group_name static method decorator was incorrectly referencing MsgType in the wrapper function signature. Since MsgType is a class-level type parameter and not accessible in static method scope, changed it to Message which is the appropriate bound type. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * docs: add explanatory comment for Message type in decorator Added a comment explaining why we must use Message instead of MsgType in the _ensure_group_name decorator's wrapper function. This prevents future confusion and protects against accidental "fixes" that would break the code. The MsgType parameter is a class-level type variable that's not in scope within the static method decorator context. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>
Buttercup Cyber Reasoning System (CRS)
Buttercup is a Cyber Reasoning System (CRS) developed by Trail of Bits for the DARPA AIxCC (AI Cyber Challenge). Buttercup finds and patches software vulnerabilities in open-source code repositories like example-libpng. It starts by running an AI/ML-assisted fuzzing campaign (built on oss-fuzz) for the program. When vulnerabilities are found, Buttercup analyzes them and uses a multi-agent AI-driven patcher to repair the vulnerability. Buttercup system consists of several components:
- Orchestrator: Coordinates the overall task process and manages the workflow
- Seed Generator: Creates inputs for vulnerability discovery
- Fuzzer: Discovers vulnerabilities through intelligent fuzzing techniques
- Program Model: Analyzes code structure and semantics for better understanding
- Patcher: Generates and applies security patches to fix vulnerabilities
System Requirements
Minimum Requirements
- CPU: 8 cores
- Memory: 16 GB RAM
- Storage: 100 GB available disk space
- Network: Stable internet connection for downloading dependencies
Note: Buttercup uses third-party AI providers (LLMs from companies like OpenAI, Anthropic and Google), which cost money. Please ensure that you manage per-deployment costs by using the built-in LLM budget setting.
Note: Buttercup works best with access to models from OpenAI and Anthropic, but can be run with at least one API key from one third-party provider (support for Gemini coming soon).
Supported Systems
- Linux x86_64 (fully supported)
- ARM64 (partial support for upstream Google OSS-Fuzz projects)
Required System Packages
Before setup, ensure you have these packages installed:
# Ubuntu/Debian
sudo apt-get update
sudo apt-get install -y make curl git
# RHEL/CentOS/Fedora
sudo yum install -y make curl git
# or
sudo dnf install -y make curl git
# MacOS
brew install make curl git
Supported Targets
Buttercup works with:
- C source code repositories that are OSS-Fuzz compatible
- Java source code repositories that are OSS-Fuzz compatible
- Projects that build successfully and have existing fuzzing harnesses
Quick Start
- Clone the repository with submodules:
git clone --recurse-submodules https://github.com/trailofbits/buttercup.git
cd buttercup
- Run automated setup (Recommended)
make setup-local
This script will install all dependencies, configure the environment, and guide you through the setup process.
Note: If you prefer manual setup, see the Manual Setup Guide.
- Start Buttercup locally
make deploy-local
- Verify local deployment:
make status
When a deployment is successful, you should see all pods in "Running" or "Completed" status.
- Send Buttercup a simple task
Note: When tasked, Buttercup will start consuming third-party AI resources.
This command will make Buttercup pull down an example repo example-libpng with a known vulnerability. Buttercup will start fuzzing it to find and patch vulnerabilities.
make send-libpng-task
- Access Buttercup's web-based GUI
Run:
make web-ui
Then navigate to http://localhost:31323 in your web browser.
In the GUI you can monitor active tasks and see when Buttercup finds bugs and generates patches for them.
- Stop Buttercup
Note: This is an important step to ensure Buttercup shuts down and stops consuming third-party AI resources.
make undeploy
Accessing Logs
Buttercup includes local SigNoz deployment by default for comprehensive system observability. You can access logs, traces, and metrics through the SigNoz UI:
make signoz-ui
Then navigate to http://localhost:33301 in your web browser to view:
- Distributed traces
- Application metrics
- Error monitoring
- Performance insights
If you configured LangFuse during setup, you can also monitor LLM usage and costs there.
For additional log access methods, see the Quick Reference Guide.
Additional Resources
- Quick Reference Guide - Common commands and troubleshooting
- Manual Setup Guide - Detailed manual installation steps
- AKS Deployment Guide - Production deployment on Azure
- Contributing Guidelines - Development workflow and standards
- Deployment Documentation - Advanced deployment configuration
- Writing Custom Challenges - Custom project configuration and setup