Laravel Security Checker Laravel Package

Product Decisions This Supports

• Build vs. buy for vulnerability scanning: laravel-security-checker wraps the Symfony/local PHP security advisories database in an artisan command, so it's a near-zero-cost build decision. Adopt it rather than building custom advisory ingestion or paying for a heavyweight SCA platform at early stage.
• Release-gate policy: The command's exit code makes "no known vulnerabilities in production dependencies" an enforceable CI gate. This is a product-quality commitment you can put in a Definition of Done and defend in release reviews.
• Risk acceptance with an audit trail (new in v3.1.0): allow_list / LCS_ALLOW_LIST lets you explicitly suppress specific CVEs or exact advisory titles as a tracked configuration artifact. This turns "we know about that one and chose to ship anyway" from tribal knowledge into a reviewable line in .env/deploy config — a decision record PMs and security reviewers can audit per release.
• Faster, cleaner pre-release signal (new in v3.1.0): exclude_dev / LCS_EXCLUDE_DEV removes dev-only dependencies from the check, so the gate reflects actual shipped surface area rather than test tooling noise. Fewer spurious failures means engineers stop treating the check as ignorable — critical for gate adoption.
• Roadmap and dependency hygiene inputs: Repeated scan output feeds decisions like "upgrade framework minor before this feature" or "budget a sprint for dependency remediation," giving you a data-backed counterweight to feature-only roadmaps.
• Compliance and due-diligence enablement: For security questionnaires, SOC 2-adjacent controls, or enterprise procurement reviews, being able to show a scheduled, automated advisory check plus a documented allow-list is a concrete, low-effort control you can cite.
• Failure-mode posture you can plan around: An invalid allow list is ignored and logged as a warning rather than aborting, so scanning never silently stops — a deliberately fail-open-on-config, fail-closed-on-vulnerabilities design that keeps the gate reliable without blocking builds on typos.

When to Consider This Package

Consider adoption when:

• You're on Laravel/PHP and want advisory coverage inside CI with effectively no integration work (one composer dependency, one artisan command).
• You want the vulnerability check to run in the same pipeline as tests/lint, not as a separate vendor dashboard with its own login and alerting model.
• You need a lightweight, explicit risk-acceptance mechanism — allow_list fits teams that want accepted risks versioned next to the code rather than clicked away in a SaaS UI.
• Your dev dependencies are noisy or slow to update (large test/static-analysis trees) and you want the signal scoped to production dependencies via exclude_dev.
• You're pre-Series A / small platform team and a paid SCA product's license and onboarding cost isn't justified yet.

Look elsewhere when:

• You need deep transitive dependency analysis, license compliance, SBOM generation, container/OS-layer scanning, or automated remediation PRs — this package reports advisories, it doesn't fix or fully inventory them.
• You need org-wide dashboards, SLA tracking, or multi-repo aggregation across non-PHP services.
• You require formal policy-as-code, exception expiry dates, or approver workflows — the allow list has no expiry or ownership metadata, so a suppressed CVE can quietly persist; you'd need process discipline (or a richer tool) to counter that.
• Your compliance regime demands signed attestations or vendor support SLAs; this is a community package.
• You can't tolerate the operational detail that suppression lives in env configuration — for teams where .env isn't a governed, auditable artifact, the allow list is only as trustworthy as your config management.

How to Pitch It (Stakeholders)

For executives: This is a small, free addition to our existing Laravel pipeline that automatically checks our production dependencies against the public vulnerability database every time we build. It gives us a hard stop on shipping known-vulnerable code, and — importantly for audits and enterprise deals — a written record of any vulnerability we consciously accepted and why. Effort is roughly a day of setup; the alternative is a paid scanning platform with per-seat licensing and a separate dashboard nobody logs into.

For engineering: Add the package, wire php artisan security-check into CI as a blocking step, and treat the dependency advisory list as part of the build contract. The v3.1.0 additions make this practical: set LCS_EXCLUDE_DEV=true so test and static-analysis tooling doesn't create false failures, and use LCS_ALLOW_LIST with exact CVE IDs or advisory titles when we knowingly accept a risk — single-quoted JSON array in .env, invalid values are logged and ignored so the check never silently dies. Two caveats: the allow list has no expiry, so we should review it each release cycle and remove entries once patched; and this reports advisories, it doesn't remediate them — upgrade work still lands on us. No breaking changes in this release; it's additive over v3.0.0.