ASD ISM 2154Pinning Software Artefact Dependencies to Approved Versions in Source Code
Every 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.
Plain language
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.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentTopic
Software artefacts
Official control statement
Software artefact dependencies are pinned to approved versions in source code.
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- AskAsk for the organisation's list of approved software artefact versions.Look atLook at whether the list names specific versions for each dependency, who owns it and when it was last updated.GoodA maintained list exists that names exact approved versions and shows evidence of regular updates by a named owner.
- AskAsk for the dependency manifests, lock files and build scripts from a sample of source code repositories.Look atLook at how each dependency is specified, checking for exact version numbers rather than ranges, wildcards or floating tags such as "latest".GoodEvery dependency in the sampled files is pinned to an exact version and each pinned version appears on the approved list.
- AskAsk for the configuration of the build pipeline checks that enforce pinning and approved versions.Look atLook at what the check inspects and what happens when it finds an unpinned or unapproved dependency.GoodThe 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.
- AskAsk for version control history showing recent dependency version changes.Look atLook at whether each change to a pinned version was made in source code, reviewed, and tied to an approval of the new version.GoodDependency bumps are visible as reviewed commits or pull requests, and each new version was approved before the pin was changed.
- AskAsk for the results of the most recent review of repositories for dependency pinning drift.Look atLook at whether any unpinned or unapproved dependencies were found and how they were resolved.GoodReviews are performed periodically, findings are recorded, and any loosened or unapproved pins were corrected in source code.
Cross-framework mappings
How ISM-2154 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(3)expand_less | ||
| Annex A 5.21 | ISM-2154 requires organisations to control ICT supply chain inputs at the code level by pinning third-party dependencies to approved vers... | |
| Annex A 8.25 | ISM-2154 requires pinning third-party dependencies to approved versions in source code to reduce build-time supply chain risk and unappro... | |
| Annex A 8.27 | ISM-2154 requires controlling third-party software composition by pinning dependencies to approved versions in source code | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Software development
See all Guidelines for software development controls, or browse the full ASD ISM library.