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.