ASD ISM 2154 Pinning software artefact dependencies to approved versions in source code
What it says
Software artefact dependencies are pinned to approved versions in source code.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEvery third-party library or component a build pulls in is locked to an exact version your organisation has approved, and that lock is recorded in the source code itself.
When developers build software, they rarely write everything themselves. They pull in libraries, packages, container base images and other "software artefacts" from public or internal repositories. If the source code simply says "use the latest version of library X", the build will fetch whatever happens to be current on the day, which may be a version nobody has reviewed, or a version that has been tampered with or replaced by an attacker. This control requires two things. First, each dependency must be pinned, meaning the source code names a specific version rather than a range or "latest". Second, the pinned version must be one your organisation has approved, so the choice reflects a deliberate decision rather than whatever the package manager resolved. It matters because dependency confusion, malicious package updates and quietly introduced breaking changes are all real-world supply chain attacks. Pinning to approved versions in source code makes builds repeatable, makes every dependency change visible in version control, and stops an unreviewed upstream release from silently becoming part of your product.
Free. Save your status, tasks and notes.
Why it matters
If dependencies are not pinned to approved versions in source code, a build can pull in an unreviewed, vulnerable or maliciously modified version of a library without anyone noticing. A single compromised upstream package can then be shipped into production under your organisation's name. Builds also become non-repeatable, so a bug or breach cannot be reliably traced back to the exact components that were running, and the organisation cannot demonstrate to assessors which software artefacts its systems actually contain.
How to implement
Development leads compile an approved-versions list for each software artefact the organisation depends on, record it in a location developers can reference (such as a shared repository or internal registry), and assign an owner to keep it current.
Developers replace every version range, wildcard or floating tag (such as "latest") in package manifests, lock files, build scripts and container image references with the exact approved version, and commit that change to source control.
DevOps engineers add a pipeline step that parses dependency manifests and fails the build when any dependency is unpinned or resolves to a version not on the approved list.
Code reviewers check dependency changes in every pull request, confirming that any new or updated pin matches an approved version before the change is merged.
Developers who need a newer version of a dependency raise it through the organisation's approval process first, then update the pin in source code only after the version is added to the approved list.
Keep it running
Day to day, this control lives in the repositories. Developers specify exact versions in manifests (for example package manifests, lock files, build scripts and container image references) rather than version ranges or floating tags, and they only choose versions that appear on the organisation's approved list.
Someone needs to own the approved-version list and keep it current as new releases are vetted. When a developer wants to move to a newer version, the change is made in source code, goes through normal code review and is merged like any other change, so the history of every dependency bump is visible in version control.
Automated checks in the build pipeline are the practical way to keep this honest: a build should fail if a manifest contains an unpinned dependency or a version that is not on the approved list. Periodic reviews of repositories catch drift, such as a developer temporarily loosening a pin to get something working and forgetting to restore it.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the organisation's list of approved software artefact versions.
Look at
Look at whether the list names specific versions for each dependency, who owns it and when it was last updated.
Good evidence
A maintained list exists that names exact approved versions and shows evidence of regular updates by a named owner.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the dependency manifests, lock files and build scripts from a sample of source code repositories.
Look at
Look at how each dependency is specified, checking for exact version numbers rather than ranges, wildcards or floating tags such as "latest".
Good evidence
Every dependency in the sampled files is pinned to an exact version and each pinned version appears on the approved list.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the configuration of the build pipeline checks that enforce pinning and approved versions.
Look at
Look at what the check inspects and what happens when it finds an unpinned or unapproved dependency.
Good evidence
The pipeline automatically fails a build that contains an unpinned dependency or a version not on the approved list, and recent run history shows the check operating.
- Check 4 of 5What an auditor asks for
Ask for
Ask for version control history showing recent dependency version changes.
Look at
Look at whether each change to a pinned version was made in source code, reviewed, and tied to an approval of the new version.
Good evidence
Dependency bumps are visible as reviewed commits or pull requests, and each new version was approved before the pin was changed.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the results of the most recent review of repositories for dependency pinning drift.
Look at
Look at whether any unpinned or unapproved dependencies were found and how they were resolved.
Good evidence
Reviews are performed periodically, findings are recorded, and any loosened or unapproved pins were corrected in source code.
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: 3 mappings
This control partially meets A.5.21.
ISM-2154 requires organisations to control ICT supply chain inputs at the code level by pinning third-party dependencies to approved versions in source code. Annex A 5.21 requires processes and procedures to manage information security risks across the ICT supply chain, which includes third-party software components, update channels and supplier assurance. ISM-2154 is a specific technical/procedural mechanism that implements part of Annex A 5.21, while Annex A 5.21 covers a wider range of supply chain risks and governance activities.
This control partially meets A.8.25.
ISM-2154 requires pinning third-party dependencies to approved versions in source code to reduce build-time supply chain risk and unapproved component drift. Annex A 8.25 requires an organisation-defined secure development lifecycle, within which rules for dependency management (including lockfiles, approved registries and version pinning) are typically established and enforced. Annex A 8.25 is broader lifecycle governance, while ISM-2154 is a concrete implementation requirement within that lifecycle.
This control partially meets A.8.27.
ISM-2154 requires controlling third-party software composition by pinning dependencies to approved versions in source code. Annex A 8.27 requires secure system architecture and engineering principles to be established and applied, which can include supply chain integrity principles such as controlling external components and ensuring build reproducibility. Annex A 8.27 is higher-level engineering guidance, whereas ISM-2154 is a specific engineering control for dependency version control.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.