How to Respond to a Security Advisory Beyond Updating a Package
A practical security advisory response process for Ruby, PHP and Laravel teams.
A package update can be correct and still fail to protect the running application. The dependency may not be in the deployed image, the vulnerable route may be untested, or a scheduler may be watching a different branch. Treat an advisory as a change-management event with evidence at every boundary.
The seven-step response
- Identify. Record the advisory, affected component and fixed versions from the maintainer.
- Inventory. Search every lock file, image and service that can contain the component.
- Contain. Add a temporary route, access or configuration guard if exposure is plausible.
- Patch. Update the lock file and review the dependency diff.
- Test. Add a regression test for the unsafe input or behaviour, not only a version assertion.
- Release. Promote the exact tested commit through the approved branch path.
- Verify. Check health, logs, running revision and the protected behaviour after deployment.
Why the last step is where teams lose confidence
“The merge succeeded” and “the service is protected” are different statements. A release record should link the dependency diff, fresh gate result, production commit and post-release check. If one link is missing, mark the response as in progress.
Stop conditions
Pause the release if the build is reusing a stale asset, if the test did not exercise the affected guard, if the production revision cannot be identified, or if the health endpoint is green while application logs show errors. A clean rollback is safer than a confident guess.
For background, compare the maintainer's advisory with OWASP's Software Supply Chain Security guidance.
