Vulnerabilities are inevitable in any non-trivial system; managing them well is what matters. This policy sets out how Code Cutter Limited (trading as Mailbuttons) finds, prioritises and fixes security weaknesses, and how it receives reports from others.

# Purpose and scope

This policy covers the identification, assessment, remediation and disclosure handling of technical vulnerabilities across Mailbuttons software, dependencies, runtimes and operating systems. It supports ISO/IEC 27001:2022 Annex A 8.8 (management of technical vulnerabilities) and relates to 8.28 (secure coding) and 5.7 (threat intelligence).

# Policy

Monitoring for vulnerabilities. We monitor security advisories and dependency alerts relevant to our stack — the Rust toolchain and crates, Node and frontend packages, PostgreSQL, the operating system, and components such as Stalwart and Kanidm. We aspire to automated dependency scanning as tooling matures and supplement it today with manual review of advisories.

Risk-based patch cadence. Vulnerabilities are assessed for severity and exploitability in our context, then remediated within target windows:

• Critical — patched promptly, target within 72 hours of a fix being available, or faster if under active exploitation; mitigations applied immediately where a patch is not yet available.
• High — within 7 days.
• Medium — within 30 days.
• Low — within 90 days, or bundled into routine maintenance.

These are targets; the ISMS Owner may accelerate them based on exposure or risk-accept with documented justification.

Scope of patching. Patching covers operating systems and the VPS host, language runtimes (Rust, Node, the sandboxed CPython), application dependencies, and supporting infrastructure components. Updates follow the Change Management Policy and are deployed through the controlled make deploy process.

Hardening. Beyond patching, we reduce attack surface by design. Examples include the always-on SSRF guard and the network-isolated WASI/wasmtime sandbox (no socket or filesystem access, with fuel, epoch and memory limits) in which customer agent code runs. Hardening is treated as a continuous activity, not a one-off.

Independent testing. A first annual third-party penetration test is scheduled to coincide with the ISO 27001 audit kickoff, triggered on our first paid Business contract, and will recur annually thereafter. Findings feed into the remediation tracking below.

Vulnerability disclosure. We welcome reports from security researchers and users. Reports should be sent to [email protected]. We acknowledge receipt within two UK business days. We do not operate a paid bug bounty, but we credit reporters who responsibly disclose valid issues, with their consent. We will not pursue legal action against good-faith research conducted under this policy.

Tracking to remediation. Every vulnerability — whether found internally, by a dependency alert, by the penetration test or via disclosure — is recorded, assigned a severity, and tracked through to remediation or documented risk acceptance. Fixes are verified before a finding is closed, and patterns are fed back into secure development practice.

# Responsibilities

The ISMS Owner is accountable for this policy: for monitoring advisories, triaging and prioritising vulnerabilities, applying patches within the target windows, commissioning the annual penetration test, and operating the disclosure intake. As a micro-team we rely on tooling and disciplined triage rather than a dedicated security team.

# Review

This policy is reviewed at least annually and after any material change, and is approved by the ISMS Owner.

Related: Secure Development Policy, Change Management Policy, Logging and Monitoring Policy, Incident Response Policy