Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
110 lines (81 loc) · 3.39 KB

CONTRIBUTING.md

File metadata and controls

110 lines (81 loc) · 3.39 KB

Contributing to Spring2Shell

Thank you for your interest in contributing to Spring2Shell! Contributions from the security research and developer community are vital to keeping this project robust, performant, and up-to-date.

Please read our Code of Conduct before participating in this project.

📖 Table of Contents

  1. Our Policy on Responsible Disclosure
  2. How Can I Contribute?
  3. Local Development Setup
  4. Code Quality & Linting
  5. Testing Guidelines
  6. Pull Request Process

🛡️ Our Policy on Responsible Disclosure

Because Spring2Shell is a vulnerability scanner and security assessment tool:

  • Do NOT open public issues for security vulnerabilities found within Spring2Shell itself.
  • Instead, please refer to our Security Policy for details on how to report vulnerabilities privately.

How Can I Contribute?

  • Reporting Bugs: First, search the existing issues. If your problem hasn't been reported, open an issue using the Bug Report template.
  • Suggesting Features: Open an issue using the Feature Request template, detailing the proposed change and its benefits.
  • Adding Payloads / Signatures: We welcome PRs that update data/payloads/cve_payloads.json to cover new CVEs or add evasion techniques.
  • Submitting Pull Requests: Fix open issues or implement approved feature requests.

Local Development Setup

To set up a local development environment:

  1. Fork and Clone the repository:

    git clone https://github.com/your-username/Spring2Shell.git
cd Spring2Shell

  2. Set up a Virtual Environment:

    make venv
source .venv/bin/activate

  3. Install Dependencies in Editable Mode:

    make install-dev

Code Quality & Linting

We maintain high code quality and strict formatting standards using ruff and mypy. Before submitting a pull request, ensure your code passes all checks:

  • Format Code: 
    make format
  • Lint Code: 
    make lint
  • Type Checking: 
    make typecheck
  • Run All Quality Checks: 
    make check

Testing Guidelines

We use pytest for unit and integration testing. Any new features or bug fixes must include corresponding tests.

  • Run all tests (with coverage report): 
    make test
  • Run unit tests only: 
    make test-unit
  • Run integration tests only: 
    make test-integration

Ensure that coverage does not drop as a result of your contribution.

Pull Request Process

  1. Branch Naming: Use descriptive branch names (e.g., feature/add-cve-2026-xxxx or fix/connection-timeout).
  2. Commit Messages: Write clear, descriptive commit messages matching standard conventions (e.g., feat: add scanner support for CVE-2026-XYZ).
  3. Update Documentation: If your change introduces new flags, CLI modes, or configuration values, update the README.md and relevant help screens.
  4. Pass CI/CD: Ensure all tests and lints pass.
  5. Open Pull Request: Fill out the provided Pull Request Template completely so the maintainers can review your changes efficiently.