- How do I install jorijn/laravel-security-checker in a Laravel app?
- Install it with Composer via composer require jorijn/laravel-security-checker, then publish the package config file and set the relevant environment variables for your notification channels. There are no database migrations or schema changes, so setup is limited to config plus scheduling the Artisan command. After that you can run the check manually or let the scheduler handle it.
- Which Laravel versions does laravel-security-checker support?
- The package tracks current Laravel releases and is auto-discovered through Laravel's package discovery, so no manual service provider registration is needed. Check the composer.json constraint in the repository for the exact supported framework and PHP versions before upgrading a legacy app. Version 3.1.0 is a minor release with no breaking changes, so it is a drop-in update within the v3 line.
- How do I schedule the security check to run automatically?
- The package exposes an Artisan command plus a scheduler hook, so you can add it to your app's console kernel or routes/console.php schedule with a frequency such as daily. The check is a cron-shaped batch job, so it fits naturally alongside your existing scheduled tasks and can be queued if you prefer. Scheduling it is the recommended way to catch new advisories against dependencies you already ship.
- Which notification channels can Laravel Security Checker use for alerts?
- Alerts can be delivered through email, Slack, Telegram, and Discord, using Laravel's existing notification stack. Because it reuses the framework's notification system, channel credentials and routing follow the same conventions you already use elsewhere in the app. You can also run the command without notifications when you only want console output.
- What does the exclude_dev option do?
- exclude_dev removes advisories against require-dev dependencies from the results, which eliminates a common source of noise in production-focused pipelines. It maps cleanly onto a two-stage setup where development builds and production artifacts are audited differently. Confirm whether your version changes what is audited versus only what is reported, since those have different assurance implications for your team.
- How do I ignore or allow-list a known vulnerability?
- Version 3.1.0 adds an allow_list setting, configured as a single-quoted JSON array in your .env file, which lets you accept risk on specific advisories instead of leaving the build permanently red. Be careful with quoting, since secret managers and CI variable injection are frequent sources of silent misconfiguration here. Matching is generally by advisory title, which is more fragile than CVE identifiers, so prefer stable identifiers where possible and review entries periodically.
- Can I use laravel-security-checker as a CI gate instead of just an alerting tool?
- Yes. Running the Artisan command in your pipeline gives you a governable gate, and the exclude_dev and allow_list options added in 3.1.0 make that practical by suppressing dev-only noise and accepted risks. Without an allow list, every accepted advisory becomes a permanently failing build, which tends to push teams to disable the check altogether. Pair the gate with a documented review process so the allow list does not silently grow.
- What happens if my allow_list JSON in .env is malformed?
- An invalid allow list is logged as a warning and the check still runs, which is a deliberate fail-open choice so a typo never silently disables scanning. The practical consequence is that you get more findings rather than fewer, and the warning competes with normal log volume. Route package warnings to a durable destination such as your log aggregator or an alerting channel so misconfiguration is noticed.
- How is this different from running the Enlightn Security Checker directly?
- This package is a thin, Laravel-native wrapper around the Composer dependency vulnerability audit, using the FriendsOfPHP security advisories database, so you get the same underlying checks without writing custom glue code. The value it adds is the Artisan command, scheduler integration, config and env conventions, and notifications through mail, Slack, Telegram, and Discord. If you already have a bespoke audit script wired into CI, the main gain is maintenance and framework-native ergonomics.
- What are the long-term risks of maintaining an allow list?
- Allow list entries have no expiry, reason, owner, or ticket reference, so nothing forces re-review and coverage can decay without any visible signal. Title-based matching is also brittle, since upstream advisory titles get edited and a reworded title silently un-suppresses a finding. Treat the list as governed configuration: prefer CVE identifiers, record justification, and schedule periodic reviews so suppressed findings remain accepted decisions rather than blind spots.