A dependency audit identifies known advisories or other package concerns. It is the beginning of a repair decision, not a reason to replace every production dependency without testing.
IN THIS ARTICLE
What you need before you begin
Use the application’s current lock file and a supported Composer release. Identify who maintains the application and how a tested dependency change reaches production.
01 Audit PHP dependencies without blindly upgrading production
Run the supported Composer audit command and save the package names, installed versions and advisory references. Avoid putting private repository credentials in the report.
Determine whether the affected package and feature are used in the deployed application. Review the official advisory and available fixed versions.
Update the narrowest appropriate dependency set in development while respecting compatible constraints. Review changes to transitive packages as well as the direct dependency.
Build and test the resulting release, focusing on the affected feature and critical customer workflows.
Deploy the reviewed lock file through the normal release process and repeat the audit to confirm the intended issue is addressed.
02 Example: audit the locked release before selecting an update
From a private copy of the application with its reviewed composer.lock, run an audit against the locked production dependency set. This identifies advisories to investigate without selecting new package versions or changing the live site.
composer audit --locked --no-dev --format=tableFor each finding, record the affected package, locked version, advisory reference and fixed release. Determine whether the affected feature is actually used. Prepare the narrow dependency update in development and review its lock-file changes, including transitive packages. A nonzero audit exit should create a visible review item rather than be suppressed automatically.
Expected result: The maintenance record connects each relevant finding to a tested correction or an explicitly owned follow-up. A clean audit is useful evidence about known dependencies at that time, but it does not certify the application’s own code or configuration.
Confirm the expected result
Verify the deployed versions match the repaired lock and that the application still functions. Track an unfixed or unsupported package as a deliberate follow-up rather than hiding the finding.
Troubleshoot unexpected results
If no compatible fixed version exists, evaluate a supported replacement, feature restriction or other documented mitigation. Do not assume suppressing an audit entry removes the risk.
A common question
Is an audit with no findings a guarantee of security?
No. It reflects the advisories and dependency information checked at that time. Application code, configuration, access control and newly discovered issues still require attention.