Files
trailofbits-buttercup/CONTRIBUTING.md
T
Michael D Brown 35ce4034ea Simplify README and restructure documentation (#214)
* Simplify README and restructure documentation

- Move AKS deployment docs to separate AKS_DEPLOYMENT.md file
- Move manual setup instructions to MANUAL_SETUP.md file
- Create CONTRIBUTING.md with development workflow and contribution guidelines
- Restructure README to focus on individual users with:
  - Minimum system requirements (8 CPUs, 64GB RAM, 100GB storage)
  - Supported systems/architectures (Linux x86_64, ARM64 in dev)
  - Supported targets (C/Java OSS-Fuzz compatible repositories)
  - Instructions for creating and running challenges
  - GUI component usage instructions
  - Required system packages info
- Remove alternative manual commands (now automated in Makefile)
- Add links to all new documentation files

Fixes #174

Co-authored-by: Michael D Brown <michaelbrownuc@users.noreply.github.com>

* Address review feedback: update system requirements, fix ARM support description, and clean up documentation

- Reduce RAM requirement from 64GB to 16GB (with 10GB basic option)
- Reduce storage requirement from 100GB to 50GB
- Clarify ARM64 support is only for upstream Google OSS-Fuzz projects
- Remove incorrect build system requirement statement
- Update command examples to use make send-libpng-task
- Remove unimplemented GUI features (Results Dashboard, Log Viewer)
- Simplify challenge creation section to focus on pre-defined challenges
- Clean up CONTRIBUTING.md by removing alternative manual commands
- Add SigNoz reference for log monitoring
- Add note about docker-compose directory requirement

Co-authored-by: Riccardo Schirone <ret2libc@users.noreply.github.com>

* Update README.md

* Fix documentation issues after merge conflict resolution

- Fix test command references from send-integration-task to send-libpng-task
- Remove alternative manual commands sections as requested in review
- Clean up merge conflict artifacts
- Update challenge description to be more accurate

Co-authored-by: Michael D Brown <michaelbrownuc@users.noreply.github.com>

* WIP manual edits

* WIP manual edits

* WIP manual edits

* WIP manual edits

* WIP manual edits

* WIP manual edits

* Update README.md

* Update README.md

* Update README.md

* Update README.md

Co-authored-by: Ronald Eytchison <58823072+reytchison@users.noreply.github.com>

* Update README.md

Co-authored-by: Ronald Eytchison <58823072+reytchison@users.noreply.github.com>

* Update CONTRIBUTING.md

* Update CONTRIBUTING.md

Co-authored-by: Ronald Eytchison <58823072+reytchison@users.noreply.github.com>

* Update README.md

Co-authored-by: Ronald Eytchison <58823072+reytchison@users.noreply.github.com>

* Update CONTRIBUTING.md

Co-authored-by: Ronald Eytchison <58823072+reytchison@users.noreply.github.com>

---------

Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Michael D Brown <michaelbrownuc@users.noreply.github.com>
Co-authored-by: Riccardo Schirone <ret2libc@users.noreply.github.com>
Co-authored-by: Riccardo Schirone <562321+ret2libc@users.noreply.github.com>
Co-authored-by: Ronald Eytchison <58823072+reytchison@users.noreply.github.com>
2025-08-04 20:44:41 -04:00

4.7 KiB

Contributing to Buttercup CRS

Thank you for your interest in contributing to the Buttercup Cyber Reasoning System! This guide will help you get started with development and understand our workflows.

Development Setup

Before contributing, set up your local development environment:

# Clone with submodules
git clone --recurse-submodules https://github.com/trailofbits/buttercup.git

# Quick setup (recommended)
make setup-local

# Start development environment
make deploy-local

Development Workflow

Using Makefile Shortcuts

The Buttercup CRS project includes a Makefile with convenient shortcuts for common tasks:

# View all available commands
make help

# Setup
make setup-local          # Automated local development setup
make setup-azure          # Automated production AKS setup
make validate             # Validate current setup and configuration

# Deployment
make deploy               # Deploy to current environment (local or azure)
make deploy-local         # Deploy to local Minikube environment
make deploy-azure         # Deploy to production AKS environment

# Status
make status               # Check the status of the deployment

# Testing
make send-libpng-task          # Run libpng test task

# Development
make lint                 # Lint all Python code
make lint-component COMPONENT=orchestrator  # Lint specific component

# Cleanup
make undeploy             # Remove deployment and clean up resources
make clean-local          # Delete Minikube cluster and remove local config

Code Quality Standards

All Python components use consistent formatting and linting standards:

  • Formatter: ruff format
  • Linter: ruff check
  • Type Checker: mypy (for common, patcher, and program-model components)

Running Tests

# Lint all Python code
make lint

# Lint specific component
make lint-component COMPONENT=orchestrator

# Run test task
make send-libpng-task

Development Tools

Kubernetes Development

# Port forward for local access  
kubectl port-forward -n crs service/buttercup-competition-api 31323:1323

# View logs
kubectl logs -n crs -l app=scheduler --tail=-1 --prefix

# Debug pods
kubectl exec -it -n crs <pod-name> -- /bin/bash

Component Architecture

The system consists of several key components:

  • Common (/common/): Shared utilities, protobuf definitions, Redis queue management, telemetry
  • Orchestrator (/orchestrator/): Central coordination, task server, scheduler, competition API client
  • Fuzzer (/fuzzer/): Automated vulnerability discovery (build-bot, fuzzer-bot, coverage-bot, tracer-bot)
  • Program Model (/program-model/): Semantic code analysis using CodeQuery and Tree-sitter
  • Patcher (/patcher/): LLM-powered automated patch generation
  • Seed Generation (/seed-gen/): Intelligent input generation

Contribution Guidelines

Code Style

  • Follow existing code patterns and conventions in each component
  • Use structured logging via the common logging module
  • Implement proper error handling with circuit breakers for external service calls
  • Use Pydantic models for data validation
  • Write comprehensive tests for new functionality

Testing

Each component should include:

  • Unit tests using pytest
  • Mock external dependencies (Redis, LLM APIs, file system)
  • Integration tests using Docker containers
  • Test data stored in <component>/tests/data/

Security Considerations

  • All untrusted code execution must happen in isolated Docker containers
  • Never expose or log secrets and keys
  • Never commit secrets or keys to the repository

Submitting Changes

  1. Create a feature branch from the main branch
  2. Make your changes following the code style guidelines
  3. Test your changes using the appropriate test commands
  4. Lint your code using make lint or component-specific linting
  5. Create a pull request with a clear description of your changes

Python Package Management

Each component uses uv for dependency management:

# Install dependencies
cd <component> && uv sync

# Install with dev dependencies
cd <component> && uv sync --all-extras

# Add new dependency
cd <component> && uv add <package>

# Update dependencies
cd <component> && uv lock --upgrade

Getting Help

  • Validate your setup: make validate - Check if your environment is ready
  • Check the Quick Reference Guide for common commands and troubleshooting
  • Check the deployment README for detailed deployment information
  • Check logs: kubectl logs -n crs <pod-name>

Questions?

If you have questions about contributing, please feel free to open an issue or reach out to the development team.