Incident Response
=================

This section describes how the Shyft project responds to security-relevant
incidents affecting identities, keys, and release integrity.

The response model reflects the upstream–downstream trust separation:

- Shyft upstream is responsible for containment, revocation, and communication
- downstream users are responsible for evaluating impact and taking appropriate
  action within their own environments


Scope of incidents
------------------

Relevant incidents include, but are not limited to:

- loss or theft of hardware-backed key devices (e.g., Nitrokey)
- suspected compromise of key-generation or signing environments
- suspected exposure of encrypted key backups
- mistaken or unauthorized signing of commits, tags, or artifacts
- unauthorized repository access or privilege escalation
- compromise of developer or maintainer accounts


Immediate response actions
--------------------------

When an incident is suspected or confirmed, the following actions must be
taken without unnecessary delay:

1. Contain access

   - Remove or suspend affected accounts from the GitLab project
   - Revoke SSH access where applicable
   - Disable or restrict affected credentials

   Owners and Maintainers have the authority to perform these actions.

2. Preserve audit information

   - Do not delete repository history or logs
   - Record relevant timestamps, identities, and actions
   - Ensure that evidence needed for later review is retained

3. Assess scope

   - Identify which keys, accounts, or systems are affected
   - Determine whether signing keys or release processes are impacted
   - Identify potentially affected commits, tags, or artifacts

4. Revoke trust where required

   - Revoke affected GPG keys where applicable
   - Update documentation or key distribution channels if trust anchors change
   - Prevent further use of compromised credentials


Impact assessment
-----------------

For incidents affecting signing trust or repository integrity, the project
must assess and document:

- what was affected
- which keys or accounts were involved
- whether revocation was required
- whether release artifacts or repository history may be impacted

If release-signing keys are affected, this must be treated as a high-severity
incident.


Communication
-------------

Relevant stakeholders must be informed in a timely and transparent manner.

This may include:

- project maintainers and contributors
- downstream users and organizations
- public communication channels where appropriate

Communication should include:

- a description of the incident (to the extent possible)
- affected components (keys, accounts, releases)
- required actions for downstream users (e.g., re-verification, rebuild)


Recovery and follow-up
----------------------

After containment and initial response:

- establish new trusted keys or environments if required
- restore secure access for affected users where appropriate
- review and improve procedures to prevent recurrence

Where applicable, a post-incident review should be documented, including:

- root cause analysis
- effectiveness of the response
- identified improvements


Relationship to downstream environments
----------------------------------------

Due to the upstream–downstream trust separation:

- Shyft does not assume control over downstream deployments or artifacts
- downstream users are responsible for evaluating the impact of incidents
  within their own environments

This includes decisions such as:

- whether to rebuild from trusted source
- whether to revoke or replace deployed artifacts
- whether to apply additional internal controls

Shyft provides:

- transparent incident information
- verifiable repository state
- updated trust anchors where applicable

This enables downstream systems to independently re-establish trust
according to their own requirements.