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
- Open the repository on GitHub.
- Select Settings.
- Under Code and automation, select Rules → Rulesets.
- Create a new branch ruleset.
- Name it
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 release 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. 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:
- 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. 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 Settings → Actions → General → Workflow 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.