Threat Intelligence Procedure

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

1. Purpose

This procedure defines how Glassbreak consumes external threat-intelligence sources, the cadence at which those sources are reviewed, the criteria for converting an intelligence item into an internal incident, and where the resulting findings are recorded. It exists so that vulnerabilities, threats, and sub-processor incidents relevant to Glassbreak are noticed promptly and acted on consistently.

2. Scope

External threat-intelligence sources covering Glassbreak's technology stack, sub-processor services, hosting providers, dependencies, and operating context.
All workforce members responsible for monitoring or acting on those sources.
The findings produced by intelligence review, whether they result in an incident, a tracked improvement, or a no-action conclusion.

Internal detection sources (observability alerts, smoke tests, daily security-posture snapshot, DR scenarios, workforce reports) are handled under the Incident Response Policy §4 and are out of scope for this procedure.

3. Defined sources

The following are the standing sources Glassbreak reviews. The list is reviewed at least annually and may be extended at the Security Officer's discretion in response to changes in the technology stack or threat landscape.

3.1 Dependency vulnerability sources

Dependabot alerts on the Glassbreak GitHub repositories — covering direct and transitive dependencies in the web app, the API, the mobile app, and the disaster-recovery test harness.
Public CVE feeds for the languages and runtimes in use — covering the language toolchains, the HTTP framework, the database client, and the cryptographic library family.
Advisory feeds maintained by package ecosystems (npm advisory database, RustSec, GHSA).

3.2 Vendor and sub-processor advisories

Security and status advisories published by Glassbreak's compute, storage, edge, observability, and email/SMS sub-processors. The current sub-processor list is at /legal/sub-processors.
Incident-notification emails received from sub-processors under their security-notification obligations.
Vendor security bulletins for the developer tools, CI services, and operating systems in use on workforce endpoints.

3.3 Coordinated disclosure

Reports received through the published Coordinated Disclosure Policy at security@glassbreak.io.
Disclosures from peers, customers, or any party sharing intelligence relevant to Glassbreak — handled on the same triage path.

3.4 Sector and ecosystem watch

Notices from data-protection supervisory authorities relevant to the jurisdictions Glassbreak serves.
Publicly disclosed incidents at comparable services (credential-management, secure messaging, key escrow) — used as input to architectural and process review.

4. Cadence of review

4.1 Continuous

Dependabot alerts trigger a notification to the Security Officer on creation. Critical and high severity alerts are reviewed on the same business day.
Sub-processor incident notifications are read on receipt; those that may affect Glassbreak customers are routed to incident triage within 1 business day.
Coordinated-disclosure reports are acknowledged within 5 business days per the published policy and triaged accordingly.

4.2 Weekly

The Security Officer reviews the open Dependabot queue, including medium and low severity items, and triages each to: patch, accept-with-rationale, or defer-with-tracked-date.
Public CVE feeds for the languages, runtimes, and cryptographic libraries in use are reviewed for any item published in the previous 7 days that affects a component in use at Glassbreak.

4.3 Monthly

Vendor security bulletins from the developer-tool and OS vendors used on workforce endpoints are reviewed.
The list of source feeds (section 3) is checked against changes in the technology or sub-processor inventory; new feeds are added and obsolete feeds are retired.

4.4 Quarterly

The Security Officer prepares a quarterly threat summary covering: items received, items converted to incidents, items deferred and current deferral rationale, and any sector incident worth architectural attention. The summary is recorded in the threat-intelligence register.
The procedure itself is reviewed for whether the defined sources and cadence remain appropriate.

5. Criteria for raising an internal incident

An intelligence item is converted into an incident record under the Incident Response Policy when any of the following are true:

An exploited vulnerability is observed in the wild that affects a component in use at Glassbreak — irrespective of patch availability.
A vulnerability with no known active exploitation has a published proof-of-concept and affects a component on the network-exposed surface of production.
A sub-processor reports an incident that may affect Glassbreak customers or that may affect confidentiality, integrity, or availability of Glassbreak services.
A coordinated-disclosure report is substantiated after initial triage.
A signing-key, certificate-authority, or cryptographic-library compromise is reported that affects Glassbreak's trust chain.
A data-protection supervisory authority issues a notice that requires a Glassbreak response.
The Security Officer judges that the intelligence item warrants the rigour of incident handling.

Severity is assigned per IR policy §3 at the point of conversion. Severity may be re-classified as the picture clarifies.

6. Acting on intelligence

6.1 Items that do not become incidents

For each intelligence item that does not meet the conversion criteria in section 5, one of the following outcomes is recorded:

Patch. A pull request is raised against the affected component within the cadence appropriate to severity: critical and high within 7 days; medium within 30 days; low within the normal dependency-refresh cycle.
Accept-with-rationale. The item is accepted as a residual risk, with the rationale recorded in the risk register and a recorded expiry date for re-review.
Defer-with-tracked-date. The item is tracked with an explicit reconsideration date not later than the next quarterly review.
Not applicable. The item does not affect Glassbreak; the reasoning is recorded so that re-review is straightforward if conditions change.

6.2 Patching cadence

Critical and high severity dependency vulnerabilities in production-path code are expedited within 7 days of publication.
Medium severity dependency vulnerabilities in production-path code are addressed within 30 days of publication.
Low severity items are addressed within the normal dependency-refresh cycle.
Vulnerabilities in development-only dependencies (test frameworks, build tooling) are addressed at least within the normal refresh cycle unless they affect the integrity of the build itself.

6.3 Sub-processor incidents

On receipt of a sub-processor incident notice, the Security Officer assesses whether Glassbreak customers are affected and whether the notice requires customer notification under the DPA at /legal/dpa.
Where customer notification is required, the incident is handled under the IR policy and the notification SLAs in IR §7 apply.
The sub-processor's remediation is tracked until the sub-processor confirms closure; Glassbreak does not consider the matter closed until that confirmation is received.
Repeat or material sub-processor incidents are inputs to the next sub-processor reassessment under the Supplier Assessment Procedure.

7. Records

Every intelligence item reviewed is recorded in the threat-intelligence register with: date received, source, summary, affected component or process, outcome (incident / patch / accept / defer / N/A), and reference to the incident record, pull request, or risk-register entry it produced.
The quarterly threat summary is retained for at least 5 years.
Items that became incidents are cross-referenced into the incident register per the IR policy.
Items that became accepted risks are cross-referenced into the risk register.

8. Roles

Security Officer — owner of this procedure, primary reviewer of the defined sources, final decision-maker on incident conversion and accept-with-rationale outcomes.
Engineering — supports source monitoring for areas of code or infrastructure within scope of the engineering team, raises pull requests for triaged patches.

9. Review

This procedure is reviewed at least annually and after any incident attributable to a missed or late-handled intelligence item. The next scheduled review is 27 May 2027.

10. Related documents

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