Composer install versus update and noisy security advisories

A team wants reproducible dependency sets for applications while avoiding repeated security advisory notifications in CI. Composer documents install as reproducing the exact versions recorded in composer.lock and update as re-resolving version constraints against repositories and writing a new lock file. The distinction creates an unresolved decision about when re-resolution is permitted and how changes should be surfaced without noise.

Composer audit outputs advisories for the installed package set but provides no built-in alerting thresholds or deduplication. Minimum-stability and per-package stability flags interact with constraint ordering in ways that can change selected versions. Documented guidance treats composer.lock as appropriate for applications but not libraries, leaving an unresolved decision about lock file policy. Platform requirements are checked at install time and can differ between environments.

Which policy for install versus update preserves reproducibility while allowing intentional security updates? Does the lack of built-in thresholds in composer audit force teams to implement external deduplication to avoid notification noise? What criteria should govern committing composer.lock for libraries versus applications?