GitHub

Create a repository mirror

Outcome: Preserve repository files and revision history in an approved external backup location.

Method: Follow GitHub's documented mirror-clone approach in an approved backup location and fetch Git LFS objects separately when the repository uses LFS.

Limitations: A Git mirror does not include issues, pull-request discussions, packages, external secrets, or every repository setting. Storage and access controls remain the owner's responsibility.

1. Identify the repository and approved external backup location.
2. Create the documented mirror clone in that location.
3. When Git LFS is used, fetch the required LFS objects separately.
4. Record the backup date, owner, and known coverage limits without copying repository credentials into SIU.

Verification or retest: List important refs in the mirror or restore it into a disposable private location, then repeat on the approved backup cadence.

Completion evidence: A dated repository mirror stored in an approved location outside GitHub.

GitHub Docs: backing up a repository ↗

Safety: Do not send repository contents, credentials, or backup locations to SIU.

Account for local-only work

Outcome: Identify uncommitted changes, untracked files, and local-only branches that a remote backup will not contain.

Method: Use the team's approved development process to review working-tree changes, untracked files, and local-only branches before relying on a remote backup.

Limitations: This is reviewed SIU operational guidance, not a GitHub-prescribed backup procedure. Handling unfinished or sensitive work must follow the team's policy.

1. Review uncommitted changes and untracked files using the team's approved tools.
2. Identify branches that have not been pushed to an approved remote.
3. Commit, stash, or make an approved protected copy according to team policy.
4. Record only that the review occurred; do not enter code, branch names, or secrets into SIU.

Verification or retest: Confirm the chosen approved location contains the intended work or that the working-tree state is understood, then repeat before a planned device change or recovery exercise.

Completion evidence: A clean working tree or a documented approved backup of local-only work.

Safety: Follow the team's approved handling policy for unfinished and sensitive work.

Document an access route

Outcome: Record ownership, administration, and protected recovery-information responsibilities.

Method: Maintain a protected ownership and access checklist that points authorized people to approved recovery-information locations without storing the information itself in SIU.

Limitations: This is reviewed SIU operational guidance, not a GitHub-prescribed account-recovery workflow. Organization ownership and credential policies govern the actual process.

1. Record repository owners and administrators in protected team documentation.
2. Record where approved recovery information and credential inventories are held without copying their values.
3. Identify the role responsible for periodic credential and ownership review.
4. Ask another authorized person to locate the checklist through the normal process.

Verification or retest: Have the second authorized person confirm they can locate the checklist, then repeat after ownership or credential-process changes.

Completion evidence: A reviewed access and ownership checklist.

Safety: Never paste private keys, tokens, recovery codes, or repository settings into SIU.

Restore a critical repository in a disposable location

Outcome: Verify the selected backup method in a disposable private location.

Method: Use the documented repository backup method, note its coverage limits, and restore it in a disposable private location that has no production connection.

Limitations: A migration archive is not an automatically restorable backup path. The selected method must be reviewed against the organization's recovery objective and access controls.

1. Identify repositories whose loss would block the approved recovery path.
2. Create or update an approved external mirror and fetch Git LFS objects where used.
3. Record items not covered by the mirror, such as packages, discussions, external secrets, or deployment configuration.
4. Restore the selected backup into a disposable private location with no production connection.

Verification or retest: Confirm important refs and required files in the disposable restore, then repeat the drill on the approved cadence or after a material backup-process change.

Completion evidence: A successful disposable restore with date, owner, and documented coverage limits.

GitHub Docs: backing up a repository ↗

Safety: Use a disposable private location and do not connect a restore drill to production systems.

Review deployment workflow boundaries

Outcome: Review token permissions, third-party Action pinning, and privileged workflow triggers.

Method: Review each workflow in a branch, set permissions deliberately, pin reviewed third-party Actions by full-length commit SHA, and examine whether untrusted code can reach privileged context.

Limitations: Workflow changes can affect builds and deployments. GitHub documentation must be read for the repository's trigger and authentication model; SIU cannot validate an individual workflow.

1. Review each job's GITHUB_TOKEN permissions and document why each required permission is needed.
2. Review third-party Actions and pin approved versions to reviewed full-length commit SHAs.
3. Review privileged triggers and ensure untrusted code cannot reach protected secrets or privileged context.
4. Test approved workflow changes in a branch or non-production path before requesting normal review.

Verification or retest: Review the changed workflow with the responsible owner, confirm the intended path works without disclosing secrets in logs, and repeat after material workflow changes.

Completion evidence: A reviewed workflow with explicit permissions and reviewed dependency references.

GitHub Docs: secure use reference ↗

Safety: Never expose secrets in workflow logs or SIU; review workflow changes in a branch.

Document a deployment recovery path

Outcome: Record deployable references, approval boundaries, artifact location, and rollback steps.

Method: Use the repository's documented environment and change process to record allowed deployable references, review requirements, approved artifact locations, and a non-production rollback exercise.

Limitations: Environment protection features depend on repository visibility, plan, and configuration. This action does not create a deploy or authorize a production rollback.

1. Identify the protected branch or tag and the normal approval boundary for deployments.
2. Document which environment protections and secret-access rules are enabled for the repository.
3. Record the approved location and owner of the last known-good deployable artifact without copying credentials.
4. Test the rollback or alternate path in a non-production environment using the organization's approved change process.

Verification or retest: Have the deployment owner review the path and repeat the non-production test after a material workflow, environment, or artifact-process change.

Completion evidence: A reviewed deployment recovery record and a tested non-production recovery exercise.

GitHub Docs: deployments and environments ↗

Safety: Production changes require the repository's approved authorization and rollback process.