Don't just silence composer security warnings

A documented reason turns a warning into a decision

Joel Clermont

2026-03-26

Running composer audit is a good habit. It checks your installed packages against known security vulnerabilities and tells you what needs attention.

In almost every case, the correct response is to update the affected package to a patched version and move on. But there are rare scenarios where you either don't want to update, or you can't yet.

Perhaps the fix is only available in a major version you can't upgrade to yet. Or maybe the CVE is in a transitive dependency, and it affects a code path your application doesn't even touch.

For example, a recent CVE flagged a vulnerability in Socialite's Facebook JWT flow. But if your application uses SAML2 for authentication and doesn't even use Socialite's Facebook integration, that CVE is irrelevant to you. And you might not want to take on the risk of a major version upgrade in a sub-dependency of your project yet.

In that case, Composer lets you ignore specific advisories in the audit section of your composer.json config. There are two formats you can use.

The first is a simple array of advisory IDs.

{
    "config": {
        "audit": {
            "ignore": ["CVE-2025-45769"]
        }
    }
}

This suppresses the warning, but that's all it does. I don't recommend this format. It's too vague.

Six months from now, when someone new joins the team, or you're reviewing the config yourself, there's no context for why this was ignored. Was it safe to ignore? Is it still safe? Nobody knows without digging.

The better approach is the object format, where each advisory ID maps to a reason that you provide.

{
    "config": {
        "audit": {
            "ignore": {
                "CVE-2025-45769": "Transitive via Socialite. This app uses SAML2, not Socialite's Facebook JWT flow."
            }
        }
    }
}

Now the decision is documented right where it matters. Anyone reviewing the config can evaluate whether the reason still holds. If you later add Facebook authentication, this line will remind you to revisit the decision, or maybe it's time to take on the major version bump and thoroughly test the app.

The difference between these two approaches is small in terms of effort, but significant in terms of what it communicates. One says "we made this go away." The other says "we evaluated this and made a deliberate decision."

In addition, if you're on Composer 2.9 or greater, as I wrote about in a previous tip, it now actively blocks vulnerable package versions during dependency resolution by default.

To be clear, you might be able to get around this block by narrowing your composer update to just unaffected packages, but it can quickly become a challenge with all the transitive dependencies under the hood of a Laravel app.

So this approach with the audit.ignore config is a valuable tool in these rare circumstances.

As a final takeaway, please think very carefully before just ignoring security advisories, but in the hopefully rare cases where you need it, now you have the tool at your disposal. And you can do it in a clearly documented way.

Here to help,

Joel

P.S. Stuck on a dependency issue you can't easily resolve? Sometimes talking it through with someone who's seen it before is the fastest path forward. Schedule a call and let's figure it out together.

Previous tip