- How do I install psecio/versionscan in a Laravel application?
- Install it as a dev dependency with composer require --dev psecio/versionscan, then run the binary from vendor/bin. It registers no service provider and does not touch the request path, so nothing changes in your application's runtime behaviour. In practice you invoke it manually on a branch first, then wire it into CI as a pre-deploy step.
- Does VersionScan support PHP 8.3 and 8.4, and which Laravel versions does it work with?
- VersionScan is framework-agnostic, so Laravel version compatibility is not the real constraint; the PHP binary the scanner itself executes on is. There is no verified confirmation in the available assessment that the tool runs cleanly on PHP 8.2 through 8.4, so test it on the exact PHP image your CI uses before adopting. A scanner pinned to an older PHP major will simply fail to execute in a modern container.
- How is VersionScan different from composer audit?
- Composer audit reports vulnerable Composer packages, while VersionScan reports your declared PHP runtime and installed extensions against a vulnerability dataset. They cover different layers and are complementary controls. Conflating the two is the most common evaluation mistake: use composer audit and Laravel advisory feeds for packages, and VersionScan for the PHP version you are allowed to deploy on.
- Can VersionScan fail a CI build when it finds a vulnerable PHP version?
- That is the intended integration, but you must verify the exit code contract first, because gating on unreliable exit statuses creates false confidence. Confirm the tool returns a non-zero code on findings and exposes a stable machine-readable output you can parse. A safe rollout is non-blocking for two to four weeks to capture findings and triage false positives before you make the check blocking.
- Does VersionScan read composer.lock or only composer.json?
- This is not documented in the available evaluation and should be treated as an open verification item. Reading composer.lock gives accurate resolved versions, whereas reading composer.json only gives constraint ranges such as caret ranges that are more prone to false positives. Spend half a day confirming this against a real project before you rely on the results.
- How often is the VersionScan vulnerability database updated?
- The refresh cadence of the underlying CVE dataset is opaque from the outside, and this is the single most important question to resolve. A version scanner with stale data is worse than no scanner because it manufactures false assurance in a green CI check that reviewers trust. Ask upstream what the CVE source is and how it is refreshed relative to PHP security releases, and consider pinning or vendoring the dataset so CI results are reproducible.
- Should I use VersionScan at runtime in production?
- No. VersionScan is a developer-time CLI scanner, not a runtime library; it does not enter the request path and carries no framework coupling. Run it locally, in CI, or as a pre-deploy gate. Treating it as an application component would add dependency surface for no runtime benefit.
- Does VersionScan check installed PHP extensions as well as the PHP version?
- Yes. The scanner compares both your PHP version and your installed extensions against a database of known security vulnerabilities, flagging outdated or unsafe releases. This matters for multi-app portfolios where extension drift is easy to miss. For a single application already on a current, patched PHP release, the marginal value is low and it functions largely as a compliance artifact.
- What are the alternatives to VersionScan for PHP security scanning?
- Composer audit and Laravel's advisory feeds handle vulnerable packages, but they do not evaluate the PHP runtime itself. VersionScan's specific niche is flagging end-of-life or unpatched PHP versions and extensions. Many teams end up running both, treating package advisories and runtime version checks as separate quality gates.
- Is psecio/versionscan actively maintained, and what license does it use?
- Adoption is modest at roughly 249 stars with apparent single-maintainer concentration, so check commit cadence over the last twelve months and open-issue response times before committing. The repository location is listed as unknown in this assessment, and license terms still need confirming for your organisation. Because it is a dev-only, additive dependency, reversing the decision is as simple as removing one Composer entry.