ASD ISM 2024 Utilise authoritative sources in software development
What it says
The authoritative source for software is used for all software development activities.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUse only official sources for all software development tasks to ensure accuracy and reliability.
When developing software, it's crucial to use official and trusted sources to avoid errors and ensure safety. This is important because relying on unofficial sources can lead to software bugs, data breaches, or other technical issues that might harm your business or customer's trust.
Free. Save your status, tasks and notes.
Why it matters
Using non-authoritative sources can introduce malicious code or defective components into builds, undermining software integrity and user trust.
How to implement
The software development team should create a checklist of approved sources: This ensures that all members know which repositories, libraries, and tools are considered reliable and secure.
They can do this by conducting research on trusted sources as recommended by the Australian Cyber Security Centre (ACSC).
IT leaders should provide training for developers: Regularly update your team on how to identify authoritative sources.
This includes recognising certificates from software vendors and understanding endorsement from trusted industry bodies.
Procurement staff should verify software sources before purchase: They need to check that software comes from a verified vendor who follows security best practices.
This can involve looking for vendor accreditations or partnerships with reputable organisations like the Australian Signals Directorate (ASD).
Project managers should conduct regular audits: Set up periodic reviews where team members verify that the adopted software and updates come from the documented authoritative sources.
Use a simple checklist to ensure compliance with the official list.
Security officers should monitor for deviations: Implement software that alerts when non-authorised sources are used.
This can involve setting filters or alerts on the company's network to flag installations from underestimated or unknown sources.
Keep it running
Maintain an approved list of authoritative repositories and vendor sites, and periodically revalidate access paths, signatures and ownership to avoid compromised or stale sources.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A list of approved software sources: This document should detail each source considered trustworthy by the organisation.
Look at
Updates to this list and endorsements or guidelines from the Australian Cyber Security Centre.
Good evidence
Consists of a dated, detailed list with ACSC guidelines applied.
- Check 2 of 5What an auditor asks for
Look at
Attendance records and updated training materials.
Good evidence
Includes a roster of trained staff and an outline of the session.
- Check 3 of 5What an auditor asks for
Ask for
Procurement records of recent software purchases: Ensure these documents indicate that only approved vendors were used.
Look at
Vendor approvals and check they align with the authorised sources list.
Good evidence
Provides consistent records with authoritative source verification.
- Check 4 of 5What an auditor asks for
Look at
Documented decisions and action items.
Good evidence
Will have clear action points for maintaining approved software sources.
- Check 5 of 5What an auditor asks for
Ask for
Logs from the software monitoring tools: Verify that these logs show alerts for any deviations from authorised sources.
Look at
Consistent logs and alerts for any unauthorised activities.
Good evidence
Includes dated logs with actions taken to resolve any issues.
Mappings
Closest match in ISO/IEC 27001: A.8.4, Access management for source code and tools, which this control depends on.
ISO/IEC 27001: 1 mapping
This control depends on A.8.4.
Annex A 8.4 requires organisations to manage access to source code, development tools and software libraries, including controlling where and how these assets are obtained and used. ISM-2024 supports this by requiring use of an authoritative source for software development activities, which complements access management by limiting who can introduce or consume code and libraries from untrusted locations. ISM-2024 is focused on supply/source integrity rather than permissioning, so it is complementary rather than overlapping in scope.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.