A.8.4 Technological
Access to source code
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
Mapped NIST 800-53 r5 controls (11)
Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- AC-3mostlyaligns with — Both controls enforce access decisions on a protected resource (source code vs. system objects) according to defined rules and authorizations.
- AC-6mostlyaligns with — Both require that write access to source code be limited to the minimum set of privileged roles needed to perform authorized changes.
- CM-5mostlyaligns with — Both restrict who may modify source code or configuration items and require authorization before changes are applied.
- AU-2partialaligns with — Both mandate logging of accesses and modifications to source code to support accountability and detection of unauthorized activity.
- CM-3partialaligns with — Both tie source-code changes to formal change-control procedures that include authorization and tracking.
Aligned NIST CSF 2.0 outcomes (10)
NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- PR.AA-05mostlyaligns with — The ISO control enforces role-based read/write distinctions and authorization gates on source code assets, directly supporting the CSF outcome of defining, managing, and reviewing access permissions and entitlements.
- ID.AM-08partialaligns with — Treating source code and its associated development artifacts as managed assets throughout their lifecycle is consistent with the CSF outcome of managing systems, software, and data across their life cycles.
- PR.AA-01partialaligns with — By restricting write access to privileged personnel and routing developer interactions through controlled tools, the control contributes to the management of identities and credentials for authorized users and services.
- PR.PS-01partialaligns with — Requiring change-control procedures, authorization, and audit logging for source-code modifications aligns with the CSF outcome of establishing and applying configuration-management practices.
- PR.PS-04partialaligns with — Mandating an audit log of all accesses and changes to source code supports the generation of log records that enable continuous monitoring.
Related OWASP ASVS 5.0 requirements (5)
Application-security verification requirements (OWASP ASVS 5.0) this ISO control aligns with; links open the ASVS chapter. Our AI-authored analysis (authority llm_unverified, under review) — many ISO controls have no ASVS counterpart.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- V15.2.4mostlyaligns with — The ISO control's requirement to restrict write access to source code repositories and route developer changes through controlled tooling directly supports the ASVS requirement that third-party and internal components must be obtained only from expected, authorized sources.
- V13.2.4partialaligns with — By mandating an allow-list approach for who may read or write source code and associated development artifacts, the control implements the same objective as the ASVS rule that external or internal resources must be explicitly permitted before communication or access occurs.
- V13.3.2partialaligns with — Granting read versus write privileges strictly according to business need and role implements the principle of least privilege for access to critical security assets, matching the intent of the ASVS secret-management requirement.
- V15.1.2partialaligns with — Centralized control and versioning of source code and its related artifacts supports the maintenance of an accurate inventory of all components used by the application, which is the core objective of the ASVS SBOM-style requirement.
- V16.2.1partialaligns with — Requiring an audit log of every read or write access to source code fulfills the ASVS logging requirement that each log entry must capture the essential metadata (who, what, when, where) needed for later investigation.
Related weaknesses / CWE (24)
Weakness classes this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- CWE-527fullprevents — Explicit control of source-code access directly mitigates exposure of version-control repositories.
- CWE-284mostlyprevents — Strict role-based read/write controls on the central source repository directly stop unauthorized actors from reaching or altering code, which is the root of improper access control.
- CWE-732mostlyprevents — Enforcing differentiated permissions on the source-code repository and program listings stops the assignment of overly broad default or inherited permissions to critical resources.
- CWE-285partialmitigates — Requiring explicit authorization and change-control procedures before any write operation prevents the system from performing actions that the subject is not entitled to perform on the source.
- CWE-511partialprevents — Restricting access to source code limits opportunities for insiders to plant logic/time bombs.
- CWE-540partialmitigates — Directly restricts access to source code, preventing exposure of embedded sensitive information.
- CWE-541partialmitigates — Restricting access to source code prevents unauthorized retrieval of include files that contain credentials.
- CWE-615partialmitigates — Restricting access to source code reduces the chance that sensitive comments are exposed to unauthorized readers.
- CWE-862partialprevents — Mandatory authorization checks before allowing modifications ensure that every sensitive action on source code is preceded by an explicit access-control decision.
- CWE-912partialmitigates — Access to source code controls who can view code but does not guarantee detection of hidden functionality.
- CWE-1191nonenone — Source-code protection is only tangentially related to hardware debug access.
- CWE-1244nonenone — Source code access control is only tangentially related to hardware debug access misconfiguration.
- CWE-269nonenone — Limiting write access to only privileged personnel or designated owners reduces the chance that excessive privileges will be granted to developers who should not hold them.
- CWE-282nonemitigates — Access to source code control depends on proper ownership assignment to protect intellectual property.
- CWE-471nonenone — Restricting source-code access reduces the chance an attacker can alter constants or configuration treated as immutable.
- CWE-767nonenone — Limiting source-code access reduces opportunity for attackers to discover the public method.
- CWE-778nonenone — Requiring an audit log of all repository accesses and changes supplies the evidence needed to detect and respond to unauthorized or malicious activity after the fact.
- CWE-913nonenone — Source code access restriction limits who can introduce dynamic code but does not govern its runtime behavior.
Mitigated MITRE ATT&CK techniques (5)
Adversary techniques (MITRE ATT&CK Enterprise) this ISO control helps mitigate; links open attack.mitre.org. Our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- T1195mostlyprevents — Restricting write access to source code repositories and requiring change-control authorization reduces the likelihood that an adversary can insert malicious code into the organization's software supply chain.
- T1078partialmitigates — Role-based access rules and the requirement for explicit authorization before granting write privileges to source code limit the misuse of any compromised developer or privileged accounts.
- T1554partialmitigates — Limiting direct developer access to source repositories and enforcing tool-mediated check-ins makes it harder for an attacker to compromise host binaries by modifying the original source.
- T1587partialmitigates — By enforcing strict read/write separation and audit logging on source libraries, the control reduces the opportunity for an attacker to develop or modify malware within the organization's own code base.
- T1608nonemitigates — Centralized, access-controlled storage of source code and associated artifacts limits an adversary's ability to stage or upload malicious code into the organization's build pipeline.
Control IDs, short titles and the structured attribute table (control type, CIA properties, cybersecurity-concept, operational capability, security domain) are facts from ISO/IEC 27001:2022 Annex A / ISO/IEC 27002:2022. The full implementation guidance prose lives in ISO/IEC 27002:2022 — not reproduced here. Cross-walks to NIST 800-53, NIST CSF 2.0, OWASP ASVS, CWE, MITRE ATT&CK and OWASP Web Top 10 are our own AI-authored analysis (authority llm_unverified, under review), not an ISO, NIST, MITRE or OWASP product — how ours compare.