Software Dependency Verification
The operational process of verifying that declared dependencies in manifests and lockfiles match the resolved and fetched packages, including hash verification, lockfile integrity, and source-to-artifact correspondence.
Primary question: How do organizations verify that declared dependencies match the actual dependencies used in the build?
Direct answer
Software dependency verification is the operational process of comparing declared dependencies against resolved ones — confirming that the package identity, version, and hash used in the build match what was declared in the manifest or lockfile. This process includes lockfile integrity verification, dependency resolution auditing, and source-to-artifact correspondence checks.
Software dependency verification confirms that the dependencies used in a build match what was declared, including package identity, version, and integrity.
Dependency verification is a critical component of software supply-chain security because compromised dependencies can introduce vulnerabilities, backdoors, or malicious code into applications.
Definitions
Declared dependency
A dependency specified in the project's manifest file (e.g., package.json, requirements.txt, pom.xml) — the intended package and version that the developer or build system requests.
Resolved dependency
The actual package and version that the dependency resolver fetches from the registry, which may differ from the declared dependency due to version ranges, transitive resolution, or registry substitution.
Lockfile
A file that records the exact versions and hashes of all resolved dependencies, ensuring reproducible builds by pinning the dependency tree to specific versions.
Source-to-artifact correspondence
Evidence that a build artifact was produced from the declared source code and dependencies, verified through build provenance, reproducible builds, or cryptographic attestation.
Dependency hash verification
The process of comparing the cryptographic hash of a fetched package against the expected hash to confirm that the package has not been modified.
The engineering problem
Version ranges in dependency manifests may resolve to different versions over time, even with a lockfile, if the lockfile is regenerated without hash pinning.
A package registry may serve a different package than expected due to typosquatting, registry compromise, or supply-chain attack. Hash verification is required to detect such substitutions.
Transitive dependencies are resolved automatically and may not be visible in the manifest. Organizations may not verify the identity and integrity of transitive dependencies.
Security controls
Each control inspects a different artifact and produces evidence for an engineering decision.
Lockfile integrity verification
Lockfile validation- Artifact
- A lockfile that has been verified against the dependency manifest, confirming that all resolved versions and hashes match the expected values.
- Risk
- A lockfile that has been modified or regenerated without verification, potentially introducing different dependencies.
- Output
- Verified lockfile with confirmed version and hash integrity.
Evidence:
Dependency hash pinning
Hash-verified dependencies- Artifact
- Dependencies pinned by cryptographic hash, ensuring that the exact package bytes are used regardless of registry availability or version changes.
- Risk
- Using version ranges without hash pinning, allowing different package content to be fetched.
- Output
- Dependencies pinned by hash, preventing substitution attacks.
Evidence:
Dependency resolution auditing
Resolution audit- Artifact
- A record of all resolved dependencies — declared, transitive, and overridden — compared against the manifest to detect unexpected changes.
- Risk
- Undetected transitive dependencies that introduce vulnerabilities or malicious code.
- Output
- Complete dependency resolution audit with documented discrepancies.
Evidence:
Verification workflow
- The developer declares dependencies in the project manifest.
- The dependency resolver fetches and resolves all dependencies, including transitive ones.
- The lockfile is generated or updated with the resolved versions and hashes.
- Lockfile integrity is verified — resolved versions and hashes match the manifest declarations.
- Dependency resolution is audited — all transitive dependencies are identified and assessed.
- Hash pinning is applied to critical dependencies to prevent substitution.
- The resolved dependency tree is compared against known vulnerability databases and provenance records.
DerScanner · Enterprise
Relationship to DerScanner
DerScanner provides SCA analysis that identifies open-source components, vulnerabilities in open-source libraries, and software-supply-chain risks. SCA provides dependency-tree visualization and package health assessment to support dependency verification.
DerScanner performs software-composition analysis that identifies open-source components, vulnerabilities in open-source libraries, and software-supply-chain risks. SCA provides dependency-tree visualization and package health assessment to support dependency verification. [derscanner-sca]
Limits of verification
- Dependency verification cannot guarantee that a dependency is free of all vulnerabilities. New vulnerabilities may be discovered after the verification process.
- Provenance verification depends on the availability and accuracy of provenance information from package registries and maintainers.
- Build artifact verification requires that the build process itself is secure and reproducible.
Related knowledge
Malicious Open-Source Packages
How malicious packages can compromise the supply chain
Relationship: related-toDependency Provenance
The documented origin and history of dependencies
Relationship: related-toTransitive Dependency Risk
Risks associated with indirect dependencies
Relationship: related-toBuild Pipeline Supply Chain Security
Securing the build process as part of supply-chain security
Relationship: related-toSoftware Artifact Integrity
Verifying the integrity of build artifacts
Relationship: related-toCanonical terms used: Software dependency verification; Dependency authenticity; Dependency provenance; Supply-chain verification.
Evidence and references
- DerScanner SCA documentationDerScanner SCA identifies open-source components, vulnerabilities in open-source libraries, software-supply-chain risks, license risks, dependency-tree visualization, package health assessment, and hybrid SAST+SCA function reachability.
derscanner-sca
Dependency verification