Who may read or change source code, software libraries and development tools is to be properly managed. Purpose: stop unauthorized functionality being introduced, prevent accidental or malicious changes and keep valuable intellectual property confidential. Guidance: strictly control access to source code and related items such as designs, specifications and verification and validation plans, and to development tooling including compilers, build and integration tools, and test platforms and environments. For source code, control its central storage, preferably in a source code management system. Read and write access can differ by role: read access may be broad within the organization while write access goes only to privileged staff or designated owners; shared code components should be read from a central repository; open source or third-party repositories may be widely readable but write access stays restricted. To reduce the chance of corrupting programs, consider managing access to source code and source libraries through established procedures; granting read and write access by business need, managed against the risk of alteration or misuse; updating code and related items, and granting access, only under change control (8.32) and after proper authorization; giving developers access through developer tools that control their actions and authorizations rather than directly to the repository; keeping program listings somewhere secure with managed access; and keeping an audit log of all access and changes to source code. If code is to be published, consider added integrity assurance such as a digital signature. Other information: poorly controlled access lets code be altered or lets unauthorized people retrieve development environment data such as production data copies or configuration details.
This control maps to 36 controls across 16 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
ISO 27002:2022 8.4 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of ISO 27002:2022 your existing evidence covers. Hold NIST SP 800-53 Rev 5 and 79 of 93 ISO 27002:2022 controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 180 were rejected on the NIST SP 800-53 Rev 5 pair alone.
The graph holds this control, the 36 it maps to, and the evidence behind each claim, over MCP and REST.