Porto Laravel Package

Product Decisions This Supports

• Supply-chain security as a roadmap item. A dependency audit turns "we should care about our Composer graph" into a repeatable, scriptable check. That gives you a defensible answer for security questionnaires, SOC 2 / ISO evidence requests, and enterprise procurement reviews without standing up an AppSec program.
• Build vs. buy for internal tooling. The alternative is an in-house script wrapping composer outdated + composer audit + a license whitelist. This package replaces that glue with a maintained CLI. Buy (well, adopt MIT) unless your policy needs are genuinely org-specific.
• CI gating policy. The key decision is where the gate sits: advisory in PR comments first, blocking on main later. A deterministic CLI makes that a config change, not a re-architecture.
• Upgrade and modernization planning. Answers "what is actually blocking our Laravel 12 / PHP 8.4 migration" with a concrete list instead of a survey of opinions. Directly informs sequencing on the platform roadmap.
• License compliance for commercial distribution. If you ship a closed-source product or do a source-available release, a license audit is a legal prerequisite, not a nice-to-have. This is often the decision that unlocks the budget conversation.
• Agent-assisted remediation loops. The project's conventions (AGENTS.md, machine-oriented messages, deterministic output shapes) signal a tool built to be driven by coding agents as well as humans. That makes it a candidate for an internal "fix the dependency drift" automation workstream — a differentiating capability, not just a lint step.
• Make-vs-integrate for agent tooling. If your engineering org is investing in AI-assisted maintenance, a tool with an explicit agent contract lowers integration cost versus retrofitting a human-first CLI.

Diligence flag for the PM: the artifact metadata is inconsistent — package name nunomaduro/porto, repository laravel/vet, description "Laravel Vet is a dependency audit for PHP", 0 dependents, and a release date that needs verification. Before this appears in composer.json, confirm the canonical package name and maintainer. Treat the naming gap as a real risk item in the adoption decision, not a footnote.

When to Consider This Package

Adopt when:

• The stack is PHP/Composer, ideally Laravel, and dependencies are already centralized in composer.lock.
• You have CI on pull requests and want a low-friction place to attach the check — the cost of adoption is one CI step, not a platform migration.
• You need machine-readable, deterministic output for scripts, dashboards, or agent-driven fix workflows.
• You want permissive licensing (MIT) with no procurement cycle and no per-seat cost.
• The goal is awareness and hygiene — outdated, abandoned, or risky dependencies surfaced on a schedule.

Look elsewhere when:

• The estate is polyglot (npm, Go, Python, containers). You need one SCA surface, not one per ecosystem; standardize on a cross-language scanner.
• You need reachability analysis or runtime exploitability, not just declared-version auditing. That is a different product class and a different budget.
• You need formal SBOM artifacts (CycloneDX/SPDX) plus a VEX workflow for regulated customers. Audit output is not an SBOM.
• You need a policy engine across many repos with centralized exceptions and waivers, or a vendor with an SLA, indemnification, and a curated advisory feed contract.
• You are making this a blocking production gate. At this maturity level (low star count, no dependents, single-maintainer profile), a hard gate creates availability risk for your own pipelines. Run it in advisory mode, pin the version, and re-evaluate after a quarter of stable signal.
• Nobody owns the findings. A scanner with no remediation owner is a dashboard nobody reads, and it will be switched off within two release cycles.

Sequencing recommendation: adopt as advisory in CI → measure finding volume and false-positive rate for 4–6 weeks → decide on a blocking policy with a named owner → only then consider it part of the compliance narrative.

How to Pitch It (Stakeholders)

To executives: We have no consistent answer to "are our third-party PHP dependencies current, maintained, and legally safe to ship." Today that answer is assembled by hand, per project, when a customer or auditor asks. This package gives us a repeatable check that runs automatically on every change, at zero license cost, inside the toolchain we already use. The near-term value is risk reduction and faster security questionnaires. The long-term value is that dependency hygiene becomes a standing capability rather than a fire drill before each release. Cost is engineering time to wire it into CI and to own the findings — not a new vendor contract.

To engineering: One CLI over the existing Composer graph, deterministic output, runs in CI alongside your current steps. No new runtime dependency, no service to operate, no credentials. Start it in advisory mode so it informs without blocking; we promote it to a gate once we trust the signal and have an owner for remediation. The tool's conventions are explicitly designed for machine consumption, so it composes with agent-assisted cleanup work rather than fighting it. The tradeoff is honest: it is an early-stage MIT project with a small maintainer base, so we pin the version, keep the check non-blocking initially, and keep our existing tooling as the fallback. Verify the canonical package name before it lands in composer.json — the repository metadata is inconsistent, and that is the one thing that could make the first sprint of adoption frustrating.