Formula Used
The calculator uses a weighted preservation model. It combines coverage controls with active dependency risk.
Coverage Score = pinned ratio × 18 + mirror ratio × 18 + checksum ratio × 14 + lock freshness × 13 + restore test ratio × 14 + backup score × 9 + offline score × 4 + inventory ratio × 10.
Risk Penalty = vulnerabilities × 5 + unmaintained dependencies × 4 + license conflicts × 6 + unprotected critical dependencies × 5 + stale lockfile penalty + offline penalty.
Risk Score = 100 − Risk Penalty.
Preservation Index = Coverage Score × 0.60 + Risk Score × 0.40.
Exposure Hours = unprotected dependencies × average restore hours × criticality factor × offline factor.
How To Use This Calculator
Enter the total number of project dependencies first. Count direct and transitive packages when possible. Add the number of critical packages that can block production builds. Enter how many packages are inventoried, pinned, mirrored, and checksum verified. Add lockfile age, restore test progress, vulnerabilities, license issues, and backup retention. Select offline build support and release criticality. Press calculate. Review the index, grade, exposure hours, and recommendation. Use CSV or PDF export for audits, release notes, and internal reviews.
Dependency Preservation Overview
Dependency preservation protects a project when external packages change, disappear, or become unsafe. Modern builds often rely on many direct and transitive packages. A single missing package can stop deployment. A weak lockfile can also allow unexpected versions. This calculator gives a practical score for that risk. It compares protected packages with total packages. It also checks mirrors, checksums, restore tests, backups, and vulnerability pressure.
Why The Score Matters
A good preservation plan keeps releases reproducible. Teams can rebuild older versions without guessing. They can recover faster after registry outages. They can prove which package versions were approved. This matters for audits, customer trust, and incident response. The calculator is not a security scanner. It is a planning tool. It highlights gaps that often create downtime. The final index combines coverage and risk. High coverage shows strong controls. Low risk shows fewer active problems.
Reading The Results
The preservation index runs from zero to one hundred. A higher value means stronger readiness. The coverage score measures how many controls exist. The risk score reduces value for vulnerabilities, license conflicts, stale lockfiles, and unmaintained packages. Exposure hours estimate recovery effort for unprotected dependencies. This number helps teams decide whether mirroring or vendoring is worth the work. The grade gives a fast summary for managers. The recommendation explains the next best action.
Practical Improvement Steps
Start by pinning every production dependency. Commit lockfiles for applications. Store package checksums when your tooling allows it. Mirror critical packages into a trusted internal registry. Keep a small backup of release artifacts. Test restores before a real outage. Review abandoned packages before major releases. Replace risky packages gradually. Keep license records with each release. These steps make builds repeatable. They also make emergency recovery calmer, faster, and more defensible.
Advanced Use Cases
Use this page during release reviews, migration planning, procurement checks, and vendor risk discussions. Compare several projects with the same inputs. Then rank them by exposure hours and preservation index. A project with many critical packages may need internal mirrors first. A smaller tool may only need better pinning. Repeat the assessment after every major framework upgrade or registry policy change. Document every exception so future maintainers understand the accepted risk.
FAQs
What is dependency preservation?
It is the practice of keeping package versions, artifacts, checksums, and recovery steps available. It helps teams rebuild software even when external sources change or fail.
What is a good preservation index?
A score above 80 is usually strong. A score above 90 is excellent. Lower scores suggest missing mirrors, weak pinning, stale lockfiles, or unresolved risks.
Should transitive dependencies be counted?
Yes. Transitive dependencies can break builds too. Count every package used during install, build, test, packaging, and production deployment when possible.
Why does lockfile age matter?
An old lockfile can hide stale packages, abandoned dependencies, and unreviewed risks. Fresh lockfiles show that dependencies were recently checked and confirmed.
What does mirror coverage mean?
Mirror coverage shows how many packages are stored in a controlled registry, cache, or vendor folder. Higher coverage reduces outage and deletion risk.
Why are checksums important?
Checksums confirm package integrity. They help detect changed files, tampered archives, and unexpected replacements during future builds or emergency restores.
What are exposure hours?
Exposure hours estimate the recovery effort for unprotected dependencies. It helps compare the cost of weak preservation against the effort needed to improve it.
Can this replace security scanning?
No. This calculator supports planning and preservation scoring. Use dedicated security, license, and software composition tools for deeper package analysis.