Composer Security And Supply-Chain Risk

Composer installs third-party code into the application and may execute plugins or scripts. Dependency security includes advisories, abandoned packages, repository trust, credentials, and review of the resolved package graph.

Working Knowledge

• Run composer audit and inspect abandoned-package warnings.
• Allow Composer plugins deliberately through allow-plugins.
• Review scripts before allowing them in CI or deployment.
• Protect private repository credentials and avoid leaking them in logs.
• Review package source, maintainers, release history, and transitive dependencies for sensitive projects.

Allow Plugins Deliberately

Composer plugins execute code inside Composer. Keep the allow-list narrow:

{
  "config": {
    "allow-plugins": {
      "composer/package-versions-deprecated": true,
      "*": false
    }
  }
}

Do not enable every plugin merely to make installation continue. Understand why the project needs each one.

Protect Repository Credentials

Private repository credentials belong in approved runtime or developer credential storage, not committed URLs, shell history, build logs, or copied lock-file metadata.

Review where CI obtains credentials and which repositories they can read. Use the smallest scope that works.

Review The Graph

A direct dependency can pull in many transitive packages. For sensitive projects, review source ownership, release history, repository URLs, scripts, plugins, advisories, and abandoned-package warnings.

Use lock files and trusted artifact processes so production installs the graph that was reviewed and tested.

In Application Work

A package installation is a code-execution decision. Apply more scrutiny to plugins, framework extensions, deployment tooling, and packages with broad runtime privileges.

What To Check

Before moving on, make sure you can review a plugin allow-list, protect private repository credentials, inspect transitive dependencies, and explain why installation is a supply-chain boundary.