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.

Baseline status

Control Required state Evidence on 2026-08-16 Status
Private vulnerability reporting Enabled GitHub API returned {"enabled":true} Verified enabled
CodeQL GitHub Actions analysis Enabled and running CodeQL workflow run #1 (31974178430) completed successfully Verified enabled for GitHub Actions workflow analysis
Repository ruleset for main Active Repository rulesets API returned an empty list Not satisfied
Dependabot configuration for GitHub Actions Weekly update monitoring .github/dependabot.yml schedules weekly GitHub Actions updates Implemented in repository configuration
Dependabot alerts Enabled Connected integration receives HTTP 403 from the live vulnerability-alert setting endpoint Live verification required
Dependabot security updates Enabled Connected integration cannot read/administer this Advanced Security setting Live verification required
Secret scanning Enabled Connected integration cannot read/administer this Advanced Security setting Live verification required
Push protection for secrets Enabled Connected integration cannot read/administer this Advanced Security setting Live verification required
Code scanning alert state Reviewable with no unaccepted blocker for release CodeQL analysis uploads successfully; connected integration receives HTTP 403 when listing code-scanning alerts Live alert review required
Default GitHub Actions workflow permissions Read-only by default unless a workflow declares narrower/required permissions Connected integration receives HTTP 403 from the repository workflow-permissions endpoint Live verification required
Classic main branch protection Superseded by or compatible with the required active ruleset Connected integration receives HTTP 403 from the classic branch-protection endpoint Live verification required; no repository ruleset currently exists

Required main ruleset

Before the repository is treated as release-ready, create 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;
  • include the repository Quality Gate as a required check once GitHub offers the exact observed check name for selection;
  • include CodeQL/code-scanning requirements when the repository plan and GitHub UI expose an appropriate rule without creating a circular or unusable workflow;
  • do not grant broad bypass access merely to make the rule convenient.

This project intentionally works directly on main during pre-release repository construction. If a temporary administrative bypass is needed while finishing v0.1.0, it must be explicit and removed or narrowed before the final release-readiness decision. The release decision must not claim main is protected while the rulesets API remains empty.

Configure the ruleset

  1. Open the repository on GitHub.
  2. Select Settings.
  3. Under Code and automation, select RulesRulesets.
  4. Create a new branch ruleset.
  5. Name it Protect main.
  6. Set enforcement to Active.
  7. Target the default branch.
  8. Enable the minimum protections listed above.
  9. Save the ruleset.
  10. Re-run the verification steps in this document and record the result in the release evidence.

Advanced Security settings to verify

Open SettingsSecurityAdvanced 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. This was independently verified through the API on 2026-08-16.

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

Code scanning review

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

Before stable release:

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

PowerShell source is not represented as CodeQL-covered. PowerShell security analysis remains the responsibility of the repository-owned PSScriptAnalyzer security rules, Pester contracts, review, and the broader assurance process.

GitHub Actions permissions

Open SettingsActionsGeneralWorkflow permissions and verify the repository default is the least privilege appropriate for the project, preferably Read repository contents and packages permissions rather than a broad read/write default.

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

Evidence classification

Use these terms consistently:

  • Verified enabled — live setting or behavior was read directly from GitHub.
  • Implemented in repository configuration — repository files enforce or configure the behavior, but a platform-side setting may still be relevant.
  • Live verification required — the connected integration cannot prove the current setting.
  • Not satisfied — live evidence proves the intended baseline is currently missing.

The release-readiness process must treat Not satisfied separately from Live verification required. A permissions limitation in the verification integration is not evidence that a control is either enabled or disabled.