.NET projects often rely on NuGet packages. By generating a packages.lock.json file, you create a stable snapshot of all dependencies—critical for accurate CybeDefend SCA scanning.

  1. Enable Lockfiles in .csproj
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
    <RestoreLockedMode Condition="'$(ContinuousIntegrationBuild)' == 'true'">true</RestoreLockedMode>
  </PropertyGroup>
</Project>
  1. Run dotnet restore
    This generates a packages.lock.json file.
  2. Commit packages.lock.json
    Never edit this file manually. Let dotnet restore handle updates.

​
Why You Should Use Lockfiles

Using a lockfile is critical for secure and predictable builds. A lockfile contains a fixed version and a hash for each dependency and sub-dependency in your project.

  1. Supply Chain Protection
    Lockfiles prevent malicious package injections. This is crucial as supply chain attacks are rising.
  2. Predictable Builds
    Everyone uses the exact same package versions, avoiding “it works on my machine” inconsistencies.
  3. Performance Gains
    With dependency versions locked, build tools skip the usual resolution step, making builds faster.

Lockfiles are never edited manually. They’re generated and updated by your package manager and committed to your repository, ensuring consistent environments for all teammates.

​
Lockfile Commands

  • Generate: dotnet restore
  • Locked Restore: dotnet restore --locked-mode
  • Update: Change versions in .csproj or Directory.Packages.props, then run dotnet restore again.

​
Supported Files for .NET

File Examples
.deps.json, packages.lock.json, Packages.props, .csproj

If your lockfile is missing, SCA scanning might only detect partial or incorrect versions of NuGet packages. Lockfiles ensure precise dependency resolution.

Use Directory.Packages.props (NuGet central package management) for an even cleaner approach to pinned versions.