We only provide security fixes for the latest release. Please update before reporting.

Do not open a public GitHub issue for security vulnerabilities.

Report vulnerabilities privately via one of the following:

• GitHub Private Advisories: Security Advisories
• Email: If a maintainer email is listed on their GitHub profile, use that.

Please include:

• A clear description of the vulnerability and its potential impact
• Steps to reproduce or a minimal proof-of-concept
• The affected component (e.g., pipeline YAML parsing, processor loader, state ledger, CLI)
• Any suggested mitigations if you have them

You can expect an acknowledgment within 72 hours and a status update within 7 days.

DeepZero is a local pipeline orchestrator. The following areas carry inherent risk and are worth scrutinizing:

DeepZero dynamically loads Python modules from paths specified in pipeline YAML files (e.g., processor: ./modules/example.py:ExampleImplementation). Only run pipelines from sources you trust. A malicious YAML file can execute arbitrary code on your machine.

Pipeline configs are parsed from YAML. DeepZero uses safe YAML loading, but user-supplied configs should still be treated as untrusted input.

The state ledger and work directory are written to the local filesystem based on paths in the pipeline config. Ensure pipeline YAMLs do not specify sensitive or unintended paths for work_dir.

Map-stage processors are parallelized across system workers. Processors that perform network I/O, spawn subprocesses, or access shared resources should be reviewed for race conditions and privilege escalation.

If you are writing a custom processor or contributing upstream:

• Never eval, exec, or deserialize untrusted data inside a processor.
• Avoid hardcoding credentials; use environment variables.
• Keep setup() / teardown() symmetric, don't leave sockets or file handles open.
• Run the required linting and security scan before submitting:

  ruff check . && ruff format --check . && bandit -r src processors

• bandit is already part of the CI gate, address all HIGH and MEDIUM severity findings before opening a PR.

We follow coordinated disclosure. Once a fix is ready, we will:

1. Release a patched version.
2. Publish a GitHub Security Advisory crediting the reporter (unless anonymity is requested).
3. Add a note to the changelog.

We ask that reporters allow us a reasonable remediation window before any public disclosure.