{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifg7en2ze3hgu3tyqra75e6mm5mxpeq2rik7iyqxxxw4thehfo4ea",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mol5yu6ebin2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreibgzrjp66ojgk7j43xqsewsvph3txbgz7comhmc3xnp5ayhdwa6xq"
    },
    "mimeType": "image/webp",
    "size": 181102
  },
  "path": "/vulert_official/dependency-pinning-vs-floating-versions-what-security-teams-need-to-know-50c4",
  "publishedAt": "2026-06-18T15:09:49.000Z",
  "site": "https://dev.to",
  "tags": [
    "dependencypinning",
    "applicationsecurity",
    "floatingversions",
    "vulert"
  ],
  "textContent": "A dependency version can decide whether your production build installs the same safe code every time or silently pulls a different release. `lodash@4.17.21`, `lodash@^4.17.0`, and `lodash@>=4.0.0` create very different security outcomes.\n\nThat is why **dependency pinning security** matters. Pinning improves reproducibility, floating ranges allow updates, and lock files sit between both. The right strategy helps teams avoid surprise package changes without getting stuck on old vulnerable versions.\n\n##  The Three Approaches to Dependency Versioning\n\nDependency pinning means specifying an exact package version. For example, `lodash@4.17.21` allows only version `4.17.21`. The package manager should not choose `4.17.20` or `4.17.22` unless the developer changes the requirement.\n\nFloating versions use ranges instead of exact versions. For example, `lodash@^4.17.0` can allow newer compatible versions in the same major release line, depending on the package manager rules. A broad range such as `>=4.0.0` is even more permissive and can allow many future versions.\n\nSemi-pinning is the common middle path. The manifest file uses a range, but the lock file records the exact resolved version. For example, `package.json` may contain `\"lodash\": \"^4.17.0\"`, while `package-lock.json` records the exact version installed in the project.\n\n  * **Pinned dependency:** An exact version such as `axios@1.7.7` that improves reproducibility but requires manual patch movement.\n  * **Floating dependency:** A version range such as `axios@^1.7.0` that allows newer compatible releases.\n  * **Lock file:** A resolved dependency record such as `package-lock.json`, `composer.lock`, or `poetry.lock`.\n  * **Transitive dependency:** A package installed because another dependency requires it, even if your project did not list it directly.\n\n\n\nThe safest dependency strategy is rarely “pin everything forever” or “float everything freely.” Most teams need reproducible installs plus fast patch automation.\n\n##  The Security Case for Pinning\n\nPinning gives security teams one major advantage: certainty. If the application says it uses `express@4.18.2`, and the build installs exactly that version, the team can reproduce the environment, test the same code, and investigate incidents with confidence.\n\nThis matters during security response. If a CVE affects `log4j-core 2.14.1`, the team needs to know whether that exact version exists in production. Exact pins and lock files make that answer easier. Without them, the answer can change depending on when the install happened.\n\nPinning also reduces surprise updates. A package maintainer may publish a broken release, remove a function, add a risky dependency, or accidentally introduce a vulnerability. If your production build floats freely, that release may enter your environment without a code change in your repository.\n\nAnother benefit is auditability. When versions are fixed, teams can compare one build to another and see exactly which dependency changed. That supports release review, incident investigation, rollback, and compliance evidence.\n\nFor dependency pinning security, the strongest benefits are:\n\n  * **Reproducible builds:** Development, CI, staging, and production can install the same versions.\n  * **No surprise package movement:** New releases do not enter production unless the team updates them.\n  * **Clear audit trail:** Version changes become visible in pull requests and lock file diffs.\n  * **Better incident response:** Teams can confirm whether a vulnerable version was installed.\n  * **Reduced accidental breakage:** Builds are less likely to fail because a new dependency release changed behavior.\n\n\n\n> **Tip:** Pinning is most valuable when you combine it with regular patch review. Exact versions without updates become technical debt.\n\n##  The Security Case Against Pinning\n\nPinning has a real downside: it can freeze vulnerable code in place. If your project pins `lodash@4.17.10`, it will not move to `4.17.21` automatically. If no one owns dependency updates, the pinned version may remain vulnerable for months or years.\n\nThis problem is called pin drift. The longer a pinned dependency stays unchanged, the further it falls behind maintained releases. Eventually, upgrading becomes painful because the team must jump across many versions at once. Tests fail, APIs change, and developers delay the work again.\n\nFloating versions solve part of this problem by allowing package managers to select newer releases. A patch release may include a security fix, and a range may allow that fix to be installed without manually editing the manifest. But this benefit only helps when installs are controlled and reviewed.\n\nThe dangerous version of floating happens when a production build resolves dependencies without a lock file. In that case, two builds from the same source code can install different package versions. That weakens testing and creates supply chain risk.\n\n> **Warning:** Pinning without update automation can leave you running old vulnerable packages. Floating without lock files can let unreviewed package versions enter production.\n\n##  The Best Approach — Lock Files as the Middle Path\n\nLock files give teams the best balance for most applications. The manifest file can express intent with a reasonable range, while the lock file records the exact versions that were actually resolved and tested.\n\nFor npm, the manifest is `package.json` and the lock file is `package-lock.json`. For Yarn, it is `yarn.lock`. For PHP Composer, the files are `composer.json` and `composer.lock`. For Python projects, tools such as Poetry and Pipenv use `poetry.lock` and `Pipfile.lock`. Go uses `go.mod` and `go.sum` for module requirements and verification.\n\nLock files make builds reproducible because they preserve the resolved dependency graph. If the manifest says `^4.17.0`, the lock file can still say the actual installed version is `4.17.21`. CI and production should install from that lock file rather than resolving new versions every time.\n\n\n\n    npm ci\n\n\nFor npm, `npm ci` installs from the lock file and is designed for clean CI environments. It helps prevent unexpected dependency resolution during builds.\n\n\n\n    composer install --no-dev --prefer-dist\n\n\nFor Composer, `composer install` reads `composer.lock`. Use `composer update` only when you intentionally want to resolve newer versions and update the lock file.\n\nThis middle path supports dependency pinning security because the production install remains exact, but updates can still be managed through pull requests. The team controls when packages move and can test every change before merging.\n\n##  Ecosystem-Specific Pinning Guidance\n\nEvery ecosystem handles dependency resolution differently. A strong policy should respect those differences instead of forcing one rule everywhere.\n\nEcosystem | Recommended Manifest Approach | Lock File? | Automated Updates\n---|---|---|---\nnpm / Node.js | Use `^` for normal apps, stricter ranges for sensitive packages | Commit `package-lock.json` or `yarn.lock` | Dependabot or Renovate\nMaven / Java | Use exact versions in `pom.xml` for production | Use dependency management and build reproducibility controls | Renovate or similar tooling\nPython pip | Use exact pins for production deployments | Use generated lock files with Poetry, Pipenv, or pip-tools where possible | Dependabot or Renovate\nPHP Composer | Use `^` constraints in `composer.json` | Commit `composer.lock` for applications | Dependabot or Renovate\nGo Modules | Use `go.mod` requirements | Commit `go.sum` | Dependabot or Renovate\n\n###  npm Pinning\n\nnpm pinning should usually rely on a committed lock file. Many Node.js applications use `^` ranges in `package.json` and exact resolved versions in `package-lock.json`. Avoid `*`, `latest`, and broad `>=` ranges in production dependencies.\n\n\n\n    npm install\n    npm ci\n    npm audit --production\n\n\n###  Maven and Java\n\nMaven production dependencies should normally use explicit versions. Avoid open-ended version ranges for production code because they can make builds harder to reproduce. Use dependency management to centralize versions across modules.\n\n\n\n    mvn dependency:tree\n\n\n###  Python pip\n\npip production deployments usually benefit from exact pins such as `Django==4.2.16`. For larger projects, generate locked requirements with pip-tools, Poetry, or Pipenv so every install uses the same package set.\n\n\n\n    pip freeze > requirements.txt\n    pip install -r requirements.txt\n\n\n###  PHP Composer\n\nComposer works well with flexible constraints in `composer.json` and exact resolved versions in `composer.lock`. Applications should commit `composer.lock`. Libraries usually should avoid forcing consumers to use the library’s lock file.\n\n\n\n    composer install\n    composer audit\n\n\n###  Go Modules\n\nGo Modules provide strong defaults through `go.mod` and `go.sum`. Commit both files for services and applications. Use `go mod verify` to verify downloaded modules against expected checksums.\n\n\n\n    go mod tidy\n    go mod verify\n\n\n##  Building an Automated Update Strategy by Severity\n\nAutomation solves the biggest weakness of pinning: delayed updates. The goal is not to merge every update blindly. The goal is to make safe updates visible, testable, and routine.\n\nUpdate Type | Example | Recommended Policy | Reason\n---|---|---|---\nPatch |  `4.17.20` to `4.17.21` | Auto-PR, allow auto-merge after CI for low-risk packages | Usually bug fixes and security patches\nMinor |  `4.16.0` to `4.17.0` | Auto-PR, human review required | May add features, dependencies, or behavior changes\nMajor |  `4.17.21` to `5.0.0` | Manual review and planned upgrade | May include breaking changes\nKnown exploited CVE fix | Any fixed version | Urgent review and expedited merge | Attackers may already be exploiting it\n\n  * **Enable update bots:** Use Dependabot or Renovate to open pull requests when safer versions become available.\n  * **Separate patch, minor, and major changes:** Keep small fixes easy to review and large upgrades deliberate.\n  * **Require CI checks:** Run tests before merging any dependency update.\n  * **Prioritize security fixes:** Treat CVE-driven updates differently from routine version bumps.\n  * **Scan lock file changes:** Review transitive dependency movement, not just direct dependency names.\n\n\n\n##  Why Continuous Monitoring Still Matters Either Way\n\nWhether you pin or float, you still need to know when a version becomes vulnerable. A pinned version can be safe today and vulnerable tomorrow when a CVE is disclosed. A floating range can still resolve to a vulnerable version if the fixed release is outside the allowed range or the lock file has not moved.\n\nContinuous monitoring closes that gap. Instead of waiting for a manual audit, the system watches your manifest files and SBOMs for newly disclosed vulnerabilities. When a CVE affects a package you use, your team gets alerted with context.\n\nVulert supports this workflow by analyzing manifest files and SBOMs against a database of 458,000+ known CVEs. It supports files such as `package-lock.json`, `yarn.lock`, `pom.xml`, `build.gradle`, `requirements.txt`, `Pipfile.lock`, `poetry.lock`, `composer.lock`, `go.sum`, `Gemfile.lock`, `Cargo.lock`, `pubspec.lock`, `mix.lock`, `*.csproj`, `packages.lock.json`, and SPDX/CycloneDX SBOMs.\n\nVulert also provides fix guidance, exact fixed versions, CLI commands where available, CVSS context, full CVE detail, Jira ticket creation, vulnerability history, and dependency health grouping. That makes dependency pinning security easier to operate because developers see the package, version, CVE, and fix path in one place.\n\n##  Key Takeaways\n\n  * **Pinning improves reproducibility, auditability, and incident response,** but it can delay security patches without automation.\n  * **Floating versions can pull updates faster,** but broad ranges and missing lock files create supply chain risk.\n  * **Lock files are the best middle path for most applications** because they preserve exact resolved versions.\n  * **Use automated update tools** to open patch, minor, and major update pull requests with different review policies.\n  * **Scan lock files and SBOMs** because transitive dependencies often carry security risk.\n  * **Dependency pinning security works best with continuous monitoring,** not one-time manual audits.\n\n\n\n##  Frequently Asked Questions\n\n###  1. Should I pin all my npm dependencies?\n\nFor npm applications, the better default is usually sane ranges in `package.json` plus a committed `package-lock.json`. Use `npm ci` in CI so builds install from the lock file. For very sensitive packages, exact pins or patch-only ranges may be appropriate.\n\n###  2. What’s the difference between package.json and package-lock.json for security?\n\n`package.json` describes the dependency names and allowed version ranges. `package-lock.json` records the exact dependency tree that was resolved. For security scanning and reproducible builds, the lock file is usually more precise.\n\n###  3. How do I automate security updates for pinned dependencies?\n\nUse tools such as Dependabot or Renovate to open pull requests when fixed versions are available. Configure patch updates for faster review, require CI checks, and route major upgrades through manual engineering review.",
  "title": "Dependency Pinning vs Floating Versions — What Security Teams Need to Know"
}