Commit composer.lock to version control or risk version drift after backup restoration?

When a composer‑based project restores its vendor directory from a backup, the exact dependency versions must be reproduced to guarantee reproducible builds.

If the composer.lock file is absent from the backup, the subsequent composer install may resolve to newer package releases, breaking compatibility with the original environment and introducing version drift.

Should the composer.lock be included in the backup and version‑controlled repository, or omitted to allow dependency upgrades? Which verification method can reliably detect mismatches between the restored vendor directory and the lock file? How can teams balance dependency stability with the need for security updates?