Prevent Unauthorised Changes to Software Sources
Ensure software source is protected against unauthorised changes to maintain integrity.
Plain language
This control is about making sure that only the right people can change or update the source of the software your business uses. If just anyone can tamper with it, you might end up with untrustworthy software that could affect everything your business does, leading to financial loss or damaging your reputation.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Nov 2022
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
Unauthorised modification of the authoritative source for software is prevented.
Why it matters
If the authoritative software source can be modified, attackers can inject code into builds, compromising released software and systems that deploy it.
Operational notes
Restrict write access to authoritative repos; enforce signed commits/tags and protected branches; require peer review and verify changes before merge.
Implementation tips
- System owners should ensure that access permissions to the software source are tightly controlled. This can be done by regularly reviewing who has access and removing anyone who no longer needs it. Use a simple list or tool to track this access.
- The IT team should implement version control systems to manage software updates. This involves clearly tracking changes made to the software, who made them, and ensuring only authorised individuals can apply updates.
- Managers should establish a clear policy on software changes. This means writing down rules that say only approved changes can be made, and that these changes must be documented and reviewed.
- Procurement officers should ensure third-party software sources are verified and trustworthy before any purchase. Check that vendors provide evidence of integrity and security practices, such as certifications or audits.
- The IT team should implement automated alerts for any unauthorised attempts to change the software source. Use tools that notify the team in real-time if unapproved actions are attempted or if there are unusual activities.
Audit / evidence tips
- AskA list of individuals with access to software source code: Request documentation of all current access permissions GoodShows a dated, regularly reviewed list with justifiable access roles
- AskTo see the change management policy: Request a copy of the policy that governs software updates and changes GoodIs a clear policy document that's dated and used in practice
- AskLogs from the version control system: Request logs that show who's made changes and when GoodHas timestamps, user identification, and shows regular review
- AskDocumentation on any third-party software audits: Request proof of vendor security certifications or audit results GoodIncludes current and thorough certification records
- AskReports on unauthorised access attempts: Request the IT team’s reports on any alerts triggered by attempted tampering GoodShows resolved alerts with explanations and timestamps
Cross-framework mappings
How ISM-1816 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| handshake Supports (4) expand_less | ||
| Annex A 5.15 | ISM-1816 requires controls to prevent unauthorised changes to the authoritative source for software | |
| Annex A 8.3 | ISM-1816 requires that the authoritative software source, such as source code repositories and release artefacts, is protected to prevent... | |
| Annex A 8.31 | ISM-1816 requires protecting the authoritative software source from unauthorised modification | |
| Annex A 8.32 | ISM-1816 is concerned with preventing unauthorised changes to the authoritative software source to maintain integrity | |
E8
| Control | Notes | Details |
|---|---|---|
| handshake Supports (1) expand_less | ||
| E8-MF-ML2.1 | ISM-1816 requires preventing unauthorised modification of the authoritative software source | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.