Laravel Risk Analyzer Laravel Package

Getting Started

Install the package as a dev dependency so it is available locally and in CI but absent from production builds:

composer require --dev <vendor>/<package>

If the package ships a Laravel service provider, publish its configuration and review the baseline path, output format, and advisory-source settings:

php artisan vendor:publish --tag=<package>-config

The entry point is typically an Artisan command or a vendor/bin binary. Run it once against the project’s composer.lock before changing configuration — that is the fastest way to see what a vulnerable-dependency finding looks like in your project:

php artisan security:scan
# or
vendor/bin/<binary> scan --format=console

First use case: run the scanner locally on a feature branch, fix or baseline the direct dependencies that matter for the release, and generate the Markdown report to paste into the pull request. The console output now shows the advisory identifier(s), for example (GHSA-wxmh-65f7-jcvw / CVE-2023-29197), and the Markdown output contains the same data in a review-friendly form.

Implementation Patterns

CI gate on pull requests. Run the scanner in a dedicated CI job after composer install --no-interaction. Use the Markdown formatter to produce a report artifact or step summary, and let the exit code fail the job when new findings appear. Keep the console formatter for human-readable job logs.

Baseline accepted risk. Generate a baseline file, commit it, and run the scanner with the baseline enabled. Because fingerprints are stable — v2.0.0 explicitly leaves them unchanged — an accepted advisory stays quiet across upgrades. Review the baseline on a schedule; a baseline that is never revisited becomes an undocumented risk register.

php artisan security:scan --generate-baseline
php artisan security:scan --baseline=security-baseline.json

Composer script for developers. Add the scanner to composer.json scripts so it always runs against the same lock file the application uses:

"scripts": {
  "security:check": "@php artisan security:scan --format=console"
}

Then composer security:check works locally and in CI without remembering the binary path.

Markdown for review workflows. In GitHub Actions, write the Markdown report to $GITHUB_STEP_SUMMARY or post it as a PR comment. This is more useful now that CVE IDs are included: reviewers recognize CVE-2023-29197 more readily than a GHSA/OSV-only identifier, and the Markdown output keeps the advisory URL and affected package visible in one place.

Scope the scan. Decide whether dev dependencies are in scope. Many teams scan production dependencies in the deploy gate and scan the full lock file in a scheduled nightly job. If the package supports --no-dev or a Composer --no-dev install, align the scanned dependency set with what actually ships to production.

Layer with other checks. Treat this as one security layer: pair it with composer audit/composer validate, static analysis, and container scanning. The package’s value is the OSV-backed advisory data and the baseline mechanism, not a replacement for dependency-update automation such as Dependabot or Renovate.

Gotchas and Tips

• Baseline fingerprints are unchanged in v2.0.0. You do not need to regenerate baselines for this release. Do not “fix” a noisy baseline by regenerating it blindly; that hides new findings.
• The CVE display is a display change. v2.0.0 now renders (GHSA-… / CVE-…) in console and Markdown output. If a script or dashboard parses the old single-ID format with a regex, update the parser. The advisory identity and fingerprint are unchanged, so baseline and exit-code behavior should not change.
• Not every advisory has a CVE. The new format shows a CVE only when the OSV record maps to one; otherwise you will see the GHSA/OSV ID alone. Do not assume the absence of a CVE means the finding is minor.
• Ensure composer.lock exists and matches composer.json. The scanner reads the lock file. Run composer install or at least composer update --lock before scanning; otherwise you may scan stale or missing dependency data.
• Network and rate limits. OSV-backed scanners call an external API. Cache results in CI where possible, and provide a fallback or pinned advisory database if the API is unavailable during a release.
• Baseline hygiene. Remove baseline entries when the underlying package is upgraded past the vulnerable range; otherwise the baseline silently suppresses a future regression in the same advisory.
• Version 2 major bump. The release note documents the CVE display change, but a major version can still carry platform requirements (PHP/Laravel version) or config-key changes. Check the upgrade guide and run the scanner in a branch before merging.
• Exit codes in CI. Confirm the scanner’s exit-code semantics (0 clean, non-zero findings or error). Distinguish infrastructure/network errors from actual vulnerabilities so CI failures are actionable.
• Markdown escaping. Advisory titles and package names can contain characters that break tables or links. Preview the Markdown once before relying on it in PR comments.