Technical Vulnerability & Threat Management Policy¶
Purpose. Ensure vulnerabilities in Soon's product and infrastructure are found and fixed within defined timescales, and that relevant threat information is monitored and acted on. Absorbs threat intelligence requirements (A.5.7).
1. Scope¶
Soon's product code, dependencies, container images, and AWS infrastructure. Endpoint patching is covered by the Endpoint Protection Policy.
2. Policy¶
2.1 Identifying vulnerabilities¶
- Dependency scanning runs on product repositories via GitHub Dependabot — alerts and security updates verified enabled on all six SoonHQ repositories on 2026-09-08 — and via Aikido across the organisation. GitHub secret scanning, push protection and code scanning are not enabled: they require GitHub Code Security, which is not on the current plan. Compensating controls: secrets are injected from AWS Secrets Manager rather than committed, every release is approved by a second founder before production, and the annual penetration test covers the deployed application.
- Shared responsibility: AWS is responsible for vulnerabilities in the underlying cloud (hardware, hypervisor, managed-service patching); Soon is responsible for its own code, dependencies, images, and configuration.
- A penetration test of the SaaS product is performed at least annually. The current engagement is with GetAgency, included in the SOC 2 Type 1 bundle; the first test is scheduled for 21–23 September 2026 against production, as a greybox web-application test. Retesting is not included in that engagement.
- Security researchers can report vulnerabilities to Soon. The coordinated-disclosure contact is security@soon.works (see security@soon.works) and publish it.
2.2 Remediation SLAs¶
Vulnerabilities are triaged by severity (CVSS or scanner rating) and must be remediated within:
| Severity | Deadline |
|---|---|
| Critical | 7 days |
| High | 30 days |
| Medium | 90 days |
| Low | next regular release cycle |
These SLAs are confirmed by the owner (2026-08-13) and are the standard Soon is measured against. If a fix cannot meet the SLA, the security responsible must record a risk-based exception with a target date and report it at management review.
- Exploited-in-the-wild vulnerabilities in internet-facing components must be treated as critical regardless of score.
2.3 Threat intelligence¶
- Monitored sources: Dependabot and Aikido alerts (the primary route, since they match advisories against what Soon actually runs), AWS security bulletins, and vendor status and security notifications for the services in the stack. These reach all four founders by Slack and email; whoever sees a material item first raises it. Netlify is no longer in the stack — the front end is served by Cloudflare Pages.
- The security responsible reviews relevant advisories, assesses applicability to Soon's stack, and triggers patching (2.2) or a risk-register update where needed.
- Significant threats affecting customers are communicated per the Incident Response process.
3. Roles & responsibilities¶
- Security responsible: monitors sources, triages alerts, tracks SLAs, owns exceptions, arranges pentests.
- Engineers: remediate assigned vulnerabilities within SLA via the normal PR/CI process.
4. Related documents¶
- Secure Development Policy
- Endpoint Protection Policy
- Change Management Process
- Information Security Event Reporting Procedure
Change log¶
| Version | Date | Author | Comments |
|---|---|---|---|
| 0.1 | 2023-10-23 | Olaf Jacobson | First draft document |
| 0.2 | 2026-07-18 | Andrea Cardinali | Rewritten lean and Soon-specific (ISMS overhaul); absorbs threat intelligence (A.5.7) |
| 0.3 | 2026-10-16 | Olaf Jacobson | Policies matched to practice (owner decisions 2026-10-16): peer review described at release; material items reviewed at the quarterly security review. |