Question
Composer install versus update and noisy security advisories
Ari Nea
0 reputation · 29 Apr 2024, 04:01 UTC
93.3K views1
Loading…
0 reputation · 29 Apr 2024, 04:01 UTC
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?
Answer: Use composer install in all CI/CD and production environments to reproduce the exact versions locked in composer.lock. Run composer update only on a dedicated branch when you intentionally want to evaluate newer versions (e.g., during a scheduled security‑update sprint). After the update, review the output of composer audit. If the new advisories are acceptable, commit the updated lock; otherwise revert or adjust constraints. Tag the commit with a clear message indicating the intentional update.
The noisy security advisories that appear after running composer update are likely caused by the resolver picking newer versions that have publicly reported vulnerabilities, which were not present in the previously locked set.
composercomposer install never modifies composer.lock; it installs exactly what is locked, so the advisory set stays constant between runs.composer update reads composer.json, resolves the newest allowed versions per constraints, writes a new lock file, and may bring in versions that have known security issues.composer audit reports advisories for the currently installed package set but provides no built‑in thresholds or deduplication.composer install (or composer install --prefer-dist --no-interaction) to install the locked versions.composer update.composer audit and review the list.composer.lock with a descriptive commit message.composer.json and repeat.composer.lockcomposer.lock to guarantee identical installs across dev, CI, and production.composer.lock; let consumers lock their own dependencies. Commit a lock file only for internal tooling (e.g., a demo application).Use comments to ask for clarification. Post a solution as an answer.
29,775 reputation · 29 Apr 2024, 13:27 UTC
One clarification that often gets missed: composer update doesn't have to be all-or-nothing. Running composer update vendor/package re-resolves only that package (add --with-dependencies if its own deps must move), which is the practical way to land a security patch without churning the whole lock file. Verify with git diff composer.lock that only the intended entries changed.
On the noise question: composer audit exits non-zero when advisories exist, so any CI step that fails on exit code will alert on every run until the lock changes. Since there's no built-in severity threshold or dedup, teams typically parse the JSON output (composer audit --format=json) and filter by severity or advisory ID, or use the audit.ignore config (Composer 2.7+; confirm availability in your version) to suppress accepted advisories at the source.
For libraries, skipping the lock file in VCS also means CI should test lowest and highest constraint resolutions, since consumers will see both.