A.8.4 Technological
Access to source code
AttributesPreventiveC·I·AProtectIdentity and access managementApplication securitySecure configurationProtection
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
The implementation guidance for this control is published in
ISO/IEC 27002:2022
and is not reproduced here. The structured attributes and the cross-walk
rationales below are derived facts and our own AI-authored analysis.
Mapped NIST 800-53 r5 controls (17)
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.
- CM-5partialcovers — A.8.4's narrow focus on source-code access restrictions addresses only a slice of CM-5's broader requirement to restrict all physical/logical changes to the entire system
- AC-3covers — Assessed as NOT holding by the authoring instrument at v1.19-2026-08-23. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- AC-6covers — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
Aligned NIST CSF 2.0 outcomes (18)
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.
- ID.AM-08implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- PR.AA-01implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- PR.AA-05implements — A.8.4's technical requirement to control (restrict) access to source code directly operationalizes the management and enforcement of access permissions within PR.AA-05's governance outcome, reaching it through the shared access-control domain even though the CSF outcome does not name source code specifically
- PR.PS-01implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- PR.PS-04implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
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 (17)
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-282nonemitigates — Access to source code control depends on proper ownership assignment to protect intellectual property.
- CWE-284prevents — 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-285mitigates — 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-511prevents — Restricting access to source code limits opportunities for insiders to plant logic/time bombs.
- CWE-527prevents — Explicit control of source-code access directly mitigates exposure of version-control repositories.
- CWE-540mitigates — Directly restricts access to source code, preventing exposure of embedded sensitive information.
- CWE-541mitigates — Restricting access to source code prevents unauthorized retrieval of include files that contain credentials.
- CWE-615mitigates — Restricting access to source code reduces the chance that sensitive comments are exposed to unauthorized readers.
- CWE-732prevents — 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-862prevents — Mandatory authorization checks before allowing modifications ensure that every sensitive action on source code is preceded by an explicit access-control decision.
- CWE-912mitigates — Access to source code controls who can view code but does not guarantee detection of hidden functionality.
Mitigated MITRE ATT&CK techniques (219)
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).
T1006←MT1027.001←MT1027.002←MT1027.004←MT1027.006←MT1027.007←MT1027.008←MT1027.009←MT1027.010←MT1027.011←PT1027.014←MT1027.016←MT1027.017←PT1027.018←MT1036←MT1036.002←MT1036.003←MT1036.005←MT1036.008←MT1036.009←MT1037.004→PT1055←MT1055.001←MT1055.002←MT1055.003←MT1055.004←MT1055.005←MT1055.008←MT1055.009←MT1055.011←MT1055.012←MT1055.013←MT1055.014←MT1055.015←MT1068←MT1070.003←MT1070.006←MT1070.010←MT1078←PT1080←M →PT1098.006←MT1127←M →PT1127.001←MT1127.003←M →PT1133←MT1134←MT1134.001←MT1134.002←MT1134.003←MT1134.004←PT1137.001→PT1137.006→PT1176.002←M →PT1195←M →MT1195.001←M →PT1195.002←M →PT1202←MT1203→PT1204.004←MT1204.005←M →PT1207←MT1211←PT1213←M →PT1213.001←P →PT1213.002→PT1213.003←M →MT1216←MT1218←MT1218.003←MT1218.004←MT1218.005←MT1218.007←MT1218.008←MT1218.009←MT1218.010←MT1218.011←MT1218.012←MT1218.013←MT1219.001←MT1219.003←PT1220←MT1221←MT1222←MT1222.001←MT1222.002←MT1480.001←MT1484←MT1484.001→PT1484.002←MT1497←MT1505→PT1505.003→PT1535←MT1537←MT1539←MT1542←MT1542.002←MT1542.003←MT1543.002→PT1546.004→PT1546.006←PT1546.012←PT1546.017→PT1547.006→PT1548.001←PT1548.003←PT1548.006←MT1550←MT1550.001←MT1550.002←FT1550.003←MT1550.004←FT1552.001→PT1553←PT1553.001←MT1553.002←PT1553.003←MT1553.004←PT1553.005←MT1553.006←MT1554←M →PT1556←MT1556.001←PT1556.003→PT1556.005←PT1556.007←PT1556.009←MT1564.004←MT1565→PT1565.001→PT1565.003→PT1567.001←M →PT1571←MT1574←MT1574.001←M →PT1574.004←MT1574.005←MT1574.006←MT1574.008←P →PT1574.010←MT1574.013←MT1578←MT1578.001←MT1578.002←MT1578.003←MT1578.004←MT1578.005←PT1599←MT1600←MT1601.001←M →PT1601.002←MT1606.001←FT1610←PT1611←MT1612←MT1620←MT1622←MT1647←PT1666←PT1677←M →PT1678←PT1684←MT1685←MT1685.002←MT1685.004←MT1687←PT1688←MT1689←P
Why these map — AI rationale (under review)
- T1037.004prevents — A.8.4 strictly controls read/write access to source code, associated items, and development tools (including via SCM, role-based privileges, change control, and audit logs), which prevents unauthorized modification of RC scripts when they are treated as managed source in the development or build pipeline, but leaves the runtime modification vector (direct root-level edits on deployed Unix-like systems) untouched.
- T1080detects — A.8.4.f explicitly requires maintaining an audit log of all accesses and changes to source code, which would surface adversary writes that taint shared/internal code repositories (a core vector of T1080); this is genuine detection but only a slice, as the control is silent on network drives, binary infection of non-source artifacts, directory-share pivots, and non-repository shared storage.
- T1080prevents — A.8.4 strictly controls read/write access to source code and repositories (via roles, change procedures, no direct dev access, audit logs), which stops adversaries from adding/tainting malicious content in internal code repositories — a core vector named in T1080 — but leaves network drives, binary infections on non-source shared storage, and directory-share pivots untouched.
- T1127prevents — A.8.4's strict access controls on source code, dev tools, and repositories (read/write separation by role, no direct repo access for devs, change-control gating) directly constrain the availability and abuse surface of the very trusted developer utilities that T1127 relies on for proxy execution, but only for in-house or managed components; it does not reach third-party signed utilities, LOLBAS-style binaries already present on endpoints, or runtime abuse after the utilities are installed.
- T1127.003detects — A.8.4 mandates audit logging of all accesses and changes to source code and development tools (including build utilities like JamPlus), which surfaces abuse of the tool for malicious .jam execution; this is genuine detection but only a slice, as the control is scoped to source-code and build-tool repositories rather than runtime process or script execution monitoring.
- T1127.003prevents — A.8.4's strict controls on read/write access to source code, central SCM, role-based privileges, change-control gating and developer-tool mediation directly stop adversaries from introducing or altering a malicious .jam build file that would be executed by JamPlus, but leave open the possibility of abusing a legitimate pre-existing .jam or JamPlus installation that was already present.
- T1137.001prevents — A.8.4's strict access controls on source code, libraries, and change procedures can prevent malicious insertion of VBA macros into templates when those templates are managed as source-controlled intellectual property, but this is only a slice — the technique routinely targets user-writable Office files outside any central repository, registry hijacks, search-order abuse, and non-developer endpoints.
- T1137.006prevents — A.8.4's strict access controls on source code, libraries, repositories, and change procedures (including developer-tool mediation and audit logging) prevent unauthorized addition or modification of add-in code that would enable the persistence technique, but this is only a slice: the technique can also be realized via registry changes, file drops, or configuration of already-trusted add-ins without touching protected source.
- T1176.002prevents — A.8.4's strict controls on read/write access to source code, libraries, and development tools (including via SCM, role-based restrictions, change control, and no direct repo access) directly constrain the ability to introduce or side-load malicious IDE extensions that abuse the development environment, but do not address marketplace-installed extensions, benign extension abuse for tunneling, or post-install execution.
- T1195prevents — 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.
- T1195.001prevents — A.8.4 strictly controls read/write access to an organization's own source code, libraries, and development tools (including via SCM, role-based permissions, change control, and audit logs), which directly stops many insider or local manipulations of those items before they reach consumers, but leaves the dominant external/open-source dependency and typosquatting vectors named in T1195.001 untouched.
- T1195.002prevents — A.8.4's strict controls on read/write access to source code (via SCM, role-based permissions, change procedures, and audit logs) directly block unauthorized manipulation of application source code — one of the three named vectors in T1195.002 — but do not address manipulation of update/distribution mechanisms or replacement of compiled releases.
- T1203prevents — A.8.4's strict access controls, change procedures, and developer-tool mediation on source code and libraries directly reduce the chance that unsecure coding practices introduce the exploitable vulnerabilities that T1203 relies on, but this is only a slice: many client-application vulnerabilities arise in third-party binaries, closed-source components, or non-source artifacts outside the clause's reach.
- T1204.005prevents — A.8.4's strict controls on read/write access, centralized SCM, role-based permissions, change-control gating and audit logging for source code and libraries directly constrain the upload/backdooring of malicious libraries into internal or organizational repositories, but do not reach public package managers (NPM/PyPI), open-source ecosystems or typosquatting that the technique primarily exploits.
- T1213prevents — A.8.4 strictly controls read/write access to source code and development tools (including via SCM, role-based permissions, change control, and audit logs), which directly stops adversaries from mining source code snippets or related IP from code repositories — a named slice of T1213 — but leaves the bulk of other repository types (SharePoint, Confluence, CRM, Slack, cloud DBs) and non-code data untouched.
- T1213.001prevents — A.8.4 strictly controls read/write access to source code (and associated items like designs/specs) via centralized SCM, role-based permissions, change control, and audit logs, which directly stops adversaries from mining source code snippets or related dev artifacts in a Confluence repository; it does not address the broader non-code categories (policies, diagrams, credentials, schedules) that also make the technique valuable.
- T1213.002prevents — A.8.4 strictly controls read/write access to source code (and associated items like designs/specifications) via centralized repositories, role-based permissions, change procedures, and audit logs, which directly stops adversaries from mining source code snippets (and some related technical docs) from a SharePoint repository; it does not address the other listed items such as policies, network diagrams, credentials, or schedules.
- T1213.003prevents — A.8.4's strict access controls (read/write separation, centralized SCM, role-based grants, no direct repo access for devs, audit logging) directly stop adversaries from reaching and collecting from private/internal code repositories once inside the victim network, which is the core of T1213.003; the bounded remainder is third-party/external SaaS repos where the organization has no enforcement power.
- T1484.001prevents — A.8.4 strictly controls read/write access to source code and development tools (via central SCM, role-based permissions, change control, audit logs) which reaches the slice of GPO abuse that modifies policy files inside SYSVOL when those files are treated as managed source; the bulk of the technique (AD delegation, GPO permissions on non-source objects, runtime modification of deployed policies) sits outside source-code access controls.
- T1505prevents — A.8.4's strict role-based access controls, change procedures, and audit logging on source code and development tools directly block unauthorized installation of malicious server components in first-party or managed codebases, but do not constrain third-party server extensions, published components, or runtime abuse of already-installed legitimate extensibility features on production systems.
- T1505.003prevents — strict access controls and change procedures on source code and dev tools can stop an adversary-placed web shell script from being introduced or altered in the legitimate codebase, but do not block direct filesystem writes to a deployed web server's document root or other runtime locations where the technique actually occurs
- T1543.002prevents — A.8.4 strictly controls read/write access to source code, associated items, and development tools (including via SCM, role-based permissions, change control, and audit logs) to prevent unauthorized functionality or malicious changes, which reaches the creation/modification of .service files or generators when they are treated as source or developed artifacts but leaves the bulk of the technique (altering deployed unit files in /etc/systemd or $HOME, placing symlinks, or using non-source generators) outside its scope.
- T1546.004prevents — A.8.4 strictly controls read/write access to source code, associated items, and development tools (including via SCM, role-based privileges, change control, and no direct repo access), which prevents unauthorized insertion of malicious commands into shell config files when those files are treated as source code or managed through the controlled development toolchain; this covers the developer-introduced and many system-level cases but leaves a bounded remainder (adversary abuse of existing user-level dotfiles or post-deployment configs outside the dev process).
- T1546.017prevents — A.8.4's strict access controls on source code, libraries, and change procedures (including no direct repo access for developers) would prevent unauthorized addition/modification of udev rules if those rules are managed as source-controlled configuration in /lib/udev/rules.d/ or similar, but this is only a slice — many udev rules are deployed via packages or live root-level edits outside source management, and the control does not reach runtime or non-source persistence vectors.
- T1547.006prevents — A.8.4 strictly controls read/write access to source code, associated items, and development tools (including via SCM, role-based privileges, change control, and audit logs) to prevent unauthorized or malicious changes; this reaches the slice of T1547.006 where an adversary (or insider) must introduce or alter LKM/kext source before loading, but leaves the bulk untouched — loading already-compromised/signed modules, runtime injection, or non-source vectors such as kextload of pre-built binaries.
- T1552.001prevents — strict access controls on source code and development tools (read/write separation, SCM, change control, no direct repo access) stop credentials from being embedded in source or left in associated items, directly blocking the source-code/binary-files slice of the technique; this is only a minority slice of the class (user files, config files, credential stores, container logs, backups, GPP, etc. remain untouched)
- T1554prevents — A.8.4 strictly controls read/write access to source code and development tools (via SCM, role-based permissions, change control, and audit logs) to block unauthorized modifications that could introduce malicious functionality into binaries built from that source, but it does not address post-build binary patching, replacement of deployed host binaries, or prevention on platforms where binaries are not rebuilt from controlled source.
- T1556.003prevents — A.8.4 strictly controls read/write access to source code, libraries, and development tools (including via SCM, role-based grants, change control, and audit logs) which directly stops many unauthorized modifications to PAM components such as pam_unix.so when those components are built or maintained as in-house source; it does not reach pre-compiled third-party PAM modules, configuration files, or runtime binary patching that the technique also uses.
- T1565prevents — A.8.4 strictly controls read/write access to source code, libraries, and development tools (via SCM, role-based permissions, change control, and no direct repo access), which prevents adversaries from gaining the specialized access needed to insert/delete/manipulate data in source or build artifacts for T1565; this covers only the development-time slice of the technique, leaving runtime data manipulation (e.g. in databases or applications) untouched.
- T1565.001prevents — A.8.4 strictly controls read/write access to source code, associated items, and development tools (via SCM, role-based permissions, change control, and audit logs), which directly stops unauthorized insertion/deletion/manipulation of source and related stored data at rest; this is only a slice of T1565.001, which broadly covers any stored data (databases, Office files, emails, custom formats) on any platform.
- T1565.003prevents — A.8.4 strictly controls read/write access to source code, libraries, and development tools (via SCM, role-based grants, change control, and no direct repo access), which prevents unauthorized modification of application binaries or related components that could enable runtime data manipulation at build time; this covers only the development-origin slice of the technique, leaving post-deployment binary alteration, runtime memory patching, file-association changes, and masquerading untouched.
- T1567.001detects — A.8.4 explicitly requires maintaining an audit log of all accesses and changes to source code (including to central repositories), which surfaces anomalous or unauthorized exfiltration activity to a code repo when that activity touches managed source-code assets.
- T1567.001prevents — A.8.4 strictly controls read/write access to source code and repositories (including via roles, change procedures, and developer tools), which stops most legitimate insiders and many external actors from being able to push/exfiltrate data to a code repo, but leaves open the possibility of stolen credentials, misconfigured public repos, or external third-party repo abuse that the control does not address.
- T1574.001prevents — strict access controls and change-management procedures on source code and development tools reduce the chance that an adversary (or insider) can introduce or substitute a malicious DLL into a build or repository, but the control does not reach runtime search-order hijacking, sideloading of already-deployed binaries, or phantom DLL planting outside the development environment
- T1574.008prevents — strict access control to source code and development tools (including change procedures and audit logs) prevents malicious insertion of hijackable binaries into source-managed or build directories, but leaves runtime search-order hijacking of unsigned third-party or system binaries untouched
- T1601.001prevents — A.8.4 strictly controls read/write access to source code, associated items, and development tools (including via SCM, role-based access, change control, and audit logs) to prevent unauthorized functionality or malicious changes; this reaches the source-code and dev-tool slice of T1601.001 but leaves the dominant remainder (admin-level debug commands, boot-loader/ROMMON manipulation, in-memory patching of a running monolithic firmware image on a network device) untouched.
- T1677prevents — A.8.4 strictly controls read/write access to source code, associated items, and development tools (including via SCM, role-based grants, change-control gating, and indirect tool-mediated access), which directly stops the Direct and Indirect Pipeline Execution scenarios that require repository modification; it reaches none of the Public Pipeline Execution scenarios that rely on external forks, pull-request triggers, or self-hosted runners.
Prevented OWASP Web Top 10 (2025) risks (4)
OWASP Web Top 10 (2025) risk categories 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)
- A01mitigates — strict access controls on source code (read/write separation, change procedures, audit logs) limit the ability of unauthorized insiders to introduce or exploit broken-access-control defects in the resulting application, but do nothing once the flaw ships or for external attacker bypasses
- A01prevents — A.8.4 strictly controls read/write access to source code and development tools per roles and change procedures, which prevents many Broken Access Control defects (e.g. missing function-level checks, IDOR via improper authorization in code) from being introduced during development; it does not address runtime enforcement failures, path traversal outside source, or CSRF.
- A08mitigates — strict access controls and change-management on source code (plus audit logs and signatures on published code) bound the blast radius and reduce the chance of realizing an integrity failure via unauthorized alteration or CI/CD paths, but do not address the realized weakness itself (e.g. missing verification on deserialization or unsigned updates)
- A08prevents — A.8.4's strict access controls on source code and libraries (read/write separation, change control, no direct repo access, audit logs) directly block unauthorized or malicious modifications that introduce integrity failures, covering several members of A08 such as unsigned updates and CI/CD compromise paths, but not all (e.g. insecure deserialization of untrusted data).
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.