Context

The block-insecure feature in Composer 2.9 is a great step for PHP ecosystem security. However, it creates a real pain point for library and extension developers: advisories in transitive dependencies pulled in by the framework block CI — and the library developer has no way to fix them.

Example from the TYPO3 ecosystem:

• Extension requires typo3/cms-core (it has to — it's a TYPO3 extension)
• typo3/cms-core → typo3/cms-backend → firebase/php-jwt
• firebase/php-jwt gets advisory PKSA-y2cr-5h3j-g3ys
• Extension CI breaks — the developer can't update firebase/php-jwt because it's constrained by typo3/cms-core
• Only the TYPO3 core team can fix this by releasing a new core version

This happens across every framework ecosystem: Symfony bundles, Drupal modules, Laravel packages, Shopware plugins (see #12628), WordPress plugins, etc.

What people do today

1. Disable the check entirely: COMPOSER_NO_SECURITY_BLOCKING=1 — silences all advisories, including ones in dependencies the developer controls and should fix.

2. Manually maintain config.audit.ignore: Every new advisory requires a commit to every affected repo. With dozens of extensions and frequent advisories, this becomes a constant maintenance burden. Stale entries accumulate, and nobody reviews whether they're now hiding a vulnerability in a dependency the developer does control.

Both approaches share the same flaw: they treat security as all-or-nothing when the real question is who is responsible for which dependency.

The concept: Responsibility propagation

Security responsibility follows the dependency chain:

The idea is to classify every installed package by ownership using graph analysis:

1. Detect the framework packages (from type field or explicit config)
2. BFS from framework roots → all packages reachable through the framework
3. BFS from user roots (direct requires minus framework), treating framework packages as opaque barriers — don't traverse into them
4. Classify: packages reachable only through the framework are "platform-only" — their advisories should not block the library developer

The diamond problem (package reachable via both paths) uses a conservative rule: if the developer has any dependency path to a package, it's their responsibility. This prevents false negatives.

Working proof-of-concept

I've built this as a Composer plugin: netresearch/composer-audit-responsibility (Packagist)

It hooks PRE_COMMAND_RUN, fetches current advisory IDs from the Packagist Security Advisories API, and injects platform-only advisory IDs into config.audit.ignore at runtime. No manual maintenance needed.

Tested against a real TYPO3 extension — correctly identified 49 platform-only transitive packages and auto-suppressed the firebase/php-jwt advisory while keeping all user-owned dependencies blocking.

Known limitation

As @stof noted in #12628, there's a chicken-and-egg problem: the block-insecure PoolBuilder check runs during dependency resolution, before a newly-required plugin can execute. This plugin works when it's already in the lock file (the typical case for composer install in CI), but can't help on the very first composer update that adds it. A --no-security-blocking flag on that initial install is needed.

This is one reason why native Composer support would be better than a plugin.

What could native support look like?

A possible composer.json section:

{
    "config": {
        "audit": {
            "responsibility": {
                "upstream": ["typo3/cms-*"]
            }
        }
    }
}

Or automatic detection from the package type — Composer already knows the framework ecosystem from the type field.

With native support:

• No chicken-and-egg problem — runs before dependency resolution
• No Packagist API call needed — Composer already has the advisory data
• Framework maintainers could declare responsibility boundaries in their packages
• The graph analysis is lightweight (BFS over the lock file)

What this is NOT

• Not a way to silence advisories you should fix — your own transitives still block
• Not "disable audit for framework deps" — it classifies each package individually using graph analysis
• Not framework-specific — works for any ecosystem with the same pattern

I'd love to hear thoughts from the maintainers on whether this concept fits Composer's direction, and whether a native config.audit.responsibility section (or similar) would be worth exploring.