Pulse sits inline with your telemetry stream, so we treat security reports with the urgency of a production incident. This document explains how to report a vulnerability, what to expect from us, and what is in scope.

Please do not open a public issue for security reports.

Report vulnerabilities privately through GitHub Private Vulnerability Reporting ("Report a vulnerability" under the repository's Security tab). This keeps the report confidential between you and the maintainers while we work on a fix, and lets us publish a coordinated advisory with credit to you.

Include what you can of the following — partial reports are welcome:

• Affected component (control-plane, data-plane / pulse_filter, Helm chart, container images, CI workflows) and version or commit.
• Reproduction steps or a proof of concept.
• Impact assessment: what an attacker gains (data exposure, rule tampering, telemetry loss, denial of service).
• Any suggested remediation.

If we cannot meet a target we will tell you why and keep you updated. We will credit you in the advisory unless you prefer to remain anonymous.

Security fixes ship as patch releases on the newest minor line and are announced via GitHub Security Advisories on this repository.

In scope — anything that breaks Pulse's security model beyond its documented assumptions, including:

• Authentication or authorization flaws in the Control Plane API beyond the documented V1 trust model (e.g. fleet-key bypass, cross-fleet policy access, IDOR on policy/stats endpoints).
• Data plane vulnerabilities: crashes, memory corruption, or resource exhaustion triggered by crafted OTLP payloads; REDACT bypasses that leak data a rule should have masked; rule-evaluation flaws that drop or leak telemetry contrary to policy.
• Injection of any kind (SQL via Prisma bypass, header injection in the sync client, template injection in the Helm chart).
• Vulnerabilities in our build and release pipeline (workflow privilege escalation, cache poisoning, image tampering).
• Secrets or sensitive data unintentionally baked into published container images (other than the documented local-dev seed credentials).

Out of scope — known, documented V1 limitations (see Security Posture & Roadmap):

• The Control Plane shipping without built-in user authentication (RBAC/SSO is on the roadmap; V1 assumes an IAP/VPN perimeter).
• Plain-HTTP transport between the data plane and Control Plane (native mTLS is on the roadmap; V1 assumes a service mesh or trusted network).
• The deterministic dev fleet credentials seeded by the docker-compose and Helm quick starts, which are documented as local-evaluation-only.
• Vulnerability reports generated by automated scanners without a demonstrated Pulse-specific impact.

If a finding makes one of these documented limitations worse than documented — for example, a way to reach the Control Plane from the data path that the perimeter model doesn't anticipate — that is firmly in scope.

• All three container images are scanned with Trivy in CI and again at release time; any CRITICAL CVE fails the build before an image is pushed.
• Third-party GitHub Actions with a history of tag tampering are pinned to full commit SHAs.
• Images are published to GitHub Container Registry under this repository's namespace, built only by the tag-triggered release workflow.

We support good-faith security research. If you make a genuine effort to comply with this policy — no privacy violations, no data destruction, no service disruption of systems you don't own, and no exploitation beyond what's needed to demonstrate the issue — we will not pursue legal action over your research and will work with you toward coordinated disclosure. Testing should be performed only against instances of Pulse that you deploy and control, never against another organization's deployment.