Supply Chain Security: Hardening npm postinstall and Composer Scripts

During a routine audit of our CI/CD pipeline last month, I noticed our build times had crept up by about 45 seconds. It wasn’t a heavy compilation step or a bloated image; it was a deep-nested dependency running an obscure postinstall script every time we deployed. That’s when the reality of supply chain security hit home: we were blindly executing arbitrary code from third-party packages every time a developer ran npm install.

We’ve all grown comfortable with the convenience of automation. You run npm install or composer install, and the package manager handles everything. But those lifecycle scripts—preinstall, postinstall, pre-autoload-dump—are essentially open doors for code execution. If a maintainer’s account is compromised, or a package is typosquatted, your server is the next victim.

The Problem with Implicit Execution

When you run npm install, the package manager executes scripts defined in the package.json file without asking for permission. Similarly, composer runs scripts defined in composer.json. This is intended for build-time tasks, like compiling assets or generating documentation. However, it’s a massive attack vector.

We first tried to solve this by manually inspecting the node_modules tree, but that failed because nested dependencies are often hundreds of levels deep. We realized that preventing malicious dependencies required a shift from "trust by default" to "verify by policy."

Hardening npm postinstall Hooks

In the Node.js ecosystem, npm (and yarn) lets you define scripts that run automatically. To secure your environment, you should stop executing these scripts globally.

If you're using npm, you can use the --ignore-scripts flag during installation:

Bash
# Safely install dependencies without triggering lifecycle scripts
npm install --ignore-scripts

If you need specific packages to run their scripts, you’re forced to be explicit. It’s a bit of a manual lift, but it’s the only way to be sure. I prefer using npm-run-all or husky in specific, audited ways rather than allowing every package to define its own execution path.

Securing Composer Scripts in PHP

PHP’s composer is slightly more transparent, but it’s just as dangerous. A malicious package can hook into post-install-cmd or post-autoload-dump.

I’ve moved to a strict "no-scripts" policy in our production build pipelines. We use the following configuration in our composer.json to disable scripts entirely during the deployment phase:

JSON
{
    "config": {
        "allow-plugins": {
            "vendor/package-name": false
        }
    },
    "scripts": {
        "post-install-cmd": [],
        "post-update-cmd": []
    }
}

By explicitly clearing these arrays, you prevent any package from hijacking the installation process. If your application requires a specific build step, run it as a separate, isolated job in your CI pipeline rather than as part of the dependency installation.

Comparing Security Strategies

When choosing how to lock down your environment, consider the trade-offs between convenience and safety.

Why This Matters for Your Supply Chain

Supply chain security isn't just about scanning for known vulnerabilities; it's about controlling what runs in your environment. If you haven't yet, you should revisit Dependency Confusion Attacks: Securing Your Node.js and PHP Supply Chains to ensure you aren't pulling in malicious packages from public registries.

I’ve also found that auditing the package-lock.json or composer.lock files is crucial. If I see a package I don’t recognize, I don't just delete it; I track it back to the require statement. If it’s a dev dependency that doesn't need to run code at install time, I remove it.

What I’m Still Figuring Out

Honestly, I’m still struggling with the balance between developer velocity and this level of paranoia. Disabling scripts breaks a lot of modern tooling, specifically things like husky for git hooks or prisma for database schema generation.

My current compromise is to allow scripts only in local development environments and strictly enforce --ignore-scripts in CI/CD. It’s not perfect, but it’s a hell of a lot safer than letting an unknown dependency write to my production environment's disk.

Next time, I want to explore container-based sandboxing for npm install steps, so even if a script does execute, it has zero access to the host file system or environment variables. We aren't there yet, but it’s the logical direction for any team serious about protecting their build pipeline.