Laravel Risk Analyzer Laravel Package

Product Decisions This Supports

• Release-gating and CI policy: the package produces vulnerable-dependency findings with stable baseline fingerprints, which is what lets a PM choose between "fail the build on any known advisory" and "fail only on new advisories since the accepted baseline." That is a product decision with real friction trade-offs, and this tool makes the noise-suppression option concrete rather than aspirational.
• Build vs. buy for security reporting: a thin, Composer-native scanner that already speaks OSV and emits both console and Markdown means you don't staff a bespoke audit script. The Markdown output is the deciding artifact — it is the thing that can be pasted into a release ticket, a PR comment, or a customer security questionnaire without a human rewriting it.
• Compliance and disclosure workflows: v2.0.0 surfaces the advisory's CVE id beside its OSV/GHSA id (e.g. (GHSA-wxmh-65f7-jcvw / CVE-2023-29197)). CVE is the identifier auditors, procurement, and customers recognize; GHSA/OSV ids are what tooling recognizes. Carrying both in one string removes a manual cross-reference step from vulnerability-disclosure and vendor-review processes.
• Roadmap sequencing on security debt: because fingerprints are unchanged, an existing baseline remains a valid record of "accepted risk as of date X." That gives you a defensible audit trail for deferring upgrades — you can show what was known, what was accepted, and what is newly surfaced, per release.
• Use cases to plan around: pre-release dependency audits, upgrade-PR validation, periodic drift checks against a committed baseline, and generating per-release security appendices for enterprise or regulated customers.
• Explicit non-goal: this is a dependency/advisory scanner, not runtime or first-party code analysis. Don't let it occupy roadmap space reserved for SAST/DAST; treat it as supply-chain hygiene only.

When to Consider This Package

Consider adoption when:

• The stack is PHP/Laravel with Composer-managed dependencies, and security review currently happens ad hoc or not at all.
• You need baseline-aware diffing — you have a legacy codebase with a large, accepted backlog of advisories and cannot adopt a scanner that reports everything on every run. Unchanged fingerprints across releases are the key property here.
• A consuming artifact (Markdown, console) matters: results need to land in PRs, tickets, or customer-facing documents rather than a vendor dashboard.
• You want OSV-backed advisory data without paying for a commercial SCA feed, and you're comfortable with OSV's coverage characteristics.
• You want a low-ceremony tool an engineer can wire into CI in an afternoon.

Look elsewhere when:

• You need container image scanning, IaC scanning, secret detection, or first-party static analysis — this addresses one layer only.
• You require a commercially supported feed with SLAs, legal indemnification, reachability analysis, or auto-remediation PRs (Snyk, Dependabot, Socket, and similar).
• Your dependencies are not predominantly Composer-managed; polyglot repos will need a second tool and the Markdown output will be partial.
• You need policy authoring with severity thresholds, exception expiry, and org-level reporting — a baseline file is not a governance system.
• Your CI cannot tolerate a network call to advisory sources, or you need fully air-gapped operation.

How to Pitch It (Stakeholders)

To executives: this is a small, low-cost addition that makes dependency risk visible and auditable without slowing releases. It lets us deliberately accept a known backlog of advisories while guaranteeing that new vulnerabilities surface immediately — so we stop shipping unknown risk without freezing the roadmap on cleanup. As of v2.0.0, findings cite standard CVE identifiers alongside tooling identifiers, which means the output can go straight into customer security reviews and audit evidence without translation.

To engineering: Composer-native, one command, emits console and Markdown. Baseline fingerprints are stable across the v2.0.0 upgrade, so committed baselines and CI gates keep working unchanged — the release is a display-only change that adds the CVE id next to the OSV/GHSA id. No breaking changes, no config migration, no re-baselining. Upgrading is safe to do in a routine dependency bump.

Positioning: buy-and-integrate, not build. The value isn't the scanning logic — it's the stable fingerprint contract and the report format, both of which are tedious to maintain in-house and cheap to consume here.