Purpose
This plan defines how Oxide declares and classifies security incidents, including ways they may be detected, how they are to be triaged, investigated, and learned from. It includes requirements and responsibilities for reporting and handling security incidents. It exists to protect:
The integrity of Oxide products and systems that produce them. Oxide ships hardware and software that customers run as the foundation of their infrastructure. A compromise of the sources, build and release pipeline, signing infrastructure, or the manufacturing process is the most consequential type of incident.
Customer trust and their data in Oxide’s custody. Protected by responding to vulnerabilities in shipped products and safeguarding any customer data that Oxide holds.
Oxide’s data and operations.
This plan supports Oxide’s security objectives for SOC for Supply and SOC 2. It may be amended in the future to include other objectives, such as ISO 27001.
Scope and Boundaries
This plan covers security incidents that affect any software or hardware that Oxide produces and distributes to customers, and the systems that build, sign, and distribute them. It includes the Oxide Cloud Computer and ecosystem software such as Terraform Providers and other integration solutions. This scope is deliberately more broad than current product security audit objectives (e.g. SOC for Supply Chain, SOC 2, etc.).
SOC for Supply Chain boundary
The systems in scope for SOC for Supply Chain are the people, processes, and infrastructure that produce and distribute the Oxide Cloud Computer, including:
Source code and review infrastructure: the Oxide GitHub enterprise account and the organization(s) it contains, including repositories, branch protection, code review, and any enterprise-level policies or rulesets governing them, as well as the self-hosted Gerrit Code Review system used for Oxide’s illumos work.
Build and release infrastructure: Continuous Integration systems (buildomat, GitHub Actions, including self-hosted runners and the infrastructure they run on), release tooling, artifact storage and distribution.
Signing and trust infrastructure: keys and processes used to sign firmware and software (e.g. RoT trust roots, Hubris firmware signing, (planned) TUF repository signing), and manufacturing keys used to certify genuine Oxide platform identities.
Manufacturing and hardware integration: contract manufacturing, component sourcing, and rack integration, to the extent that a security event in those could affect product integrity.
Update delivery: the mechanisms that customers receive and validate system updates.
Corporate systems involved with systems listed above: employee endpoints, Google Workspace identities used for Single Sign-on, GitHub accounts and credentials.
SOC 2 boundary
For SOC 2 purposes, the systems in scope of this plan include those that are mentioned in the SOC 2 system description. In general, this is the corporate infrastructure that supports Oxide’s commitments to customers regarding the safety of their data in Oxide custody. Incidents purely within this boundary will typically classify at SEV-1 or below.
Notes
Security incidents in customer environments are out of scope for this plan. Oxide does not operate customer environments, and while customer may reach out to Oxide support to assist with security incidents in their environments involving Oxide products, those will be handled as support cases and not an Oxide security incident. This plan may come into effect if an event reported by the customer gives evidence of a product vulnerability being exploited, a compromised artifact (e.g. software update), or exposure of customer data. In that case, Oxide will trigger a security incident response in parallel to the customer support case.
Disclosure of product vulnerabilities is its own process outlined in Vulnerability Disclosure Program. Undisclosed product vulnerabilities that are being actively exploited are in scope for this plan.
Security incidents involving corporate infrastructure that have no plausible path to production systems (e.g. Oxide private financial data is externally exposed) are handled under this plan but will typically classify with lower severity.
Definitions
Security event: An observation that is potentially security relevant, such as an alert, an anomaly, an external report, etc. Most events are not security incidents.
Security incident: An event that is triaged and determined to be, or reasonably suspected may be, unauthorized access, use, modification, disclosure, or destruction of Oxide systems, code, signing material, or data, or a credible compromise of product integrity. While all Oxide employees are responsible for reporting security events that they suspect are likely to result in being declared a security incident, the declaration of security incident is done by the security function, and not any reporter’s assessment.
Supply chain incident: A security incident that affects the integrity of Oxide products: source, build, signing, artifacts, manufacturing, or update delivery. It includes events from third-parties, such as a malicious or compromised vendor, even when Oxide infrastructure was not breached.
Roles and Responsibilities
| Role | Responsibility | Default assignment |
|---|---|---|
Incident Manager (IM) | Owns the incident end-to-end: declares severity, coordinates responders, makes containment decisions, owns the timeline, decides when the incident is closed. The IM does not have to be the most senior person present, and is empowered to make containment decisions without prior executive approval. | First security-engineering responder. Can be reassigned by mutual agreement. |
Subject Matter Responders | Individuals actively working on investigation and remediation. | Pulled in by IM as needed. |
Communications Lead | Owns external communications: customers, researchers, public advisories. | Incident Manager |
Executive Management | Briefed on all SEV-0 and SEV-1 incidents. Makes business-level calls, such as customer notification timings, legal engagement, public disclosure of supply chain compromise. | CTO |
Legal Counsel | Engaged for incidents involving customer data, contractual notification duties, law enforcement, or insurance claims. Counsel should be engaged early for SEV-0 and SEV-1 incidents. |
All Oxide employees are responsible for reporting suspected security events promptly. Employees will not face adverse consequences for good-faith reports, including mistakes made by the reporter, such as accidentally pasting an access token publicly online.
Severity Classification
Severity is assigned at the time a security incident is declared by the IM and may be revised through the course of the response. Classification focuses on product and supply-chain integrity first, then customer impact, the corporate systems impact. Availability of internal systems is deliberately minor.
| Severity | Definition | Examples | Response engagement |
|---|---|---|---|
SEV-0 | Confirmed or strongly suspected compromise of product integrity or the infrastructure used to produce it. | RoT code signing key or Platform ID key compromise; malicious code merged in product repos or otherwise present in a release; compromised release artifact; build and release pipeline compromise with attacker-controlled access to credentials and online signing service; evidence of tampering of manufacturing station systems. | All-hands-on-deck. IM + executive management + legal counsel immediately. Ship and release freeze. Determine whether to notify cyber insurance carrier within policy limits. |
SEV-1 | Confirmed compromise of systems adjacent to the supply chain, or confirmed exposure of customer data, without (yet) evidence of product impact. | Compromised engineer GitHub account or endpoint with push or release access; compromised self-hosted build runners (buildomat, GitHub Actions) without confirmed lateral movement; actively exploited vulnerability in a shipped product; exposure of customer support data. | IM + responders immediately. Executive management within hours. |
SEV-2 | Contained or limited compromise of corporate systems; credible vulnerability reports requiring coordinated response; software dependency compromise with no evidence of Oxide having consumed or executing malicious versions. | Malware discovered on a non-engineering endpoint, where impact was contained by credential rotation; OAuth token theft with limited scope; Dependabot alerts flagging malicious packages. | IM + relevant responders during business hours. |
SEV-3 | Security events that require tracking but not coordinated response. | Active sophisticated phishing campaign targeting multiple employees; scanning activity. | Logged, handled by individual responder. |
Reporting
Reporting channel
Any employee who suspects a security event should report it immediately to security@oxidecomputer.com and mention that a report was sent in the #oxide-security Matrix channel. The reporter may share details of the event in the #oxide-security channel, but should use their personal judgment as to whether those details should be visible to all of Oxide internally by posting in that channel.
If the suspected compromise involves the security@oxidecomputer.com channel itself, (e.g. Google Workspace) then reporters are to fall back to using Out-of-band Contacts.
External vulnerability reports
Reports to security@oxidecomputer.com from external parties are triaged under the Vulnerability Disclosure Program. They enter this incident response plan only when triage indicates active exploitation or indication of compromise. Otherwise, those reports follow the vulnerability disclosure processes outlined in the RFD.
Response Lifecycle
Each security incident follows the same lifecycle. The parts listed below do not need to be conducted in sequential order, though none should be skipped.
Declare
Upon observing a security event or receiving a report of one, the security function triages it and either determines it to be a non-incident or declares an incident. Upon declaring an incident, a severity and the IM role are assigned, an incident folder is created in the Security Incidents shared drive, and an incident record is created, where a timeline is started.
Contain
Containment intends to limit the impact of the incident (e.g. attacker capabilities) while still preserving evidence that can help determine the full impact of the incident. This may include:
Suspending user accounts or their access (GitHub, Google Workspace, etc.)
Revoking credentials (e.g. Oxide Silo access tokens)
Taking services offline (e.g. online signing service)
Investigate
Establish with evidence initial access vector(s), scope of access (e.g. accounts, machines, repos, secrets, etc.), actions performed (if any), and any persistence mechanisms.
For incidents where supply chain is involved, an integrity verification sweep is to be performed.
Recover
Restore normal operation, and potentially monitor the affected systems with extra sensitivity.
Close and review
The IM closes the incident when eradication and recovery are confirmed. Each SEV-0 and SEV-1, and SEV-2 incidents at IM discretion, gets a blameless post-incident review that includes a written narrative and timeline of what happened, the root cause, what, if detections caught or missed events, any response friction that could be improved, and corrective actions taken. This review is a separate document from the incident record document that is intended to be more broadly shareable within Oxide. It should not contain sensitive specifics about the incident, as those are intended for the incident record only. The post-incident review is retained for audit evidence.
Incident Records and Tooling
System of record
Security incidents are recorded in the "Security Incidents" Google Drive shared drive. Each incident gets a folder containing an incident record Google Doc and any evidence. Membership for the drive is granted to the Google group behind security@oxidecomputer.com (and explicitly via a group for Google Workspace admins, who have access to it via their admin accounts otherwise), the same group that receives security event reports. Per-incident participants who are not group members (e.g. legal counsel, subject matter responders) are granted access to the folder made for the incident only. Sharing settings for the drive are deliberately hardened: people outside Oxide are not permitted, people who aren’t drive members do not have access (no shared link).
In the event a SEV-0 or SEV-1 investigation plausibly implicates a group member, then its records are kept out of the shared drive until that is resolved. Responders are to use Out-of-band Contacts for establishing a temporary alternative location for storing records.
Corrective actions
GitHub issues are preferred for managing and tracking corrective action items, where they can be assigned to others in the Oxide organization. They do not need to be in any particular repository, and the repository visibility should be considered before sensitive information that could compound the incident is exposed. Alternatively, the IM may choose to use task items in the incident Google Doc instead, where the IM is responsible for management and tracking of them. Management and tracking of these is required for closing an incident.
Privileged track
For SEV-0 and SEV-1 incidents with plausible legal exposure, the counsel may choose to establish a counsel-controlled storage option other than the shared drive. In such an event, a post-incident review is still required for incident folder in the shared drive.
Identifiers
Every security incident is to get an identifier of the format SEC-YYYY-NNN (e.g.
SEC-2026-001) where YYYY is the current year of the incident and NNN is
the next number in sequence from other incidents declared that year. Incident
folder names in the Security Incidents shared drive are the identifier with a
short description of what happened (e.g. SEC-2026-001 - admin token exposed in
internal repo).
Record contents
Security incident records should include severity, rationale, response team members and roles, a timeline, an index of evidence, decisions made in the course of the response, communications log. The incident folder should also contain a post-incident review that may be broadly shared within Oxide.
Template
Templates for incident records and post incident review are available in the Security Incidents shared drive.
Communication and Notification
All external communications go through the Communications Lead. Internally, incident details for SEV-0 and SEV-1 are shared on a need-to-know basis in order to contain potential overexposure of vulnerability details, and may be open more broadly at lower severities at IM discretion.
The table below lists the potential external audiences that Oxide may owe communications to in the course of an incident. It defines what triggers the obligation, timing expectations, and who owns delivery.
| Audience | Trigger | Timing | Owner |
|---|---|---|---|
Customers | Any incident affecting the integrity, security, or supportability of their racks or data in Oxide possession; any artifact they may have received during a compromised window; actively exploited vulnerabilities in the wild. | Per contractual commitments. | Comms Lead + customer support team |
Cyber insurance carrier | Any SEV-0/SEV-1, and any incident plausibly giving rise to a claim or legal exposure. Late notices can jeopardize insurance coverage. | Per policy terms; evaluated with legal counsel within 24 hours for SEV-0/SEV-1 declaration. | Counsel + CFO |
Security researchers | Reports via coordinated disclosure | Acknowledgment and ongoing communication per the published disclosure policy. | Engineering / Comms Lead |
Public advisory | Vulnerabilities in shipped products after remediation; supply chain incidents where transparency helps to serve customers. | After customer notification and remediation, timed with counsel. | Comms Lead + Exec Management |
Statutory breach notification (affected individuals + state regulators) | Breach of unencrypted personal information of state residents. | Counsel determines applicable states per incident. | Counsel + Comms Lead |
Law enforcement | At executive + counsel discretion (e.g. FBI for intrusions and supply chain attacks); legally mandates | As required. | Counsel |
Upstream / ecosystem | When Oxide’s incident implicates an upstream project (e.g. Oxide discovers a malicious third-party Rust crate). | Promptly, via upstream published security contact. | Engineering |
Training
All employees are to receive training on incident reporting expectations detailed in this plan at initial onboarding.
Out-of-band Contacts
In the event primary communication channels are unavailable or should be avoided for reasons mentioned in this plan, reporters are to establish an alternative channel with an individual holding one of the roles listed below, in order of the list:
Security Engineer
Director of Operations
CTO
Current information including who holds these roles and their contact information can be found in the company directory at company directory.
External References
[rfd-661] Oxide Computer Co. RFD 661: Vulnerability Disclosure Program.
[sp-800-63] National Institute of Standards and Technology (NIST). SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile
[directory] Google Contacts (Oxide company directory). https://contacts.google.com/directory