Skip to content

Missing Lockfile resulting in unpinned dependencies

Verifies the presence of dependency management manifests (e.g., package.json, Gemfile, pyproject.toml, Pipfile, go.mod, etc.) without an accompanying lockfile that cryptographically pins dependencies (e.g., package-lock.json, Gemfile.lock, poetry.lock, Pipfile.lock, go.sum).

The Importance of Dependency Lockfiles for Consistent, Secure, and Predictable Dependency Management

Dependency lockfiles play a critical role in modern software development, allowing teams to create consistent, secure, and predictable environments across different stages of the software lifecycle. For developers, lockfiles aren’t just another file in a repository—they’re vital to maintain consistent builds, enhance security, and streamline collaboration. This article explores the importance of lockfiles, the benefits they bring, and the specific implementation across major programming languages.

Why Dependency Lockfiles Matter

1. Consistency Across Environments

Lockfiles record the exact versions of every dependency, along with sub-dependencies, that a project relies on. By storing these specific versions, lockfiles eliminate inconsistencies between environments (development, staging, production). When the same lockfile is used, developers can be confident that each installation recreates the exact same environment every time, reducing the risk of "works on my machine" issues.

2. Enhanced Security

Using dependency lockfiles is a strong security measure. Lockfiles help protect applications against dependency-related vulnerabilities by preventing unexpected updates that could introduce insecure versions. Security vulnerabilities in dependencies are common, and by controlling which versions are installed, you gain better control over security risks.

3. Improved Collaboration

For teams working on the same project, lockfiles ensure that every developer, regardless of local setup, works with identical dependency versions. This alignment is crucial for teams, enabling smoother collaboration and reducing friction when reviewing and merging code changes.

4. Software Bill of Materials (SBOM)

Lockfiles are essential for generating a Software Bill of Materials (SBOM), which is increasingly important for tracking software supply chains. For example, Trivy, a security scanner, can generate an SBOM for dependency security analysis, but it requires a lockfile to function effectively. Without such a file, the SBOM would not accurately reflect the project’s dependencies and their associated vulnerabilities as would be an incomplete and most likely incorrect picture of the reality in the production environment.

Where the Rule Looks for a Lockfile

A dependency manifest is reported when none of the lockfiles accepted for that manifest is found. The sections below list, for each language, the manifests that are checked and the lockfiles that satisfy them.

Some package managers keep a single lockfile above the projects it covers rather than beside each manifest. For those, the lookup starts in the directory holding the manifest and climbs to the repository root, so a workspace or monorepo carrying one lockfile at its root is not reported:

  • Cargo.lock for the members of a Cargo workspace
  • uv.lock for the members of a uv workspace
  • cabal.project.freeze for a *.cabal package below the directory holding the freeze file
  • *.deps.json and *Packages.props for .NET projects, covering a repository-wide Directory.Packages.props and build output written to a shared bin/ directory

Dependency Lockfiles Across Languages

JavaScript

Python

Go

Java

Scala

.NET / C

Ruby

PHP

Rust

Objective-C / Swift

Elixir

Dart

C/C++

Julia

Haskell

R

Steps to Create an SBOM with Trivy

For Trivy’s SBOM feature to work correctly, it’s essential to have an up-to-date lockfile. Lockfiles contain metadata required for generating an SBOM that accurately represents the project’s dependencies, versions, and potential security vulnerabilities.

Additional Resources