Dependency Vulnerability Scanning Setup

By Kokil Thapa | Last reviewed: August 2026

A proper dependency vulnerability scanning setup is the single most effective control you can add to a PHP or Node.js project today. Most breaches I investigate in Nepal and globally stem not from custom code flaws but from unpatched third-party packages with known CVEs. Whether you maintain a Laravel SaaS platform, a WooCommerce store, or a legal-tech portal, automating this detection prevents shipping compromised code. This guide covers the exact configuration I use across production systems to catch vulnerabilities before they reach your server.

How Do You Configure Native Dependency Vulnerability Scanning Setup for PHP and Node?

Before adding external services or paid SaaS platforms, exhaust the capabilities built directly into your package managers. Modern versions of Composer and npm have significantly improved their native auditing, making them the first line of defense in any Laravel developer's security toolkit. These tools check your installed packages against public vulnerability databases like GitHub Advisory and Packagist without requiring API keys or network calls to proprietary servers.

Composer Audit for PHP Projects

Since Composer 2.4, the audit command has been stable and reliable. On any project running PHP 8.2+ with Composer 2.7+, this should be part of your daily workflow. Unlike older third-party plugins, it respects your composer.lock file exactly, meaning it reports vulnerabilities for the specific versions you have pinned, not just the latest available.

<!-- Run a standard audit -->
composer audit

<!-- Return non-zero exit code on HIGH severity (for CI) -->
composer audit --severity=high

<!-- Output as JSON for parsing in pipelines -->
composer audit --format=json

<!-- Ignore specific advisories with documented justification -->
composer audit --ignore=GHSA-xxxx-xxxx-xxxx

In practice, I configure --severity=high as the default failure threshold for client projects. Low and moderate severity issues often represent theoretical risks or edge cases that don't apply to your specific usage pattern. Blocking every low-severity advisory leads to alert fatigue, causing teams to disable scanning entirely. Document ignored advisories in a .composer-audit-ignore file or your CI configuration with a comment explaining why the risk is acceptable.

npm Audit for Node.js Frontends

For Laravel applications using Vite 6.x or standalone Node.js services, npm audit remains the baseline. However, its default behavior can be noisy because it includes devDependencies and transitive dependencies you may never execute in production. Use the --production flag to focus on runtime risk.

<!-- Audit only production dependencies -->
npm audit --production

<!-- Fail CI only on critical/high severity -->
npm audit --audit-level=high

<!-- Generate detailed report for review -->
npm audit --json > audit-report.json

A common mistake is treating npm audit fix as a safe automatic solution. In my experience working on production Laravel applications with complex frontend builds, blind auto-fixes frequently break Vite configurations or introduce breaking changes in major version bumps. Always review proposed fixes manually. If a fix requires a semver-major upgrade, treat it as a separate task with proper testing rather than an automated patch.

What Is the Best Automated CI/CD Dependency Vulnerability Scanning Setup?

Local scans protect individual developers, but only CI enforcement protects the project. A reliable CI/CD pipeline must treat vulnerability scanning as a blocking gate, not an informational warning. I typically implement this using GitLab CI or GitHub Actions, depending on the client's infrastructure. The key principle is consistency: the same command that fails CI should also be runnable locally so developers can reproduce and fix issues before pushing.

GitLab CI Configuration Example

For the sister sites I maintain on shared EC2 infrastructure (including legal-tech portals like Notary Kathmandu and Court Marriage In Nepal), the following GitLab CI job runs on every merge request and nightly on the main branch. It uses the official Composer Docker image to ensure a clean environment.

security_audit:
  stage: test
  image: composer:2.7
  script:
    - composer install --no-interaction --no-progress
    - composer audit --severity=high --format=json > audit-results.json
    - |
      if [ -s audit-results.json ]; then
        echo "❌ High severity vulnerabilities detected"
        cat audit-results.json
        exit 1
      fi
  artifacts:
    paths:
      - audit-results.json
    expire_in: 30 days
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"
      when: always

Note the artifact retention. Keeping audit results for 30 days allows you to track whether vulnerability counts are trending up or down over time, which is useful for reporting to non-technical stakeholders who need evidence that security hygiene is improving.

Handling False Positives and Acceptable Risk

No scanner is perfect. You will encounter false positives or vulnerabilities that are technically present but practically unreachable in your application. Create an allowlist mechanism rather than disabling the scanner. In Composer, use the --ignore flag with specific GHSA identifiers. In npm, use the .npmrc audit-level or override resolutions. Always document the rationale next to the ignore rule. Undocumented ignores become technical debt that future maintainers cannot safely evaluate.

How Do You Handle WordPress and Legacy PHP Dependency Vulnerability Scanning Setup?

WordPress presents unique challenges because many installations still rely on plugin directories rather than Composer-managed dependencies. Standard composer audit won't detect vulnerabilities in plugins installed via wp-admin. For these projects, your dependency vulnerability scanning setup requires specialized tooling. This is particularly relevant for Nepali businesses running WooCommerce stores where plugins handle payments, bookings, or local integrations like eSewa and Khalti.

WP-CLI Vulnerability Scanner

The wp-cli/vulnerability-scanner package checks installed plugins and themes against the WPScan vulnerability database. Install it as a global WP-CLI package and run it as part of your deployment verification or scheduled maintenance.

<!-- Install the scanner -->
wp package install wp-cli/vulnerability-scanner

<!-- Scan all plugins and themes -->
wp vuln status

<!-- JSON output for CI integration -->
wp vuln status --format=json

<!-- Check only active plugins -->
wp vuln plugin status --active-only

For managed WordPress hosting environments where you cannot install WP-CLI packages globally, consider the Wordfence CLI or Sucuri SiteCheck as alternatives. However, WP-CLI integrates most cleanly into automated deployment pipelines using Deployer 7, which I use extensively for WordPress clients.

Roave Security Advisories for Non-Lock Composer Projects

Legacy PHP applications sometimes lack a composer.lock file or use outdated dependency constraints. Adding roave/security-advisories as a dev dependency prevents installation of known-vulnerable package versions at the resolver level. This acts as a preventive control rather than a detective one.

composer require --dev roave/security-advisories:dev-latest

This approach has limitations: it only blocks installation, not runtime detection, and it can cause dependency conflicts in older projects. Use it alongside, not instead of, active scanning. For modern Laravel 12.x or Symfony 7.x applications with proper lock files, native composer audit is superior.

When Should You Add Commercial Scanners to Your Dependency Vulnerability Scanning Setup?

Native tools cover public CVEs effectively, but commercial scanners add value in specific scenarios: private package repositories, license compliance requirements, reachability analysis (determining if vulnerable code is actually callable), and regulatory compliance like PCI-DSS for eCommerce sites handling credit cards. For most small-to-medium Laravel or WordPress projects in Nepal, native tooling plus disciplined processes is sufficient. Commercial tools become justified when your risk profile or compliance obligations exceed what public databases provide.

If you're building a custom eCommerce platform processing payments through ConnectIPS or IME Pay, PCI-DSS requirements may mandate commercial-grade scanning with attestation. Budget accordingly — expect NPR 30,000–80,000 annually (~USD 225–600) for adequate coverage. For informational sites, legal-tech portals, or internal tools, free tiers combined with rigorous native scanning typically satisfy due diligence requirements.

How Do You Maintain a Sustainable Dependency Vulnerability Scanning Setup Long-Term?

The hardest part isn't initial setup — it's preventing the system from becoming noise that developers ignore. Sustainability requires three practices: severity-based gating, scheduled reviews, and update discipline.

1. Gate on severity, not volume. Block CI only on high/critical vulnerabilities. Log medium/low for weekly review. This keeps the feedback loop tight for genuine emergencies while batching lower-priority items into manageable maintenance windows.
2. Schedule dependency update sprints. Allocate 2–4 hours monthly specifically for addressing accumulated advisories. Treat this as planned work, not emergency firefighting. For clients on retainer, include this in your maintenance agreement explicitly so expectations align.
3. Pin and verify, don't float. Always commit lock files. Use exact versions for critical dependencies. Test upgrades in staging before production. Automated PRs from Dependabot or Renovate are useful but require human review — never enable auto-merge for security updates without passing your full test suite.
4. Document your ignore decisions. Every ignored advisory should have a timestamp, GHSA ID, and written justification stored in version control. Review ignores quarterly. Vulnerabilities that were acceptable six months ago may become exploitable as your application evolves.
5. Monitor upstream channels. Subscribe to security mailing lists for your core frameworks (Laravel Security Advisories, WordPress Security Releases). Scanners have lag; official announcements give you hours or days of advance notice before CVEs propagate to databases.

Implementing Your Dependency Vulnerability Scanning Setup Today

Start with what you already have. Run composer audit and npm audit --production on your current projects this afternoon. Document what you find. Add the CI gate configuration shown above to your next sprint. Resist the urge to fix everything immediately — triage by severity and business impact. For WordPress sites, install the WP-CLI vulnerability scanner and schedule weekly checks. Only after these foundations are solid should you evaluate commercial tools or advanced features like reachability analysis.

Security is a practice, not a product. A well-maintained native dependency vulnerability scanning setup outperforms a neglected expensive tool every time. If you need help implementing this for your Laravel, WordPress, or Node.js project — especially in contexts where budget and team size constrain your options — reach out to discuss your specific situation. I've helped teams across Nepal and internationally establish sustainable security practices that survive real-world operational pressures.