Composer Audit Responsibility Laravel Package

Technical Evaluation

netresearch/composer-audit-responsibility is a Composer plugin, not an application-level Laravel package — it has no service provider, no runtime footprint, and no bearing on request handling. Its entire surface is Composer lifecycle behaviour: a post-install/post-update audit gate that fails composer install on known advisories unless the project has explicitly accepted the risk, plus ignore-list injection into composer audit.

Architecture fit. Because it operates at the dependency-resolution/verification layer, it composes cleanly with any Laravel codebase regardless of framework version. The relevant architectural boundary is not Laravel but Composer: the plugin must be registered via config.allow-plugins (mandatory since Composer 2.2), and it inspects composer.json policy keys under policy.advisories, plus the legacy audit.ignore / audit.ignore-severity keys.

What 0.4.1 changes materially. Prior to this release, the most important adoption blocker was governance, not functionality: a globally installed plugin could override a project's explicit risk acceptance and fail that project's composer install. That inverted the normal trust model — a tooling decision made once on a developer machine silently overrode per-project policy decisions made by the team that owns the project. 0.4.1 fixes this in three ways:

1. The post-install gate now honours the root project's own ignores (ignore, ignore-id, ignore-severity, and legacy audit.ignore / audit.ignore-severity), printing the project's stated reason. On Composer 2.10+ the ignore list and matching logic are delegated to Composer itself (PolicyConfig, Auditor::processAdvisories()), scoped to the block operation.
2. Disabling blocking now actually disables it: policy: false, policy.advisories: false, policy.advisories.block: false, and audit.block-insecure: false downgrade the failure to a warning.
3. composer audit ignore-injection was corrected for Composer 2.10, which skips audit.ignore when policy.advisories is set — the plugin now writes platform-only ignores into policy.advisories.ignore-id for audit scope only, preserves the project's own reason for the same advisory ID, and does not re-enable a policy the project disabled.

Technical risk. Three items dominate:

• Pre-1.0 churn. At 0.4.x the configuration schema and blocking semantics are still settling. This very release changed failure behaviour for four distinct config keys. Treat the config contract as unstable and pin versions.
• Coupling to Composer internals. The 2.10+ path depends on PolicyConfig and Auditor::processAdvisories(). Whether these are genuinely public API or internal classes determines how likely a Composer 2.11 minor is to break the plugin. This is the single largest long-term maintenance question.
• Dual code paths. Composer 2.10+ uses Composer's own ignore semantics; older Composer uses a fallback that "mirrors the legacy rules." Two implementations of risk-acceptance logic that must stay semantically aligned is a durable source of subtle divergence.

Key questions for the maintainer / to validate in a spike:

• What is the declared Composer version constraint, and which versions are actually exercised in CI?
• On network failure or advisory-service unavailability, does the gate fail open or fail closed? This determines blast radius on deploy.
• Are PolicyConfig and Auditor::processAdvisories() public API or @internal?
• Is the plugin's own failure a hard composer install abort, and can it be scoped to --no-audit / CI-only?
• Does a global install remain a supported deployment mode now that project policy wins, or is per-project installation the recommended posture?

Integration Approach

Stack fit. Negligible integration surface: one require-dev (or global) dependency plus an allow-plugins entry. It does not touch Laravel's container, config cache, or build pipeline. The real "integration" is constitutional — deciding where risk acceptance lives (per-project composer.json) and who is allowed to author it.

Migration path. Do not enable blocking on day one.

1. Baseline, warn-only. Install with blocking explicitly disabled (policy.advisories.block: false or audit.block-insecure: false — 0.4.1 makes these behave as warnings). Run across the estate and collect the advisory set per repository.
2. Triage and encode. For each advisory, either remediate (bump the dependency) or record an ignore with a mandatory human-readable reason. The reason string is the audit artifact — treat its presence as the review gate, not the ignore itself.
3. Enforce. Flip the block flag per repository once the ignore list is complete and reviewed. Enforcement should be a reviewed diff, not a default inherited from a template.
4. Steady state. Blocking on in CI; new advisories fail the build and force an explicit accept-or-fix decision.

Compatibility. Version skew is the main hazard. A developer on Composer 2.10 and CI on 2.9 will take different code paths and can reach different verdicts on the same commit. Pin the Composer version in CI images and in local tooling, and prefer 2.10+ so the Composer-native policy path is the one exercised. Where the repo sets policy.advisories, verify audit-scope ignores land in policy.advisories.ignore-id rather than audit.ignore, or they will be silently dropped.

Sequencing. Install the plugin and allow-plugins entry first (no behaviour change with blocking off), then the ignore inventory, then enforcement. Because the plugin is Composer-level rather than framework-level, this can proceed independently of any Laravel upgrade work and does not need to be coordinated with application release trains.

Where it does not fit. Projects that vendor dependencies, build on an immutable lockfile with a separate audit stage, or run composer install --no-scripts will get partial or no coverage. Confirm which of those apply before assuming uniform enforcement.

Operational Impact

Maintenance. Two clocks run here. The plugin's own pre-1.0 release cadence (0.4.0 → 0.4.1 already reworked core blocking semantics) and Composer's release cadence, which can invalidate the internals the plugin depends on. Budget for reading the changelog on every plugin bump and for a Composer-version upgrade rehearsal, not just a plugin upgrade. Pin to a patch range and upgrade deliberately.

Support. The plugin lives in the developer/CI tooling lane, so the owning team is platform or DevOps, not application support. Escalation for "my install is blocked" needs a documented, single-step escape hatch (disable blocking, file the exception), otherwise engineers will discover it themselves by removing the plugin — which loses the audit trail entirely. Document the escape hatch explicitly and make it noisy.

Scaling. Cost per CI run is an advisory lookup plus evaluation; the constraint is network and registry availability, not compute. The scaling pressure is organisational: as the number of repositories grows, the ignore inventory becomes a distributed, drifting corpus of risk acceptances with no central view. Expect to need an aggregate report over policy.advisories.ignore entries (advisory ID, reason, owner, age) — the plugin does not provide one. Stale ignores are the failure mode of success here: advisories that were accepted once and never revisited.

Failure modes.

• Deploy blocked by an advisory nobody owns. Correct behaviour, poor outcome if there is no named responder and no documented override. This is the dominant operational risk.
• Silent acceptance creep. Ignores get added under time pressure with reasons like "known, will fix." Reasons are printed but not enforced or reviewed, so the ignore list only grows.
• Composer version divergence. 2.10 vs. older produce different verdicts via the two code paths. Manifests as "passes locally, fails in CI" and erodes trust in the gate.
• The bug 0.4.1 fixes, pre-upgrade. Any estate running ≤0.4.0 with a global install is currently at risk of a tooling-level policy overriding a project-level accepted risk and breaking installs. Upgrading is a governance fix, not just a bug fix — prioritise it if the plugin is installed globally anywhere.
• Audit-scope ignore loss. Pre-0.4.1, projects that set policy.advisories were silently losing platform-only ignores in composer audit on Composer 2.10, understating advisory noise. Verify post-upgrade that the ignore set Composer reports is the intended one.

Ramp-up. Low for installation, moderate for policy design. An engineer can add the dependency and allow-plugins entry in minutes. Getting to a defensible state — reviewed ignore list, documented override, pinned Composer across CI and local, and an owner for advisory triage — is a one-to-two-week effort per repository the first time and materially less thereafter with a template. The 0.4.1 fixes substantially lower the political cost of adoption: the plugin no longer overrides project-level decisions, which was the argument that would have killed it in review. The remaining objections are maturity (0.x) and Composer-internals coupling, both of which are manageable with version pinning but should be recorded as accepted risks rather than assumed away.

Assessment of this release. 0.4.1 is a bug-fix release with outsized implications for adoption: it converts the plugin from "tooling that can silently override project policy" to "tooling that enforces project policy." No new features, no deprecations, no breaking changes signalled — but the behavioural change in blocking semantics is significant enough that anyone on ≤0.4.0 should treat the upgrade as required, and anyone evaluating the plugin should re-evaluate, since the primary adoption objection is now resolved.