GitHub repository security baseline

This document records the repository-level GitHub security baseline for infoconex/copy-github-repo. It distinguishes settings verified from the live repository from settings that the connected GitHub integration cannot read or administer.

A feature is never described as enabled merely because GitHub may enable it by default for some public repositories. Owner-side verification performed in the GitHub web UI is recorded explicitly as such and is not represented as API evidence.

The initial v0.1.0 clean-repository qualification is complete. Historical verification dates remain useful evidence, but future releases and security-relevant repository changes must verify the resulting live state again rather than treating August 2026 observations as permanent platform guarantees.

Baseline status

Control	Required state	Evidence	Status
Private vulnerability reporting	Enabled	GitHub API returned `{"enabled":true}` on 2026-08-16; repository owner also confirmed the live security settings in the GitHub web UI on 2026-08-19; the baseline was restored/reverified during the clean-repository `v0.1.0` qualification	Verified enabled for the qualified `v0.1.0` repository state
GitHub Actions CodeQL analysis	Enabled and running	CodeQL workflow execution completed successfully during qualification and continues to be repository-controlled	Verified enabled for GitHub Actions workflow analysis
PowerShell code security analysis	Dedicated repository-owned gate	`Analyze Code Security` uses a security-only PSScriptAnalyzer profile plus targeted security behavior tests	Implemented in repository configuration; workflow evidence is release-specific
Repository ruleset for `main`	Active with six GitHub Actions-bound required checks	Repository owner created an active branch ruleset named `main` in 2026; maintainer explicitly approved four additional gates on 2026-10-20; the complete live ruleset ID 21202675 was independently fetched and its behavior checked with a real, non-merging PR after the expansion	Owner verified for the qualified `v0.1.0` repository state; independently verified active with six checks on 2026-10-20
Dependabot configuration for GitHub Actions	Weekly update monitoring	`.github/dependabot.yml` schedules weekly GitHub Actions updates	Implemented in repository configuration
Dependabot alerts	Enabled	Repository owner confirmed the live Advanced Security settings in the GitHub web UI on 2026-08-19; baseline restoration/reverification was part of clean-repository qualification	Owner verified enabled for the qualified `v0.1.0` repository state
Dependabot security updates	Enabled	Repository owner confirmed the live Advanced Security settings in the GitHub web UI on 2026-08-19; baseline restoration/reverification was part of clean-repository qualification	Owner verified enabled for the qualified `v0.1.0` repository state
Secret scanning	Enabled where GitHub exposes the setting	Repository owner confirmed the live Advanced Security settings in the GitHub web UI on 2026-08-19; baseline restoration/reverification was part of clean-repository qualification	Owner verified enabled/available configuration for the qualified `v0.1.0` state
Push protection for secrets	Enabled where available	Repository owner confirmed the live Advanced Security settings in the GitHub web UI on 2026-08-19; baseline restoration/reverification was part of clean-repository qualification	Owner verified enabled/available configuration for the qualified `v0.1.0` state
Code scanning alert state	Reviewable with no unaccepted release blocker	GitHub Actions CodeQL analysis uploads successfully; the connected integration has historically received HTTP 403 when listing code-scanning alerts	Live verification required for each release decision where alert state could have changed
Default GitHub Actions workflow permissions	Read-only by default unless a workflow declares narrower/required permissions	Repository owner confirmed the repository Actions workflow-permission setting in the GitHub web UI on 2026-08-19; baseline restoration/reverification was part of clean-repository qualification	Owner verified for the qualified `v0.1.0` repository state
Classic `main` branch protection	Superseded by or compatible with the required active ruleset	Active `main` ruleset is the repository’s intended protection mechanism	Satisfied by ruleset; classic protection is not independently required

Required `main` ruleset

Maintain an active branch ruleset targeting the default branch (main). The intended minimum is:

block branch deletion;
block force pushes;
require changes to arrive through a pull request for normal contributor changes;
require required status checks before merge;
retain the two original required job contexts Validate PowerShell (windows-latest) and Analyze PowerShell Code Security;
additionally require Required Project Quality Gate, Required PowerShell Security Gate, Required GitHub Actions Security Gate, and Required Documentation Gate;
bind each of these six exact status-check contexts to the GitHub Actions integration ID 15368; use the observed check job names, not the workflow display names Validate Project Quality or Analyze Code Security;
require the scope-aware final gates to detect missing, failed, unexpectedly skipped, or cancelled mandatory work without making conditional substantive jobs directly required;
do not grant broad bypass access merely to make the rule convenient.

Workflow and job names are part of the observable status-check surface. When workflow/job names or trigger behavior change, verify configured required-check contexts against the newly observed checks before treating the ruleset as satisfied. Required workflows should still produce a successful/skipped check for documentation-only pull requests rather than disappearing entirely and leaving branch protection waiting for an expected check.

The live repository uses an active ruleset named Main (ruleset ID 21202675). Its 2026-10-20 authenticated API readback independently confirmed enforcement=active, target only refs/heads/main, exactly the six contexts and integration IDs above, deletion/non-fast-forward/pull-request requirements, no bypass actors ([]), strict_required_status_checks_policy=false, and do_not_enforce_on_create=false. The ruleset name is not itself a security contract; these live settings and observed enforcement are. Re-read them for each security-sensitive release or repository replacement rather than assuming they stay unchanged.

A future same-name Snapshot replacement may require a controlled administrative path. Any temporary bypass must be explicit and removed or narrowed before the resulting repository is considered qualified.

Safe expansion of required CI gates

The four final gates are now active requirements, not proposals. The owner authorized the specific four-context expansion separately, and the complete ruleset was independently read back on 2026-10-20. The October 2026 owner-approved rollout was qualified with a non-merging pull request that demonstrated GitHub blocked a failing or pending documentation gate and reported the corrected, all-required-checks-complete PR as clean. The probe was closed without merge; this is genuine enforcement evidence, not a claim that every future CI workflow succeeds.

Each of the four final gate contexts must be emitted for every applicable pull request. Conditional substantive jobs (PowerShell security analysis, GitHub Actions CodeQL, and optional matrix work) can legitimately be skipped only where verified scope declares them inapplicable. Scope-aware final gates must fail closed on missing/failed scope decisions, missing or failed required execution, and unexpected cancellations or skips; never mark an unrun mandatory analysis as successful just because GitHub accepts a skipped check. For source changes, full quality includes Windows, Ubuntu and macOS. Documentation validation is required for documentation-relevant changes; GitHub Actions CodeQL analysis is required for workflow-file changes. The two original directly required contexts remain required and GitHub may accept an intentional skipped conclusion for an inapplicable original context; the new final gate is responsible for independently enforcing correct applicability and upstream outcomes.

For future required-check changes, first qualify representative source, documentation-only, workflow, and genuine Dependabot PR evidence where safely available, including a negative case. Bind new contexts to their observed GitHub Actions integration and exact check job names, and preserve the two original contexts. Make a live membership change only after a separate exact owner authorization, then independently read back the entire ruleset and verify non-destructive PR enforcement. If a newly required context fails to appear or deadlocks legitimate changes, preserve evidence and, under appropriate owner authorization, roll back only the newly added requirement rather than weakening pre-existing checks, force-push protection, PR requirements, or adding bypass actors. Maintenance-only repository changes do not require an official product release; see the maintainer guide.

Configure or reconfigure the ruleset

Open the repository on GitHub.
Select Settings.
Under Code and automation, select Rules → Rulesets.
Create or edit the branch ruleset used to protect main.
Set enforcement to Active.
Target the default branch.
Enable the minimum protections listed above.
Save the ruleset.
Re-run the verification steps in this document and record the result in the relevant release/security evidence.

Advanced Security settings to verify

Open Settings → Security → Advanced Security and verify these controls directly:

Dependabot alerts: enabled.
Dependabot security updates: enabled.
Secret scanning: enabled when GitHub exposes the setting for the repository/account.
Push protection: enabled when available.
Private vulnerability reporting: enabled.

The repository owner verified these settings in the GitHub web UI on 2026-08-19 during pre-Snapshot preparation. The required baseline was subsequently restored and reverified for the clean repository as part of v0.1.0 qualification. Those observations are release evidence, not a substitute for fresh verification after a future repository replacement or security-relevant configuration change.

Do not infer the state of these toggles from repository visibility or GitHub defaults. Capture the actual setting state during release readiness when live state may have changed.

Code scanning review

The repository-owned .github/workflows/analyze-github-actions-security.yml analyzes GitHub Actions workflow code with CodeQL. Successful workflow execution proves the configured analysis ran and uploaded its result; it does not by itself prove there are zero open code-scanning alerts.

For a stable release or material security-sensitive change:

Open Security → Code scanning.
Review open alerts for the repository.
Resolve any release-blocking finding or explicitly record a risk acceptance through the release-readiness process.
Preserve the relevant workflow run and alert disposition as release evidence.

PowerShell source is not represented as CodeQL-covered. .github/workflows/analyze-code-security.yml provides the separate PowerShell-aware security gate using PSScriptAnalyzerSecuritySettings.psd1, the repository-owned custom security rule, selected built-in PSScriptAnalyzer security rules, and targeted Pester safety/security behavior tests. This separation avoids implying that CodeQL scans PowerShell while still giving PowerShell security findings a dedicated CI surface.

GitHub Actions permissions

Open Settings → Actions → General → Workflow permissions and verify the repository default is Read repository contents and packages permissions rather than a broad read/write default. Do not enable Actions to create or approve pull requests unless a documented workflow requirement justifies it.

The repository owner verified the live workflow-permission setting in the GitHub web UI on 2026-08-19, and the required baseline was restored/reverified during clean-repository release qualification.

Individual workflows must continue declaring explicit permissions appropriate to their jobs. Repository defaults are a backstop, not a substitute for workflow-level least privilege.

Snapshot replacement responsibility and qualification

A same-name Snapshot replacement creates a new GitHub repository object. Repository-hosted files move with the approved Snapshot tree, but GitHub platform settings are not part of Git commit history and must not be assumed to survive repository replacement.

Treat the controls in this document as follows:

Control	Source-controlled / product-restored behavior	Owner-side post-Snapshot requirement
`.github/dependabot.yml` update schedule	Included in the Snapshot tree and therefore restored with approved repository content	Verify Dependabot is operating after replacement
CodeQL and PowerShell security workflows	Included in the Snapshot tree	Verify workflows are enabled and complete successfully on the replacement repository
General repository settings and protection restoration supported by the product	Governed by the product’s documented `CAP-SET` / `CAP-PROT` behavior and exact migration result	Verify the resulting live settings rather than assuming restoration succeeded
`main` ruleset / branch protection required by this baseline	Do not assume preservation merely because product protection restoration exists; the baseline requires the exact live rule behavior described above	Reapply or correct the rule after replacement and verify deletion, force-push, PR, and required-check behavior
Dependabot alerts	Not represented by Git content	Verify enabled in the replacement repository
Dependabot security updates	Not represented by Git content	Verify enabled in the replacement repository
Secret scanning	Not represented by Git content	Verify enabled where the account/repository exposes it
Push protection for secrets	Not represented by Git content	Verify enabled where available
Private vulnerability reporting	Not represented by Git content	Verify enabled in the replacement repository
Default GitHub Actions workflow permissions	Not represented by Git content	Set/verify the least-privilege repository default
Code-scanning alert disposition	Alert state is GitHub platform state, not Snapshot content	Review the replacement repository’s code-scanning results and disposition any blocker

The product’s supported settings/protection restoration is useful migration behavior, but it is not evidence that this security baseline is satisfied. Security qualification always verifies the resulting live repository.

Required post-Snapshot security qualification

The following qualification was completed for the clean v0.1.0 repository and is required again after any future same-name Snapshot replacement:

Confirm the replacement repository is the intended same-name repository and main is the default branch.
Confirm the approved Snapshot tree contains .github/dependabot.yml and all required security/quality workflows.
Reapply or verify the active main protection ruleset and its exact required-check contexts.
Verify Dependabot alerts and Dependabot security updates.
Verify secret scanning and push protection where GitHub exposes those controls.
Verify private vulnerability reporting.
Verify the default GitHub Actions workflow permission is least privilege and that workflows use explicit job/workflow permissions where required.
Run the required quality/security workflows from the replacement repository and confirm successful evidence is bound to the clean replacement commit.
Review code-scanning alerts and disposition any release blocker.
Record any unavailable platform feature as a release-specific limitation with the platform/account constraint and compensating control; do not silently mark it satisfied.

A pre-Snapshot verification result does not carry forward as evidence for a replacement repository. For v0.1.0, the clean repository was qualified independently before the stable tag and publication. The same rule applies to any future replacement.

Evidence classification

Use these terms consistently:

Verified enabled — live setting or behavior was read directly from GitHub through an independently queryable interface.
Owner verified / Owner verified enabled — the repository owner inspected the live GitHub web UI and confirmed the setting or behavior; the connected integration could not independently read that setting.
Implemented in repository configuration — repository files enforce or configure the behavior, but a platform-side setting may still be relevant.
Live verification required — the current evidence does not prove the setting or release-specific state.
Not satisfied — live evidence proves the intended baseline is currently missing.

A permissions limitation in the verification integration is not evidence that a control is either enabled or disabled. Owner-side verification must be labeled distinctly from API evidence, and any future replacement repository must be verified independently after the Snapshot migration.