Pulp Engine — Security Policy
We take security seriously. This document describes how to report a vulnerability, what we commit to in response, and what is in and out of scope.
Pulp Engine is self-hosted software: each deployment is operated by its owner. A vulnerability in Pulp Engine itself may expose data in every deployment, so we prefer to hear about security issues before they become public.
Reporting a vulnerability
Email: troy@tksolutions.co.nz (replace with your organisation’s contact in forks).
Please include:
- A description of the issue and the potential impact.
- Reproduction steps, a proof-of-concept, or a patch.
- The Pulp Engine version (commit SHA or release tag) you tested against.
- Whether you believe the issue is being exploited in the wild.
If you require encryption for transport, request our PGP public key in your initial message and we will reply with it.
Please do not post to a public forum, tweet, or otherwise disclose the issue until we have had a chance to respond and ship a fix.
What you can expect from us
| Stage | Target |
|---|---|
| Acknowledge receipt | Within 3 business days |
| Initial triage & severity assessment | Within 7 business days |
| Status update cadence during investigation | Every 14 days until resolved or closed |
| Fix window for critical issues (RCE, auth bypass, cross-tenant leak) | Aim for a patched release within 30 days |
| Fix window for other issues | Aim for a patched release within 90 days |
| Public disclosure | Coordinated — we will agree a date with the reporter, typically ≤ 90 days from triage or on release, whichever comes first |
We will credit reporters in the release notes unless they prefer to remain anonymous. We do not currently operate a paid bug-bounty programme.
Scope
In scope:
- The Pulp Engine API server (apps/api).
- The editor web app (apps/editor).
- The render workers and controllers (apps/worker, Dockerfile.worker / Dockerfile.controller).
- Official packages under packages/ (SDKs, CLI, plugin API, renderers).
- Official Docker images published to GHCR.
Out of scope:
- Vulnerabilities in third-party dependencies that are already publicly disclosed (please file upstream; we will upgrade through normal dependency maintenance).
- Issues that require an attacker to already have admin credentials — by design, admin access is full trust.
- Missing rate limits on endpoints where rate limiting is explicitly opt-in and the operator chose not to enable it.
- Attacks requiring physical access to the operator’s infrastructure.
- Self-hosted instances operated by third parties — please report those to the operator.
- Denial-of-service via resource exhaustion of rendering capacity (operator concern; see render isolation modes).
- Issues in community or third-party plugins — report to the plugin maintainer.
Coordinated disclosure
We prefer coordinated disclosure. If a fix requires a coordinated release with downstream operators (e.g. a fix that changes the upgrade path), we may ask to extend the public-disclosure window. We will communicate the reason and a revised target.
Recognition
Reporters who follow this policy are acknowledged in the release notes for the fix. Previous advisories and their reporters are listed on the releases page.
Policy versioning
This policy is versioned with the repository. See .well-known/security.txt for the machine-readable summary consumed by automated scanners (RFC 9116).