How do you vet a Packagist package before you install it?

Before you run composer require, confirm the package name is the one you meant, read its source repository, look at who maintains it, and inspect any scripts or plugins in its composer.json. Then install from a committed lock file and run composer audit. Packagist lists packages; it does not vouch for them.

What does Packagist actually promise?

Packagist describes itself as the default Composer package repository: it lets you find packages and tells Composer where to get the code. Its front page says it aggregates public packages that anyone can install with Composer. That is a directory, and the word "anyone" applies to publishers as well as users. A listing there is not a review.

Composer's own documentation explains the naming scheme. A package name has a vendor name and a project name joined by a slash, and the vendor part exists to prevent naming conflicts. That is a naming convention, not a trust signal. Two packages can look alike on a line of output.

Which checks are worth the time?

Imagine a constructed case. A teammate adds acme-labs/pdf-forms to generate invoices. Your usual library is acmelabs/pdf-forms. One hyphen apart, same description, a README copied from the real one. Here is what catches it.

1. Read the full name aloud. Compare vendor and project against the documentation you followed, character by character. Typosquats rely on a glance.
2. Follow the source link. Open the repository the listing points to. Does it match the project you know? Does the history go back further than a few days? A brand new repository with a polished README and one commit deserves suspicion.
3. Check the maintainers and the organization. Is the vendor an account you recognize from the project's own site or documentation? Cross-check from the project's website, not from the listing itself.
4. Read composer.json. Look for the scripts section and for plugins. Composer documents --no-scripts, which skips scripts defined in composer.json, and --no-plugins, which disables plugins. Their existence tells you what a package can run on your machine at install or update time.
5. Look at the dependencies it pulls in. A small formatting library that requires five unfamiliar packages has more attack surface than its size suggests.
6. Check whether it is abandoned. Composer reports abandoned packages as part of its audit output, and the project documents an environment setting for how to treat them. Abandoned does not mean unsafe today, but nobody will fix tomorrow's bug.

None of this requires special tools. It takes ten minutes, and you only do it when adding a new direct dependency.

What should the install workflow be?

The Composer docs say you should commit your composer.lock file, so that your CI server, production machines and teammates all run the exact same dependency versions. That also stops a quiet change of version between your review and your deploy.

Then use the audit features. Composer's install and update commands accept --audit to run an audit after installation, with several output formats. The documentation also describes policy based blocking: the --no-blocking option disables blocking for packages with advisories, that are abandoned, or that are still in a cooldown period. The existence of that cooldown setting suggests a useful habit: do not adopt a version within hours of publication unless you need a fix. Check the current Composer documentation for the exact policy configuration in your version before you rely on it.

What about packages you already have?

Run the same questions on your existing lock file once. Sort by packages you do not remember adding, and begin there.

What to do

1. Compare the package name to the documentation you followed, character by character.
2. Open the source repository and check its age, history and maintainers.
3. Read composer.json for scripts, plugins and dependencies.
4. Commit composer.lock and install from it in CI.
5. Run composer audit locally and add --audit or a separate audit step in CI.
6. Avoid adopting brand new versions without a reason.
7. Review the lock file diff in every pull request that changes it.

Safeguard can scan a composer.lock for known vulnerable and malicious packages, and its free scan at gold.safeguard.sh/scan checks up to 100 dependencies in the browser. The human checks above still catch the lookalike name.

Quick check

Sources

• Packagist
• Composer: Basic usage
• Composer: Command-line interface

Last reviewed: 18 October 2026.