Security policy and coordinated vulnerability disclosure
Applies to: Throughline 3.0.0 · Last updated: 2026-09-22
Published because it is the right thing to do, and because Article 13 of the EU Cyber Resilience Act (Regulation 2024/2847) requires a manufacturer to operate a coordinated vulnerability disclosure policy. Its reporting obligations apply from 11 September 2026.
1 · Reporting a vulnerability
Security contact: [email protected] (post: PO Box 123, Flagstaff, AZ 86002, USA). Use it for anything security-relevant, however small.
Please include: the version from Help → About, your macOS version, what you did, what happened, and — if you have one — a proof of concept. If you want a reply encrypted, say so and we will exchange keys.
Please do not open a public issue for a security report, and please do not test against anyone else’s data.
2 · What you can expect
| stage | target |
|---|---|
| Acknowledgement | 3 working days |
| Initial assessment and severity | 10 working days |
| Fix or documented mitigation for critical issues | 30 days |
| Public advisory | with the fix, or sooner if already exploited |
We will credit you unless you would rather we did not. We will not pursue legal action over good-faith research conducted under this policy.
3 · In scope
- The Throughline macOS application and everything it bundles.
- The licence verification path.
- The update mechanism, if enabled.
- Anything that lets a malicious media file cause code execution, privilege escalation, or writes outside the intended directory. This is the most valuable class of report for this product: it parses untrusted video and audio from cameras, recorders and third parties all day.
4 · Out of scope
- Reports against upstream dependencies with no Throughline-specific impact — report those upstream; tell us so we can pull the fix in.
- Attacks needing physical access to an unlocked Mac, or an already-root attacker.
- The absence of a hardening measure with no demonstrated impact.
- Licence circumvention with no security consequence. That is a commercial matter, not a vulnerability.
5 · Security properties we intend to hold
Stated so that a violation is recognisable as a bug rather than a design choice:
- No silent network access. No telemetry. Every outbound connection is either requested by the user or listed in PRIVACY.md §3.
- The local AI provider refuses non-loopback endpoints. It cannot be configured into an exfiltration path.
- Minimum entitlements. Network client and user-selected files. No
disable-library-validation, noallow-dyld-environment-variables— both were removed in the 2026-07-05 audit and must not return. - Hardened runtime, signed and notarized, with library validation on.
- Untrusted input is treated as untrusted. Exporters sanitise text before it reaches EDL, XML and PDF output; the MCP surface is read-only for configuration and cannot invoke destructive operations.
- Source media is not modified during synchronisation.
6 · Update channel
Throughline 3.0.0 ships without an auto-updater. This is deliberate rather than unfinished: an update mechanism is a code-execution path, and one that cannot verify a signature is worse than none. The Sparkle framework is not bundled and no update feed is configured, so the application has no automatic channel through which code can reach your Mac.
Until an updater ships, security updates are distributed as a new signed and notarized build from the download page, announced by email to licence holders. The supported version is the latest 3.x release.
7 · Supply chain
- A CycloneDX SBOM is generated for every release: SBOM.json.
- The licence and provenance of every dependency is tracked in LICENSE-INVENTORY.md.
- Model downloads are pinned to an exact upstream revision and verified by
checksum. A placeholder revision fails the build — see
tests/test_compliance_posture.py. - Builds are signed with a Developer ID certificate and notarized by Apple.