- What is elohim/laravel-security-check and what does it do?
- It is a dev-time security validator for Laravel projects that scans your application for common vulnerabilities, configuration misconfigurations, and risky dependencies. It then reports actionable fixes so you can harden the app before deployment. It focuses on Laravel configuration posture such as APP_DEBUG, APP_KEY, session and cookie flags, TLS enforcement, and exposed debug tooling.
- How do I install elohim/laravel-security-check in a Laravel project?
- Install it as a development dependency with composer require --dev elohim/laravel-security-check and then run the provided Artisan command. There is no service, credential, or migration involved, so the setup is mechanically simple. Because the package is a static validator, it belongs in require-dev rather than your production dependencies.
- Does laravel-security-check run at runtime or only in development and CI?
- It is a development and CI-time static configuration validator, not a runtime dependency. It does not register middleware, sit in the request path, or alter application behaviour, so its architectural blast radius is close to zero. You run it manually or in a pipeline and act on its report.
- Which Laravel and PHP versions does this security checker support?
- The project does not publish a detailed compatibility matrix in its overview, so check the composer.json constraints in the repository before adopting it. The 1.0.1 release is a class-renaming tidy-up rather than a compatibility or Laravel-version-tracking change. If you are on a recent Laravel major, verify that the ruleset actually understands current framework defaults.
- Does the command return a non-zero exit code so I can use it as a CI gate?
- This is not clearly documented, and it is the single most important thing to verify before wiring it into a pipeline. If the command only prints a human-readable table and exits 0 on findings, you would need a brittle stdout-parsing wrapper to fail a build. Test it with a deliberately broken fixture and confirm you get a deterministic non-zero exit, ideally with a configurable severity threshold.
- Does laravel-security-check support JSON or machine-readable output?
- Structured output is listed as an open question for the package rather than a confirmed feature. A JSON mode matters if you want dashboards, trend tracking, or drift detection across environments. If only a human table is available, plan to capture and parse stdout conservatively.
- How is this different from composer audit, Enlightn, or Larastan?
- Dependency CVE scanning tools such as composer audit and roave/security-advisories check package versions, while Larastan focuses on static analysis of your code. This package targets Laravel configuration posture, which is a different and often under-served gap. It does overlap with opinionated analysers like Enlightn, so confirm scope overlap before adopting it, since the value case collapses if Enlightn is already in your pipeline.
- Can I ignore specific checks or add custom rules per environment?
- Ruleset configurability, allowlists, and custom rules are not confirmed in the available documentation. Multi-tenant, multi-environment, and intentionally permissive staging setups are the most likely sources of false positives, and security tooling that cries wolf gets muted. Verify whether you can suppress individual checks without forking the package.
- Will installing elohim/laravel-security-check affect my production application?
- No, as long as you keep it in require-dev, because it does not sit in the request path or change application behaviour. The only real risks are pipeline-related: depending on whether it inspects files statically or boots the framework, CI may need a synthetic .env with a valid APP_KEY. Watch for false negatives too, since a rule that silently skips makes the pipeline green with no signal.
- Is elohim/laravel-security-check actively maintained and should I pin the version?
- The project has roughly 60 stars and no known dependents, so there is very little downstream production evidence. The 1.0.1 release shows the maintainer is still committing, but it was a class renaming in a patch release, which is technically a breaking change for anyone extending those classes. Pin exact versions and treat upgrades as reviewed changes rather than automatic bumps.