GitHub Security Assessment
176 questions on a GitHub organisation, from branch protection to runners, scored per control.
176 controls · 10 pillars · 40 categories · evidence can be collected automatically
176 questions on a GitHub organisation, from branch protection to runners, scored per control.
176 controls · 10 pillars · 40 categories · evidence can be collected automatically
The platform that holds your source code now decides what reaches production, and an attacker who reaches it never has to touch your servers. This assessment scores how change is authorised, who holds administrative rights, and what is logged, independently of the team that set it up. It produces the supply chain assurance evidence that ISO 27001, SOC 2 and the software assurance clauses in large contracts increasingly ask to see.
176 questions across 10 pillars and 40 categories, taking in enterprise and organisation policy, membership, branch and review policy, workflows, runners, release approval and secrets. A read-only collector reads settings through a token you issue and can revoke; it writes nothing, so no repository, workflow or pipeline is altered and no workflow run is triggered. The output is a score per pillar, which answers a customer security questionnaire or feeds an ISO 27001 surveillance visit without a separate exercise.
Inspects enterprise policy set centrally against settings left per organisation, two-factor enforcement and single sign-on conditions, outside collaborator reach, default branch protection with review and status check requirements, protection on branches other than the default, secret scanning coverage and push protection bypass, workflow token permissions, allowed actions and version pinning, untrusted input in trigger contexts, self-hosted runner exposure and isolation, deployment environments and approvals, federated deployment credentials, build provenance and release signing, deploy keys, installed apps and webhook integrity, and audit log coverage including AI coding assistant governance. The collector reads these settings through the platform API, and each finding becomes a suggestion the assessor accepts or overrides before it is scored.
176 controls across 10 pillars and 40 categories. Every one is scored, and a control nobody can answer is recorded as unanswered rather than counted as a pass.
A read-only collector script reads enterprise, organisation and repository settings using a token you issue and can revoke, and each finding becomes a suggestion an assessor accepts or overrides before scoring. A setting the token has no rights to read is recorded as unread, not as a failure.
It can confirm that a review requirement exists and that it cannot be bypassed; it cannot tell you whether the reviews themselves are genuine, which only the people doing them can answer.
Defence and critical infrastructure suppliers are asked to evidence build provenance and release signing, which here is a scored pillar of 17 questions rather than a single tick.
Public sector software assurance asks who may merge to a deployed branch, and the source integrity pillar answers that across 24 scored questions.
Financial services need change control that survives an audit, including what is enforced on the branches nobody thought to protect.
Health and education teams run lean and share repositories with suppliers, so outside collaborator access and membership review are scored explicitly.
A fixed fee for the engagement, not an annual licence. The band follows the size of the bank: this one is standard at 176 controls.
£3,500
Per engagement, excluding VAT.
£9,000
Per engagement, excluding VAT.
Hold three or more and the Combined Security View is produced at no extra charge: it is derived from the banks you already hold rather than assessed again. See the full assessment rate card, or build a quote with this assessment in it.
There are 16 of them, and the honest answer is that most organisations need two or three rather than all of them. Tell us what you run and what you are being asked to prove.