Supply Chain Risk Management Plan

Owner: Security Officer · Approved by leadership · Version 1.0 · Effective 27 May 2026 · Next review 27 May 2027

1. Purpose

This plan describes how Glassbreak identifies, evaluates, onboards, monitors, and (when necessary) replaces the third parties on which the platform depends. It covers both the operational sub-processors that handle customer data and the software supply chain that produces the running code. It is the controlled document referenced by ISO/IEC 27001:2022 Annex A.5.19–5.23 and A.5.21, by the SOC 2 vendor-management expectation (CC9.2), and by the NIST SP 800-53 SR family (Supply Chain Risk Management).

2. Scope

This plan applies to:

Operational sub-processors that process Glassbreak customer data on Glassbreak's behalf (compute, storage, email, payments, observability, etc.).
Software dependencies that are linked into the running application (npm packages on the API, the web app, and the mobile app; OS-level dependencies on container or runtime images).
CI/CD supply chain — source-control host, CI runners, third-party CI Actions, package registries, signing keys.
Infrastructure providers used to operate the platform that do not themselves process customer data (registrars, DNS providers).

It does not apply to customers' own downstream service providers; those are the customer's own supply chain scope.

3. Categories of supply-chain risk

Sub-processor compromise. A sub-processor is breached internally, by an external attacker, or through its own supply chain.
Sub-processor failure or sunset. A sub-processor becomes unavailable, withdraws a relevant service, or exits the market.
Sub-processor jurisdictional change. A sub-processor begins processing in a jurisdiction that breaches the declared sub-processor location or the customer DPA terms.
Malicious dependency. A npm package, OS library, or other dependency is updated to a version containing malicious code (typosquat, account compromise, intentional sabotage).
Vulnerable dependency. A dependency has a known security vulnerability that affects the platform.
Compromised CI runner or pipeline. The build or deployment pipeline is compromised, allowing insertion of malicious code into release artefacts.
Compromised maintainer account. A maintainer of a critical dependency or a Glassbreak contributor has their account taken over.
Compromised signing key. A signing key used in the supply chain (registry signing, build signing, OpenTofu apply signing) is exposed.

4. Sub-processor lifecycle

4.1 Intake

Identification. The need for a new sub-processor is identified by the relevant functional lead (engineering for technical infrastructure; finance for payment-related; the Security Officer for any sub-processor that processes Class CT, A, K, or L material per /policies/isms-scope section 6).
Initial assessment. Prospective sub-processors are assessed against:
- Current SOC 2 or ISO 27001 attestation (or credible equivalent).
- Privacy posture (DPA terms, sub-processor transparency, data-subject rights workflow, jurisdiction).
- Operational maturity (uptime history, incident communication, support SLAs).
- Concentration risk (does adding this sub-processor concentrate risk on one cloud provider, one region, one corporate parent).
- Switch-out cost (how hard is it to leave).
Decision. The Security Officer authorises onboarding for sub-processors that process customer data; the functional lead authorises onboarding for sub-processors that do not.
Pre-onboarding controls. Account is created with the Glassbreak organisational identifier; hardware-key 2FA enforced on every admin login; least privilege grants on every workforce account; sub-processor audit log access established where available.

4.2 Onboarding

Contract. A processing agreement incorporating the standard Glassbreak processor terms (or terms equivalent in substance) is signed before any customer data flows.
Sub-processor list update. The sub-processor is added to /legal/sub-processors with declared role, jurisdiction, and data categories; customer notice is given per the DPA (at least 30 days where the change is material) so customers can exercise their right to object.
Integration. Integration code is reviewed under the SDLC procedure; receiving boundaries verify webhook signatures; outbound credentials are held in the secret store with rotation procedure documented.
Recording. An entry is created in the sub-processor register including: contract date, contact points (commercial, security, support), incident notification SLA, retention schedule, and the rotation procedure for the credentials Glassbreak holds against the sub-processor.

4.3 Continuous monitoring

Annual re-attestation. Every sub-processor is re-assessed annually against the same criteria as intake; attestation currency is verified (SOC 2 report dated within 12 months; ISO 27001 certificate in date; equivalent).
Advisory monitoring. Public sub-processor advisories are monitored; significant advisories trigger ad-hoc review.
Operational monitoring. Sub-processor SLA breaches are recorded; persistent degradation is treated as a review trigger.
Sub-processor incident notification. A sub-processor incident is handled per the Incident Response Policy; customer notification follows the DPA.
Annual access review. Workforce access to sub-processor admin consoles is reviewed at the annual cycle and at every departure per /policies/offboarding.

4.4 Change and replacement

Material change.A material change in the sub-processor (acquisition, jurisdictional change, sub-processor change at the sub-processor's own level) is recorded and customer notice given per the DPA.
Replacement triggers. Glassbreak will replace a sub-processor when any of the following is true:
- The sub-processor's attestation lapses and is not renewed within a reasonable window.
- The sub-processor suffers an incident of a severity that materially undermines confidence in its operating effectiveness.
- The sub-processor changes its commercial terms in a way that breaches Glassbreak's commitments to customers (data-export rules, audit rights, sub-processor transparency).
- The sub-processor processes in a jurisdiction that breaches the declared sub-processor location or customer DPA terms.
- A clearly better alternative emerges on a material dimension (price, security posture, jurisdictional alignment, resilience) and switching cost is justified.
Replacement procedure.The replacement sub-processor is onboarded per the intake procedure; data is migrated under documented procedure (or, where permissible, simply replicated through Glassbreak's own dual-vertical model); the outgoing sub-processor is notified, the contract terminated, and remaining credentials revoked; the sub-processor list is updated and customer notice given.

5. Software supply chain

5.1 Dependency policy

All workspaces use lockfiles (package-lock.json for npm; equivalent for other ecosystems). Lockfile changes are reviewed.
New dependencies are reviewed for:
- Licence compatibility with Glassbreak's commercial use.
- Maintainership health (active maintainer, release cadence, response to security reports).
- Supply-chain hygiene (signed releases where available, provenance attestations where available, no known credential leaks in history).
- Necessity (is this dependency adding value commensurate with the supply-chain surface area it adds).
Preference is given to dependencies that are widely used, actively maintained, and accept signed-release practices.
Cryptographic operations use the Noble libraries; the Wycheproof vector corpus is vendored and runs in CI to detect any regression introduced by a dependency update.

5.2 Vulnerability management

Dependabot runs on every repository.
CVE feeds are monitored.
Critical-severity advisories trigger a SEV-2 incident per the IR policy; high-severity advisories follow the standard vulnerability-management cadence; lower severity is batched.
The IR procedure includes specific guidance on sub-processor-originated advisories.

5.3 SBOM

An SBOM (Software Bill of Materials) is on the Q3 2026 plan (RTP R-06). The SBOM will be generated per release in CycloneDX format and published per release.
Customer SBOM requests prior to publication availability can be served on request to compliance@glassbreak.io.

5.4 Cryptographic-material integrity

Production secrets (signing keys, HMAC keys, peppers) are generated using the documented secret-generation runbook with attested randomness from approved sources.
Secret material is held in approved secret stores only.
Rotation runbooks per secret class are held under docs/; cross-vertical sync HMAC keys rotate on a documented schedule per docs/operator-jwt-per-vertical.md.

6. CI/CD supply chain

6.1 Source control

GitHub is the source-of-truth; branch protection on main blocks direct pushes; PRs require review before merge.
Admin accounts require hardware-key 2FA; organisation-owner accounts require approval for membership changes.
Signed commits are preferred where the contributor supports them.

6.2 CI runners

Production deploys run only from GitHub-hosted runners on approved workflows; self-hosted runners are not used on the production deployment path.
Workflows are reviewed in PR; modifications to workflow files are themselves PR-reviewed.
Third-party Actions are pinned to commit hashes (not tags) for any Action that operates on secret material or release artefacts. Pinning is on the Q4 2026 plan (RTP R-06) for the remaining Actions.
Workflow tokens are scoped to the minimum permissions required by the workflow.

6.3 Deployment

Production deploys are CI-only; manual production installs are prohibited.
OpenTofu apply runs via CI against approved plans only; OpenTofu state is held encrypted in the approved state backend.
Release artefacts are built reproducibly from source; the release pipeline is the only principal authorised to push to production.

6.4 Account hygiene

All workforce accounts on the CI/CD path require hardware-key 2FA.
Departing workforce members' CI access is revoked on the last working day per /policies/offboarding §5; rotated credentials are listed in the credential-rotation checklist.
Sub-processor accounts integrated with CI (registry credentials, deploy credentials) are rotated on departure as part of the same checklist.

7. Concentration risk

The two-stack architecture is designed to avoid concentration of compute and storage risk on a single cloud provider.
Registrar diversity (Porkbun + Gandi + DNSimple across three production domains; future fourth registrar for glassbreak.dev) limits registrar concentration risk.
DNS authority diversity (dual DNS authority on every domain) limits DNS concentration risk.
Sub-processor concentration is reviewed at the annual re-attestation: where two unrelated services have come to depend on the same underlying corporate parent or the same region, the alternative is identified and the switch-out cost recorded.

8. Replacement criteria — summary

A sub-processor will be replaced when any of the following triggers is met:

Lapsed or downgraded security attestation that is not rectified within a reasonable window.
A confirmed incident at the sub-processor that materially affects Glassbreak customers and is not remediated to Glassbreak's satisfaction.
Commercial-term change that breaches Glassbreak customer commitments.
Jurisdictional change that breaches the declared location or DPA terms.
Persistent SLA breach that meets the threshold for operational review.
Strategic substitution where a materially better alternative is identified and switching cost is justified.

9. Roles

Security Officer. Owns this plan; authorises sub-processor intake for customer-data processors; runs the annual re-attestation cycle.
Engineering. Owns the software and CI/CD supply chain; implements SBOM, Action pinning, and dependency hygiene; integrates new sub-processors per the SDLC procedure.
Functional leads. Identify the need for new sub-processors in their function; participate in onboarding and review.

10. Records

Sub-processor register held under version control.
Sub-processor attestation evidence held in the document repository; current as of the latest re-attestation date.
Customer-facing sub-processor list at /legal/sub-processors.
Records of intake, re-attestation, and replacement decisions retained for at least 5 years.

11. Review

This plan is reviewed at least annually and after any material change to the sub-processor mix, the architecture, or the regulatory environment. The next scheduled review is 27 May 2027.

12. Related documents

Counter-signed PDF copy available on request to compliance@glassbreak.io.