Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Which GitHub artifacts count as security evidence?
Updated
GitHub evidences three control areas well: change management through rulesets and pull-request records, access through organisation and repository permissions, and vulnerability management through Dependabot, code scanning, and secret scanning. This page is not legal advice, does not determine YOUR obligations, and does not file with an auditor.
GitHub evidence map, last verified 10 September 2026 against GitHub's public documentation for rulesets and branch protection, code scanning, secret scanning, Dependabot alerts, the dependency graph, and the organisation audit log, read alongside the AICPA Trust Services Criteria (CC6 access, CC7 vulnerability, CC8 change) and ISO/IEC 27001:2022 Annex A 5.15, 8.8, 8.28 and 8.32. GitHub's plan packaging changes: several scanning capabilities are included for public repositories but gated behind GitHub Advanced Security for private ones, and GitHub has been restructuring Advanced Security into separately purchasable Code Security and Secret Protection products. Re-check current packaging in GitHub's own documentation before you rely on it. This page is not legal advice and does not determine YOUR obligations.
What this page is, and what it is not
Audience: an engineering leader, security engineer, or compliance owner whose code lives on GitHub and who needs to know which GitHub surface answers which audit question. This page extends the GitHub connector setup guide on this site rather than repeating it: that page covers installing and scoping the App, this page covers what the resulting artifacts evidence.
This page is not legal advice. It does not determine YOUR obligations, does not decide which frameworks apply to your organisation, does not start a clock, and does not file anything with an auditor. Mapping a control to a GitHub artifact is a planning step, not a conclusion that the control is effective — the operating-effectiveness question is covered by the prove-a-control-works page in this cluster. Last verified 10 September 2026.
Content here is text by design, including the UI paths. Where you would expect a screenshot, you get the navigation path — for example Settings → Rules → Rulesets — so the instruction stays readable and stays correct longer than an image would. Take your own screenshots for the evidence pack if your auditor wants them; a system-generated export is stronger where one exists.
- Plan and packaging gating is described as included versus GitHub Advanced Security (GHAS) gated, because that is how GitHub itself frames it. Public repositories get several scanning features that private repositories do not without GHAS.
- GitHub's own documentation is the authority on packaging and on where a setting lives. Verify before you promise an auditor an artifact you cannot produce.
- An artifact is only evidence if you can produce the population. For change management that means all merges to the protected branch in the period, not a handful of well-behaved pull requests.
- Rulesets and classic branch protection coexist. Record which mechanism actually enforces your protected branches, because an auditor will test the one that is live, not the one in your policy.
Control-to-GitHub-artifact map
Read the first column as the control assertion, the second as the GitHub artifact that supports it, the third as where to find it in the interface, and the fourth as the packaging note. A framework reference in the last column is not a finding that the framework applies to you. Last verified 10 September 2026 against GitHub's public documentation. Not legal advice.
| Control assertion | GitHub artifact | Where it lives (UI path) | Packaging and framework note |
|---|---|---|---|
| Changes to production code are reviewed and approved before merge | Ruleset or branch-protection configuration requiring pull requests and a minimum number of approving reviews; the pull-request record showing reviewers, approvals, and merge time | Repository Settings → Rules → Rulesets, or Settings → Branches for classic protection. Evidence of individual changes: the Pull requests tab, filtered to merged into the protected branch within the period. | Rulesets and branch protection are included for public repositories; for private repositories GitHub documents them as requiring a paid organisation plan. Maps to AICPA TSC CC8.1 and ISO/IEC 27001:2022 Annex A 8.32. |
| Automated checks must pass before a change reaches production | Required status checks in the ruleset, plus the check-run history on each merged pull request and the workflow run history | Repository Settings → Rules → Rulesets → require status checks to pass. Run history: the Actions tab, and the Checks section of each pull request. | Included where Actions is available on the plan; Actions minutes are metered. Maps to AICPA TSC CC8.1 and NIST SSDF (SP 800-218) PW and PS practices. |
| Nobody can bypass the change path, including administrators | Ruleset bypass list, the do-not-allow-bypass configuration, and the ruleset insights showing bypass events | Repository or organisation Settings → Rules → Rulesets → Bypass list; Settings → Rules → Rulesets → Insights for evaluation and bypass history. | Ruleset insights and organisation-level rulesets are documented by GitHub as plan-dependent; verify for your plan. Maps to AICPA TSC CC8.1 and segregation-of-duties expectations under PCAOB AS 2201 where SOX applies. |
| Only authorised people have access, at the least privilege needed | Organisation member list with roles, team membership, repository collaborator and team permission levels, outside-collaborator list | Organisation → People; Organisation → Teams; Repository Settings → Collaborators and teams. | Included on all organisation plans. Maps to AICPA TSC CC6.1–CC6.3 and ISO/IEC 27001:2022 Annex A 5.15 and 5.18. |
| Access is removed promptly when someone leaves or changes role | Audit-log entries for member removal, team membership changes, and repository permission changes, correlated with the leaver record in your HR system | Organisation Settings → Logs → Audit log, filtered by action (for example org.remove_member, team.remove_member, repo.remove_member). | Organisation audit log is included; audit-log streaming and the longer retention window are documented as GitHub Enterprise Cloud capabilities. Maps to AICPA TSC CC6.2 and Annex A 5.18. |
| Strong authentication is enforced for everyone with code access | Organisation setting requiring two-factor authentication, plus SAML single sign-on and SCIM provisioning records where used | Organisation Settings → Authentication security. Enterprise-managed identity settings live in Enterprise Settings → Authentication security. | Two-factor enforcement is included; SAML SSO and SCIM are documented as GitHub Enterprise Cloud capabilities. Maps to AICPA TSC CC6.1 and Annex A 5.17. |
| Code is analysed for security weaknesses before release | Code-scanning alerts and their history, the code-scanning configuration, and the analysis run records | Repository → Security tab → Code scanning; configuration at Settings → Code security → Code scanning. | Code scanning with CodeQL is included for public repositories; for private repositories GitHub documents it as requiring GitHub Advanced Security, which GitHub has been repackaging as a Code Security product. Verify current packaging. Maps to AICPA TSC CC7.1 and Annex A 8.28. |
| Secrets are not committed, and leaked secrets are detected and rotated | Secret-scanning alerts with status and resolution, push-protection configuration and bypass records | Repository → Security tab → Secret scanning; configuration at Settings → Code security → Secret scanning and push protection. | Secret-scanning alerts are included for public repositories; for private repositories GitHub documents them as GHAS-gated, repackaged as a Secret Protection product. Verify current packaging. Maps to AICPA TSC CC6.1 and CC7.1, and Annex A 8.24. |
| Known-vulnerable dependencies are identified and remediated | Dependabot alerts with severity and status, Dependabot security-update pull requests, and the dependency graph for the repository | Repository → Security tab → Dependabot alerts; Insights → Dependency graph; configuration at Settings → Code security. | Dependabot alerts and the dependency graph are documented by GitHub as available for repositories generally, not GHAS-gated. Maps to AICPA TSC CC7.1 and Annex A 8.8 and 8.28. |
| Build and deployment steps are controlled and approved | Environment protection rules with required reviewers and wait timers, deployment history per environment, and workflow run logs | Repository Settings → Environments; deployment history on the repository home Environments panel and the Actions tab. | Environment protection rules are documented as included for public repositories and available on paid plans for private ones. Maps to AICPA TSC CC8.1 and Annex A 8.32. |
| Released artifacts can be traced to the source that produced them | Build provenance attestations produced in the workflow, release assets and tags, and the workflow run that produced them | The Actions tab for the producing run; the repository Releases page for tagged assets; attestation records where the workflow generates them. | Artifact attestation is documented by GitHub as available for public repositories and on paid plans; details change, so verify. Maps to SLSA provenance levels, which are best practice and not a requirement — see the CI/CD page in this cluster. |
| Repository and organisation configuration changes are recorded | Audit-log entries for protected-branch, ruleset, secret-scanning, and permission changes | Organisation Settings → Logs → Audit log; export from that view, or via the audit-log API where the plan allows. | Audit log is included; API access, streaming, and extended retention are documented as Enterprise Cloud capabilities. Maps to AICPA TSC CC7.2 and Annex A 8.15. |
Legal requirement, guidance, best practice, or our recommendation
None of the GitHub configurations above is required by a statute simply because it is a good idea. Record why each one exists, so that the control set survives a change of team. Last verified 10 September 2026. Not legal advice.
| Statement | Which kind of authority | What it does not mean |
|---|---|---|
| PCI DSS v4.0.1 Requirement 6.2 asks that bespoke and custom software be developed securely, including code review before release to production. | Legal requirement in the contractual sense, for entities in scope of PCI DSS through card-brand and acquirer agreements. | Does not mandate GitHub, rulesets, or any particular tool, and does not apply where no cardholder data is in scope. |
| AICPA TSC CC8.1 requires that changes to infrastructure, data, software, and procedures be authorised, designed, developed, configured, documented, tested, approved, and implemented. | Attestation criteria. They apply because you sought a SOC 2 report or a customer contract requires one. | Does not name pull requests, required reviewers, or a number of approvals. Those are your design choice. |
| ISO/IEC 27001:2022 Annex A 8.28 secure coding and 8.32 change management. | Certification requirement where you seek or hold ISO/IEC 27001 certification. | Does not require code scanning as a product, and does not make an organisation without certification non-compliant with anything. |
| NIST SSDF (SP 800-218) practices for reviewing code, verifying third-party components, and archiving release artifacts. | Regulatory and standards guidance. Binding on some US federal software suppliers through separate acquisition authority; otherwise a reference. | Does not become a legal obligation because you cite it in a policy. |
| Require at least one approving review from someone other than the author, block bypass for administrators, and require status checks on the default branch. | Industry best practice, widely expected by auditors as a matter of practice. | Does not appear as a numbered requirement in the criteria above, and one reviewer is not automatically sufficient for a segregation-of-duties assertion. |
| Export the merged-pull-request population and the audit log for the period at the start of the audit, not when the auditor asks, and record who produced each export. | ShipReady Metrics recommendation. | Does not make the control effective by itself, and is not required by any framework named here. |
Included versus GHAS-gated, and what to do when a feature is gated
The packaging question matters for evidence because a control you cannot enable is a control you cannot evidence. Where a scanning capability is included for public repositories but gated for private ones, you have three honest options and one dishonest one. The dishonest one is claiming the control anyway. Last verified 10 September 2026 against GitHub's public documentation, which is the authority on current packaging.
- Buy the capability, and evidence it from the GitHub surface directly. Simplest, and the artifact is native.
- Substitute an equivalent third-party scanner in the pipeline, and evidence it from the CI run records and the scanner's own reports. Record the substitution in the control description so the auditor is not surprised.
- Accept the gap, document it as a gap with a risk decision and an owner, and revisit on a stated date. This is a defensible position; an undocumented absence is not.
- Do not describe a control as operating because the feature exists in GitHub's catalogue. Evidence is what the setting shows in your organisation, in the period.
- Where GitHub has repackaged capabilities — Advanced Security has been split into separately purchasable Code Security and Secret Protection products — record which product you actually hold, because that is what determines the artifact you can produce.
Checklist
A question list for the GitHub side of your evidence set. Not a determination that any framework applies to you. Last verified 10 September 2026. Not legal advice.
- Can we produce the complete list of repositories in audit scope, and does every one of them actually have the protection we claim?
- Is the protected branch enforced by a ruleset, by classic branch protection, or by neither, and does our control description match what is live?
- Who is on the bypass list for each ruleset, and can we show the bypass events for the period?
- Can we export every merge to the protected branch for the period, with reviewer and approval timestamps, as one population?
- Are two-factor authentication and, where applicable, single sign-on enforced at the organisation level rather than by convention?
- Do we have the audit-log entries for member removals in the period, and do they reconcile with the leaver list from HR?
- For each scanning capability we claim, is it included on our plan or GHAS-gated, and do we hold the product that gates it?
- Are Dependabot alerts triaged with a recorded decision, or are they simply accumulating unread?
- Do environment protection rules exist for production deployments, with required reviewers who are not the change author?
- Is every artifact above owned by a named person with a refresh cadence?
What to do now
Ordered so that the artifacts auditors ask for first become producible first. None of these steps is a legal determination, and none files anything with an auditor.
- Fix the repository scope list first. Most GitHub evidence findings are not about a missing setting; they are about a repository nobody remembered was in scope.
- Standardise protection with an organisation-level ruleset rather than per-repository configuration, so the evidence is one artifact instead of many.
- Export the merged-pull-request population and the organisation audit log for the current period now, and store them in your evidence repository with the date and the person who exported them.
- Decide the packaging question for code scanning and secret scanning explicitly: buy it, substitute a pipeline scanner, or record the gap. Then align the control description to the decision.
- Turn Dependabot alert triage into a recorded decision — remediate, schedule, or accept with a named approver — so the vulnerability control has an artifact rather than a queue.
- Add environment protection with a reviewer other than the change author for production, which is the cheapest available segregation-of-duties artifact for a small team.
- Re-verify GitHub's documentation for packaging and UI paths at least annually, and record the date. Ours says 10 September 2026.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. The GitHub App this product installs is read-only. It requests Contents, Metadata, Pull requests, Actions, Administration, and the Dependabot, code-scanning, and secret-scanning alert scopes, plus organisation Members. It does not configure branch protection or rulesets, does not export your audit pack, and does not file anything with an auditor.
What it does: ingests Dependabot alerts, code-scanning alerts, and secret-scanning alerts as findings, deduplicates across sources, and ranks them using CISA KEV membership, EPSS, and CVSS. Blast-radius search runs over captured dependencies, including transitive npm dependencies where a lockfile was fetched.
Delivery Health computes DORA posture — deployment frequency, lead time for changes, change failure rate, and time to restore — from connected sources including GitHub Actions runs. That is engineering posture, not a change-management control opinion and not an incident-response runbook.
If you already have a session: signed-in app → Compliance holds evidence collection for control-mapped artifacts across starter control subsets, and evidence review where a named human accepting a manual row renders it met and rejecting it renders it a gap, with a timestamp. That is a compliance artifact, not a forensic chain of custody and not an auditor's opinion. The obligation map lists frameworks your organisation marked in-scope; that mark is not a legal opinion that a framework applies.
The GitHub connector setup guide on this site is the page for scopes, installation, and least-privilege configuration. This page is the evidence layer on top of it.
Primary sources (last verified 10 September 2026)
GitHub's own documentation is the authority for every product behaviour and packaging claim above; framework references are labelled by the kind of authority they carry.
GitHub documentation for repository rulesets and protected branches, code scanning, secret scanning, Dependabot alerts, the dependency graph, deployment environments, artifact attestations, and the organisation audit log. AICPA Trust Services Criteria CC6, CC7, and CC8 are professional attestation criteria. ISO/IEC 27001:2022 Annex A 5.15, 5.17, 5.18, 8.8, 8.24, 8.28 and 8.32 are certification requirements. NIST SSDF (SP 800-218) is guidance. PCI DSS v4.0.1 Requirement 6.2 binds entities in scope through contract. Not a complete list, and not legal advice.
The CI/CD, change-management, vulnerability-management, and dependency pages in this cluster cover the pipeline, change, and supply-chain sides in depth. The GitLab checklist is the equivalent map for GitLab-hosted code.
Frequently asked questions
Is this legal advice?
No. It is an operational mapping of GitHub artifacts to control assertions, with framework references labelled by the kind of authority they carry. Whether SOC 2, ISO/IEC 27001, PCI DSS, or any statute applies to your organisation is a legal and commercial question for counsel and your contracts. This page does not determine YOUR obligations and does not file anything with an auditor.
Is a merged pull request enough evidence of change management?
It is the core artifact, and it is not sufficient on its own. An auditor will also want the enforcement configuration that made review unavoidable, the complete population of merges in the period rather than a sample you chose, and evidence that bypass was either impossible or recorded. A pull request with an approval from the author's own account evidences the opposite of what you intended.
What if code scanning is GHAS-gated on our private repositories?
You have three honest options: buy the capability that gates it, substitute a scanner in the pipeline and evidence it from CI run records and the scanner's reports, or record the absence as a documented gap with an owner and a revisit date. What you should not do is claim the control because the feature exists in GitHub's catalogue. GitHub's documentation is the authority on current packaging — verify it.
How long does GitHub keep the audit log?
GitHub documents an organisation audit-log retention window and offers audit-log streaming and API access on higher plans; the specifics change, so read GitHub's current documentation rather than trusting a period quoted anywhere else. Where your required retention is longer than what your plan keeps, export on a schedule into your own evidence repository and record who performed each export.
Does the ShipReady GitHub App change our repository settings?
No. The App is read-only. It reads repository content and metadata, pull requests, Actions runs, administration and organisation member data, and the Dependabot, code-scanning, and secret-scanning alert feeds. It does not configure branch protection or rulesets, does not open or merge pull requests, does not export your audit pack, and does not file with an auditor.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.