ASD ISM 2029 Restrict third-party libraries to trustworthy sources
What it says
The authoritative source for software restricts the use and import of third-party libraries and software components to trustworthy sources.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishOnly use third-party libraries from reliable sources to ensure software security.
This control is about ensuring that the software your business uses is safe by only including parts from reliable and trustworthy sources. If you include software components from untrustworthy sources, your systems could become vulnerable to hackers, potentially leading to data theft or financial loss.
Free. Save your status, tasks and notes.
Why it matters
Using untrusted third-party libraries can introduce vulnerable or malicious code, enabling supply-chain compromise of applications and systems.
How to implement
Procurement team should verify the reputation of third-party library sources before purchase.
Check for customer reviews, history of security issues, and certifications that prove reliability.
IT team should create a list of approved third-party library sources.
Regularly update this list and ensure that every purchase checks against it to maintain software security.
Management should establish a policy that defines what constitutes a trustworthy source for third-party libraries.
Ensure that all staff involved in software acquisition and development understand and follow this guideline.
System developers should review existing software components and ensure they come from reliable sources.
Remove or replace any libraries from unapproved or questionable sources to minimise risk.
Conduct regular training sessions for software developers to recognise trustworthy sources.
Use real-world examples of good and bad sources to help them make informed decisions.
Keep it running
Use an allowlist of approved libraries/registries, require integrity checks (hash/signature), and review advisories/updates for each trusted source.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The list of approved third-party library sources. Look to see if it covers all software types used by the organisation.
Good evidence
A well-documented list showing trusted sources and evidence it's regularly updated.
- Check 2 of 5What an auditor asks for
Look at
How specific and clear the criteria are.
Good evidence
A policy that aligns with security best practices and is accessible to all staff.
- Check 3 of 5What an auditor asks for
Ask for
Records of software components currently in use.
Look at
References to their source and any checks/validations they've undergone.
Good evidence
Detailed records showing components and their verified origins.
- Check 4 of 5What an auditor asks for
Look at
How often training is conducted and what content it covers.
Good evidence
Regular, thorough training sessions documented with attendance and materials.
- Check 5 of 5What an auditor asks for
Ask for
The minutes from recent software review meetings.
Look at
Discussions on third-party components and their sources.
Good evidence
Meeting records showing active reviews and decisions on library use.
Mappings
Closest match in ISO/IEC 27001: A.5.21, Managing information security in the ICT supply chain, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.5.21.
ISM-2029 requires the authoritative source for software to restrict the use and import of third-party libraries and software components to trustworthy sources. Third-party components are part of the ICT supply chain, so this directly implements supply chain risk management for software as required by Annex A 5.21. Annex A 5.21 covers risks across all ICT products and services, whereas ISM-2029 addresses only the provenance of software components.
This control partially meets A.8.25.
ISM-2029 requires the authoritative source for software to restrict the use and import of third-party libraries and components to trustworthy sources. This is a specific secure development rule that would sit within the rules for secure development of software and systems required by Annex A 8.25. Annex A 8.25 covers the whole secure development life cycle, while ISM-2029 addresses only the sourcing of third-party components.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.