DRAFT, pending counsel review. This document is an internal draft prepared on 2026-04-26 by the engineering team. It has NOT been reviewed by external legal counsel. Do not rely on it for legal advice. Effective date is a placeholder pending sign-off. Apostle Pty Ltd makes no representation that this draft satisfies any specific jurisdictional requirement until counsel-reviewed.

Vulnerability Disclosure Policy

Last revised: 2026-04-26 · Version: 0.1.0-draft

1. Our commitment

PYLON, operated by Apostle Pty Ltd, welcomes good-faith security research on our public surfaces. We commit to:

• triage every report we receive;
• communicate with the reporter through to resolution;
• credit the reporter (if requested) once a fix has shipped;
• not pursue legal action against researchers acting in good faith within the scope and rules below.

We do not currently operate a paid bug bounty program. We may add recognition or monetary rewards in the future; the present policy is recognition-and-credit.

2. Scope

In scope:

• pylon.video
• app.pylon.video
• admin.pylon.video
• api.pylon.video
• drm.pylon.video
• The PYLON iOS application
• The PYLON Android application

Out of scope:

• Third-party services we depend on, Stripe, Mux, Resend, SignatureAPI, PostHog, Sentry, Cloudflare. Report findings against those vendors directly to the vendors. We are happy to forward, but we have no authority over their pipelines.
• Social-engineering of PYLON staff, contractors, or users.
• Physical security of our premises or equipment.
• Denial-of-service, distributed denial-of-service, traffic-flooding, or any test that degrades service for other users.
• Any test that exfiltrates user data beyond what is strictly necessary to demonstrate the vulnerability.
• Testing of email deliverability against our SPF / DKIM / DMARC setup that involves spoofed messages to real users.
• Findings from automated scanners with no manual verification.

If your finding sits on the boundary of scope, send it; we'll either accept it or explain why we won't action it.

3. Reporting channel

Email: [email protected]

PGP encryption is available; the public key is at /.well-known/pgp-key.txt (TBD, placeholder pending key rollout).

Please include:

• a description of the vulnerability;
• the affected URL, endpoint, or app version;
• reproduction steps that we can replicate;
• the impact (what an attacker can do);
• the payload or proof-of-concept;
• your preferred name (or anonymous) for the credit page.

4. Safe harbour

If you make a good-faith effort to comply with this policy during your security research, we will:

• consider your research authorised under the Computer Misuse Act, Crimes Act (Cth) or analogous statutes;
• not pursue civil action against you;
• not refer you to law enforcement;
• not request that the underlying registrar, hosting provider or account provider take action against you;
• work with you to understand and resolve the issue quickly.

This safe harbour is not absolute. It does not cover:

• testing on systems you do not have permission to test (anything outside the scope in §2);
• accessing or modifying data of users other than your own test accounts (or, where unavoidable, the smallest amount of data required to demonstrate the issue);
• public disclosure of the vulnerability before a fix has shipped;
• destructive testing.

If you are unsure whether a specific test is in scope, ask first at [email protected].

5. Researcher expectations

In return for the safe harbour above, we ask that you:

• do not access user data beyond what is required to demonstrate the finding;
• do not modify or delete data;
• do not move laterally to in-scope-but-tangential systems (e.g. our internal Jira if you happen to find a foothold);
• do not test against staff accounts, use accounts you create for the test;
• do not run distributed denial-of-service or traffic-flooding tests;
• do not submit findings whose only impact is "this header is missing" without a meaningful security impact;
• give us a reasonable window, see §7, to ship a fix before publishing.

6. What you can expect from us

When you report a vulnerability we will:

• acknowledge receipt within 24 hours for in-scope reports;
• assign a severity tier (critical / high / medium / low);
• provide an initial triage update within the SLA in §7;
• communicate the path to fix, including any partial mitigations and the full-fix timeline;
• credit you on a public security acknowledgements page (TBD, /security/acknowledgements) once the fix has shipped, if you consent to being named.

7. Triage SLAs

Severity tiers and the response SLA we commit to:

Target-fix SLAs are aspirational; actual fix time depends on the nature of the bug and the surface affected. We will tell you if we expect to miss a target.

8. Out-of-scope finding categories

The following are out of scope unless they have a demonstrable security impact:

• Reports from automated scanners with no manual verification.
• Self-XSS that requires the victim to paste attacker-supplied input into devtools.
• Missing rate limit on idempotent reads with no business-logic consequence.
• HTTP host header injection with no upstream impact.
• TLS configuration findings on third-party endpoints.
• Reports of "world's first" finding when the issue is documented in our existing security backlog.
• Username enumeration on a sign-in form where the application intentionally shows the same response for valid and invalid emails (we do; we just acknowledge that we do).

We may close such reports without further engagement.

9. Coordinated disclosure

We follow a 90-day coordinated disclosure model unless the finding is being actively exploited, in which case we work with the researcher on a faster timeline.

We support researchers who wish to publish their findings after a fix has shipped, and we will work with you on the disclosure timing if you intend to publish.

10. Limitations

This policy applies to security vulnerabilities. It does not apply to:

• privacy or data-handling disagreements (route to [email protected]);
• abuse of service or moderation matters (route to [email protected]);
• copyright disputes (route to [email protected]);
• contractual disputes.

Related

• Terms of Service
• Privacy Policy
• Data Processing Addendum

Contact

• Reports: [email protected]
• PGP key: /.well-known/pgp-key.txt (TBD)
• Acknowledgements: /security/acknowledgements (TBD)

Version history