If you’ve ever had to scramble to update your Laravel application due to a compromised package, you know how much time and effort can be lost. Recent supply-chain attacks on open-source package ecosystems, including PHP and Go, have highlighted the importance of securing our dependencies. You might recall the panic that ensued when thousands of websites were vulnerable to exploitation because of these compromised libraries.
By the end of this tutorial, you’ll build a robust defense against similar threats. You’ll configure Composer’s built-in dependency protection to ensure only trusted packages and plugins are installed, and implement a system for verifying package integrity with Composer’s own validation and audit tools. With these measures in place, you’ll be better equipped to respond quickly and effectively if a security alert is triggered, minimizing the risk of downtime or data breaches.
Understanding Recent Package Compromise Attacks
In recent years, there has been a surge in package compromise attacks targeting both PHP and Go ecosystems. These attacks involve malicious actors taking control of popular packages on public repositories like Packagist (PHP) and the Go module proxy. Once compromised, these packages can be used to inject malware or backdoors into applications that depend on them.
One notable example is the Packagist.org maintainer account takeover in May 2023, where an attacker used leaked passwords to access four inactive maintainer accounts and pointed 14 packages at forked repositories. The affected packages included doctrine/instantiator and jdorn/sql-formatter, among others.
# Check whether an affected package is in your lock file
composer show --locked doctrine/instantiator
# Find out which of your dependencies pulled it in
composer why doctrine/instantiatorTo understand why such attacks are possible, consider how many developers rely on public repositories for their dependencies. When a popular package is compromised, it can be difficult to determine whether your application has been affected.
In the next sections, we’ll explore practical steps to prevent and detect such attacks in your Laravel applications.
Auditing Your Dependencies with Composer Audit
composer audit is a command built into Composer (since version 2.4) for auditing and securing your Laravel application’s dependencies. It checks every installed package against the security advisories published on Packagist and gives you an easy-to-read report of potential security risks in your project.
First, make sure you’re running an up-to-date version of Composer by running the following command:
composer self-updateNext, decide which lock file and output format the audit should use. You can run it against the packages recorded in composer.lock (rather than whatever is currently in vendor/) and choose a format that suits your CI pipeline:
# Audit the versions recorded in composer.lock
composer audit --locked
# Machine-readable output for CI tools
composer audit --format=json
# Skip require-dev packages
composer audit --no-devThese options tell Composer which dependencies to audit and how to report the results.
To run the audit, navigate to the project root in your terminal and execute the following command:
composer auditComposer will then scan your dependencies and provide a report outlining any potential security issues. This includes packages with known vulnerabilities and packages that have been marked as abandoned by their maintainers. The command exits with a non-zero status code when problems are found, so it can fail a CI build automatically.
Reviewing the audit output will give you valuable insights into securing your Laravel application’s dependencies.
With this step complete, we’ve taken another crucial measure to protect our application from package compromise attacks. In the next section, we’ll delve into configuring Composer’s built-in dependency protection features.
Configuring Composer’s Built-in Dependency Protection
Laravel relies on Composer for dependency management, and Composer provides several built-in protection mechanisms through the config section of your composer.json file. To leverage these features, navigate to your project root directory and open the composer.json file.
{
"config": {
"secure-http": true,
"allow-plugins": {
"pestphp/pest-plugin": true,
"php-http/discovery": true
}
}
}In the configuration above, secure-http (enabled by default) ensures Composer only downloads packages over HTTPS, and allow-plugins lists the only Composer plugins that are permitted to execute code during a Composer run. Any other package that tries to register a plugin is blocked until you explicitly allow it.
To further configure dependency protection, make sure you’re on Composer 2.9 or later. Since that release, composer update, composer require, and composer remove refuse to resolve package versions that are affected by known security advisories, so a vulnerable release can’t silently slip into your lock file. Check your version with:
composer --versionFinally, when installing dependencies in CI or production, install strictly from the lock file and skip package scripts and development dependencies:
composer install --no-dev --no-scripts --prefer-distBecause --no-scripts also skips Laravel’s own post-autoload-dump script, run php artisan package:discover afterwards so package auto-discovery stays up to date.
With these settings in place, Composer will only run trusted plugins, only download over HTTPS, and only install the exact package versions recorded in composer.lock. This prevents unexpected behavior and potential security breaches caused by compromised third-party libraries.
Locking Down Your Composer Configuration
Your composer configuration file (composer.json) holds crucial information about your project’s dependencies and settings. To prevent unauthorized modifications, it’s essential to lock down this file.
Firstly, ensure you’re using the composer.lock file alongside composer.json. The former contains the exact version of each dependency required by your application, while the latter specifies how those dependencies should be fetched from their respective repositories.
Generate or refresh your composer.lock file by running:
composer updateThis will ensure all dependencies are locked to specific versions, along with the exact source commit and download URL of each, in composer.lock. Commit this file and use composer install in every other environment. You can confirm that the lock file is in sync with composer.json at any time with composer validate --strict.
Next, consider removing sensitive information like private repository credentials or API tokens from your composer.json. Composer reads these from a separate auth.json file or from the COMPOSER_AUTH environment variable instead.
To do this, store the credentials with the composer config command, which writes them to auth.json rather than composer.json:
composer config http-basic.repo.example.com your-username your-api-tokenReplace repo.example.com with your private repository’s host and add auth.json to your .gitignore. In CI and deployment environments, you can provide the same credentials through the COMPOSER_AUTH environment variable instead:
export COMPOSER_AUTH='{"http-basic": {"repo.example.com": {"username": "your-username", "password": "your-api-token"}}}'By following these steps, you’ve secured your composer configuration and prevented potential tampering with sensitive information. Remember to regularly review and update your composer.lock file to keep dependencies up-to-date while maintaining security.
Verifying Package Integrity with Composer
Composer doesn’t sign individual packages, but it gives you several built-in ways to verify that what you install is exactly what you reviewed and locked. This helps prevent compromised or malicious packages from being installed on your system.
To start, check that your composer.json is valid and that composer.lock is up to date with it using the composer validate command:
composer validate --strictThis will fail if someone has changed composer.json without updating the lock file, which is a common sign of an unreviewed dependency change.
Next, you can make Composer verify the Composer binary itself. The official composer.phar is signed, and composer self-update checks that signature before replacing your installation. To refresh the public keys it verifies against, run:
composer self-update --update-keysOnce configured, when you run the composer update command on Composer 2.9 or later, Composer will also check each resolved package version against known security advisories before installing it.
To see how this works in action, let’s say we’re trying to install a version of a package that has a published security advisory. Composer will refuse to resolve it and the command fails, and you can then inspect the advisories affecting your current lock file:
# A version with a known security advisory is rejected
composer require vendor/package:1.0.0
# Review the advisories that affect your locked packages
composer audit --lockedIf a vulnerable version is blocked, the fix is to require a patched version rather than to override the check.
This feature provides an extra layer of security for your Laravel application by preventing compromised or malicious packages from being installed. By verifying package integrity with Composer’s built-in tools, you can help protect your application from potential attacks.
Best Practices for Managing Third-Party Libraries in Laravel
When it comes to managing third-party libraries in your Laravel application, there are several best practices you should follow to ensure the integrity of your codebase.
First and foremost, always specify versions of dependencies in your composer.json file using semantic versioning. This ensures that updates to dependencies do not inadvertently introduce security vulnerabilities or compatibility issues.
{
"require": {
"laravel/socialite": "^5.0",
"league/flysystem": "^3.0"
}
}Next, keep your dependencies up-to-date with the latest versions allowed by the constraints in composer.json. You can do this by running composer update regularly and reviewing the changes it makes to composer.lock.
$ composer update --prefer-distAdditionally, commit your composer.lock file to manage dependency versions and ensure reproducibility across environments.
{
"content-hash": "4f0a1e8b5c6d7e89f0a1b2c3d4e5f6a7",
"packages": [
...
]
}Finally, regularly review your application’s dependencies for potential security risks or updates. You can use tools like Snyk to scan your dependencies and identify vulnerabilities.
By following these best practices, you can ensure the security and integrity of your Laravel application’s third-party libraries. This is crucial in maintaining a secure codebase and minimizing the risk of package compromise attacks.
Monitoring and Responding to Security Alerts
As a developer, it’s essential to stay vigilant and proactive in monitoring your application for potential security threats. Once you’ve implemented measures to prevent package compromise attacks, it’s time to focus on detecting and responding to security alerts.
To monitor your application for security vulnerabilities, I recommend using tools like Snyk or OWASP ZAP. Snyk scans your dependencies and ZAP scans your running application, so together they detect potential vulnerabilities, allowing you to address them before they become a problem.
In a Laravel project, you can also use Composer’s built-in audit command to scan your installed dependencies for security vulnerabilities. To do this, run the following command in your terminal:
composer auditThis will analyze your dependencies and report any known vulnerabilities or abandoned packages. You can then review these findings and take corrective action as needed.
When responding to security alerts, it’s essential to act quickly and decisively. Make sure to isolate the affected area of your application, contain the issue, and implement a fix or patch to prevent further exploitation.
By staying proactive and vigilant in monitoring and responding to security alerts, you can protect your Laravel application from potential threats and maintain its overall security posture.
In conclusion, protecting your Laravel application requires ongoing effort and dedication. By following the steps outlined in this tutorial, you’ll be well on your way to securing your application against package compromise attacks.
Frequently Asked Questions
What is a package compromise attack in PHP and Go ecosystems?
A package compromise attack occurs when malicious actors take control of popular packages on public repositories like Packagist (PHP) and the Go module proxy, allowing them to inject malware or backdoors into applications that depend on these compromised packages.
How can I prevent my Laravel application from being affected by a package compromise?
You can use tools like composer audit to audit your dependencies and detect potential security risks. Additionally, regularly update your packages and keep track of known vulnerabilities in your dependencies.
What is the purpose of the --locked option when using composer audit?
The --locked option tells Composer to audit the package versions recorded in composer.lock instead of the packages currently installed in vendor/. This makes the audit reproducible in CI, where it checks exactly what will be deployed for known vulnerabilities.
Can I use an alternative approach, like manually reviewing my package versions, instead of using composer audit?
While manual review can be helpful, it’s not a reliable method to detect all potential security risks. composer audit provides a more comprehensive and efficient way to identify vulnerable and abandoned packages.
What should I do if I discover that one of my dependencies has been compromised?
If you find that a dependency has been compromised, immediately update it to a patched, known-good version or remove it from your project. Also, consider notifying the package maintainers and other developers who may be using the same dependency.