A PHP dependency installation can run third-party code before the application starts. Composer plugins can subscribe to installer events and execute inside the Composer process. Build scripts can run commands as well. A compromised package or a dependency choice that pulls in a new plugin can therefore affect the build host, the generated vendor tree, and any credentials visible to the job.

What allow-plugins controls

Composer's allow-plugins configuration decides which plugin packages may run. The setting accepts a list of allowed package names, patterns in newer Composer versions, false to disallow all plugins, or true to allow all plugins. Composer warns when it encounters a new plugin that is not listed. In non-interactive mode, a new unlisted plugin causes installation to fail, which prevents a pipeline from silently making a trust decision.

The safest starting state is false for projects that do not need plugins. A project that does need one should list the exact package and review why it requires the hook. Broad patterns deserve the same review as a wildcard permission.

{
  "config": {
    "allow-plugins": {
      "dealerdirect/phpcodesniffer-composer-installer": true,
      "another-plugin/*": false
    }
  }
}

The example shows the shape of the policy; the repository must decide which package, if any, is approved. The setting belongs with the project so CI and developer installs use the same rule.

Scripts are a different execution path

allow-plugins does not by itself stop scripts entries in composer.json. Composer's documentation separates plugin activation from script execution. A package or root project can define lifecycle commands, and some commands are intended to run during install or update.

For an untrusted dependency source or a forensic replay, Composer documents --no-plugins and --no-scripts to install or update packages without executing third-party Composer code. That is a useful analysis mode. It does not make the resulting vendor directory safe to deploy, because the package code will still execute when the application loads it.

Build a reviewable policy

Capture the effective composer.json, composer.lock, Composer version, and environment variables used by CI. Check whether COMPOSER_ALLOW_SUPERUSER or command-line flags alter the expected behavior. Confirm that install runs as a non-privileged account, with short-lived registry credentials and a workspace that does not expose production secrets.

Alert on new plugin packages, changes to allow-plugins, and scripts added during dependency updates. During incident response, compare the approved plugin list with the packages that actually ran. Review Composer's output and build logs, then inspect the installed package source and any commands it invoked.

The control is narrow by design. It gives the project a deliberate decision at the point where a package can execute code. Pair it with lockfile review, package provenance, vulnerability monitoring, and least-privilege build runners.

References