01Purpose
This procedure describes how vulnerabilities and threats affecting the Synthesis platform are identified, prioritised, remediated and verified. It covers our own code, the third-party dependencies we ship, and the runtime the platform executes on.
02Dependency vulnerabilities
The application repository runs automated dependency scanning. New advisories affecting a dependency we ship raise a pull request against the repository, and security advisories are prioritised over routine version updates.
The platform runs on Google Cloud Run. The underlying operating system and container runtime are patched by the platform provider, so we do not operate unpatched long-lived servers.
03Defects in our own code
Every proposed change runs the full automated test suite before it can be merged, and a failing suite blocks the merge. The suite includes checks written specifically to catch security-relevant regressions rather than functional ones alone:
- Authentication boundary. Every route that answers without a credential must be explicitly listed and justified. A route that becomes reachable without authentication and is not on that list fails the build.
- Tenant isolation. Access to a merchant's data is checked per request against the requesting user's organisation, and that behaviour is asserted in tests.
- Data integrity. Scheduled checks assert that warehouse tables hold the grain and freshness they claim, so silent corruption surfaces as a failure rather than as a wrong answer.
04Runtime monitoring
Application errors are captured in a monitoring service configured with personal-data reporting disabled and variable capture switched off, so that diagnostics cannot themselves become a disclosure. Scheduled jobs are monitored, and a job that stops running raises an alert rather than failing silently.
05Secrets
Production secrets are held in Google Secret Manager and are never committed to source control. Credentials are rotated when a platform requires it, when personnel with access change, and immediately on any suspected exposure.
06Severity and remediation targets
| Severity | Definition and target |
|---|---|
| Critical | Remote exploitation, authentication bypass, or exposure of Restricted or Confidential data. Mitigated immediately; fix within 7 days. |
| High | Privilege escalation or cross-tenant access requiring specific conditions. Fix within 30 days. |
| Medium | Limited impact, or exploitable only with existing authenticated access. Fix within 90 days. |
| Low | Hardening and defence-in-depth. Scheduled into routine work. |
A vulnerability that is being actively exploited is handled under the Security Incident Response Policy rather than under these targets.
07Reporting a vulnerability
We welcome reports from researchers, customers and platform partners. Please include the affected URL or endpoint, the steps to reproduce, and the impact you were able to demonstrate. We will acknowledge a report within one business day.
Please do not access, modify or retain data belonging to another user while testing.
08Review
This procedure is reviewed at least annually and after any incident that reveals a gap in it.