composer and ecosystem
Dependency Audits
composer audit checks installed or locked packages against known security advisories and reports abandoned packages. It helps teams find dependency risk early.
Working Knowledge
- Run audits locally after dependency changes and in CI on a schedule.
- Investigate advisories and abandoned packages rather than treating audit as a checkbox.
- Update narrowly when possible and test the result.
- Record accepted temporary risk with ownership and a remediation date.
- Remember that audit data cannot detect every vulnerability.
Run The Audit
composer audit
Run it after dependency changes and on a schedule in CI. Dependency risk changes when new advisories are published, even if your repository has not changed.
Triage The Result
For each advisory, identify the affected package and versions, whether your application uses the vulnerable feature, the available fixed version, the update blast radius, and the owner for remediation.
An abandoned package warning is not automatically an emergency, but it is a maintenance signal. Decide whether a supported replacement exists and how migration will be tested.
Record Temporary Exceptions
If an update cannot land immediately, record the reason, compensating controls, owner, and review date. Avoid permanent silent ignores.
In Application Work
Dependency risk changes without source-code changes. Scheduled audits and update workflow matter even during quiet development periods.
What To Check
Before moving on, make sure you can run an audit, triage advisories, respond to abandoned packages, and document time-limited exceptions.
Practice
Practice: Plan Dependency Auditing
Run composer audit in a sample application and write the triage path for an advisory or abandoned dependency.
Requirements
- Choose local and CI audit timing.
- Describe advisory triage.
- Handle abandoned packages.
- Document temporary exceptions.
Show solution
Run composer audit in local checks and CI, identify affected packages and installed versions, and decide who triages findings. Check whether a compatible fixed release exists and whether an abandoned package needs replacement planning.
Update the narrowest suitable dependency set, review the lock-file diff, and run regression tests. Document temporary mitigations with an owner and removal date.