The ultimate audit guide to ISO 27001 Annex A 8.4 Access To Source Code
Table of contents
- 1. Source Code Access Policy Formalisation Verified
- 2. Repository Access Control Integrity Confirmed
- 3. Multi-Factor Authentication (MFA) for VCS Enforced
- 4. Least Privilege Branch Protection Validated
- 5. External Contractor Access Segregation Verified
- 6. Source Code Extraction and Export Restrictions Confirmed
- 7. Personal Identity Provider (IdP) Integration Validated
- 8. Audit Logging of Repository Activity Verified
- 9. Removal of Hardcoded Credentials Confirmed
- 10. Periodic Access Rights Review Records Present
1. Source Code Access Policy Formalisation Verified
Verification Criteria: A documented policy exists defining the strict ‘need-to-know’ requirements and authorisation levels for accessing program source code.
Required Evidence: Approved Secure Coding Policy or Version Control Access Standard with defined developer roles.
Pass/Fail Test: If the organisation cannot produce a formal policy restricting source code access to specific authorised personnel, mark as Non-Compliant.
2. Repository Access Control Integrity Confirmed
Verification Criteria: Access to Version Control Systems (VCS) is restricted to authorised developers only, with no public or unauthenticated access allowed.
Required Evidence: Repository settings from GitHub, GitLab, or Bitbucket showing ‘Private’ status and a list of active authorised collaborators.
Pass/Fail Test: If any production repository is found set to ‘Public’ or accessible without unique user authentication, mark as Non-Compliant.
3. Multi-Factor Authentication (MFA) for VCS Enforced
Verification Criteria: All developer accounts with access to the source code repository are required to use Multi-Factor Authentication for login.
Required Evidence: MFA enforcement reports from the VCS provider showing 100% compliance across all developer seats.
Pass/Fail Test: If the organisation permits developers to access the code repository using only a username and password, mark as Non-Compliant.
4. Least Privilege Branch Protection Validated
Verification Criteria: Protection rules are active on primary branches (e.g. main, master, production) to prevent direct pushing and require peer review.
Required Evidence: Branch protection rule configurations in the VCS showing mandatory pull request (PR) approvals and blocked force-pushes.
Pass/Fail Test: If a developer can unilaterally push code directly to the production branch without a second-party review, mark as Non-Compliant.
5. External Contractor Access Segregation Verified
Verification Criteria: Third-party developers or contractors are restricted to specific sub-repositories or branches relevant only to their assigned tasks.
Required Evidence: Access control list (ACL) showing contractors are excluded from core repositories or highly sensitive internal projects.
Pass/Fail Test: If a contractor is granted ‘Owner’ or global ‘Admin’ rights to the entire organisation’s code portfolio, mark as Non-Compliant.
6. Source Code Extraction and Export Restrictions Confirmed
Verification Criteria: Technical controls or documented procedures are in place to prevent the unauthorised download or extraction of the code base to personal devices.
Required Evidence: Data Loss Prevention (DLP) logs, MDM configurations, or signed agreements prohibiting local code storage on unmanaged hardware.
Pass/Fail Test: If developers can clone the entire production repository onto a personal, unencrypted device without technical restriction or audit, mark as Non-Compliant.
7. Personal Identity Provider (IdP) Integration Validated
Verification Criteria: Access to the code repository is integrated with the corporate Identity Provider to ensure immediate access revocation upon termination.
Required Evidence: SSO (Single Sign-On) or SCIM configuration connecting the VCS to the corporate directory (e.g. Okta, Azure AD).
Pass/Fail Test: If the VCS uses standalone local accounts not linked to the central IdP, allowing access to persist after HR termination, mark as Non-Compliant.
8. Audit Logging of Repository Activity Verified
Verification Criteria: All administrative changes, access events, and code extractions are recorded in an immutable audit log.
Required Evidence: Export of VCS audit logs showing events such as ‘Repository Created’, ‘User Added’, and ‘Code Downloaded’.
Pass/Fail Test: If the organisation cannot produce an audit trail of who accessed or modified repository permissions in the last 90 days, mark as Non-Compliant.
9. Removal of Hardcoded Credentials Confirmed
Verification Criteria: Technical scanning tools are utilised to ensure that source code does not contain hardcoded secrets, keys, or passwords.
Required Evidence: Reports from Secret Scanning tools (e.g. GitHub Secret Scanning, GitGuardian) showing zero active high-risk secrets in the code.
Pass/Fail Test: If a manual or automated check reveals plain-text API keys or DB passwords within the code repository, mark as Non-Compliant.
10. Periodic Access Rights Review Records Present
Verification Criteria: Management performs a formal review of repository access rights at regular intervals (e.g. quarterly) to prune unnecessary access.
Required Evidence: Documented Access Review meeting minutes or signed reports cross-referencing repository users against active projects.
Pass/Fail Test: If there is no evidence of a formal review of developer access rights in the last six months, mark as Non-Compliant.
About the author
