Accent Bundle Laravel Package

Product Decisions This Supports

• Security roadmap prioritization (OWASP A01 — Broken Access Control). Accent targets the single most common web vulnerability class: routes/controllers that lack an authorization check. It gives you a measurable coverage metric ("% of actions with a voter/attribute") that you can put on a security initiative roadmap and track quarter over quarter.
• Build vs. buy for authorization coverage checks. Instead of commissioning a custom static-analysis rule or an internal audit script, this is a candidate off-the-shelf dev-only quality gate. Decision: pilot vs. build custom PHPStan/Rector/Semgrep rules.
• Definition-of-done and CI gate decisions. Whether "every new controller action ships with an explicit access check" becomes an enforceable merge requirement or stays a code-review convention.
• Compliance evidence. For SOC 2 / ISO 27001 access-control controls, a repeatable report of authorization coverage per release is cheaper evidence than manual attestation.
• Platform-fit scoping. This is a Symfony bundle, not a Laravel package — there is no service provider, and it assumes Symfony's security component, voters, and #[IsGranted]-style attributes. v3.1.0 reinforces this: the release is explicitly about API Platform integration (api-platform/symfony alongside api-platform/core) and install-time dependency guards, not about broadening framework support. If your stack is Laravel, the decision this informs is unchanged: "do not adopt; use native Gate/Policy tests plus a static-analysis rule instead."
• Vendor-risk / maintenance decision. 16 stars, 0 dependents, and a low opportunity score (1.45) mean this is a tactical utility, not a strategic dependency. v3.1.0 shows signs of active maintenance (dependency hardening, fail-fast ergonomics) but does not change the maturity picture. Posture stays "pin the version, expect to fork."
• API Platform standardization decision. If your roadmap includes adopting API Platform for a Symfony service, v3.1.0 makes Accent a viable coverage gate for that surface out of the box — useful input when deciding whether to standardize on API Platform's security expressions vs. hand-rolled voters.

When to Consider This Package

Adopt (or pilot) when all of the following hold:

• You are on a modern Symfony application (6.x/7.x) using the Security component with voters and/or route/controller attributes as your authorization model.
• Your surface area is large enough that manual review demonstrably misses routes — dozens of controllers, admin panels, multi-tenant APIs, or a legacy codebase with inconsistent enforcement.
• You want this as a dev/CI-time tool only; it complements, not replaces, runtime enforcement and penetration testing.
• You have engineering appetite to own a low-adoption dependency: pinning versions, reading source, and possibly patching or forking.
• You specifically want per-route coverage reporting for audit and security-review conversations.
• New in v3.1.0: you use API Platform (api-platform/core or api-platform/symfony) and want coverage checks on those resources without custom glue. The bundle now also fails fast with an explicit message when no supported API Platform package is present, which makes spike setup and onboarding cheaper.

Look elsewhere when:

• You are on Laravel. Different ecosystem entirely — the integration cost is a rewrite, not an install. Use Gate/Policy feature tests, a custom PHPStan rule, or Semgrep patterns for the same outcome.
• You need runtime protection, WAF behavior, or DAST coverage. This is a checker, not an enforcer.
• Your app is small (a handful of routes); a checklist and code review are cheaper than a new dependency.
• You require vendor support, an SLA, or a large community for procurement/vetting — the adoption signals here (16 stars, 0 dependents, score ~2.66) do not support that bar.
• Your authorization is heavily customized (bespoke attribute pipelines, non-standard voter inheritance, custom security-expression metadata); v3.1.0 broadens package detection but not necessarily parse coverage. Verify against your real controllers in a spike before committing.
• You are on an older Accent pin (v3.0.x) with API Platform: upgrading is low risk but changes install-time dependency resolution, so confirm your composer graph resolves the way you expect in a branch first.

How to Pitch It (Stakeholders)

To executives: Broken access control is the top item on the OWASP risk list and a frequent source of breach disclosures and audit findings. This is a small, dev-only tool that scans our Symfony routes and reports which ones lack an explicit permission check — a cheap, low-blast-radius way to make authorization coverage visible and enforceable in CI before release. The latest release (v3.1.0) is a maintenance and integration step: it adds first-class support for API Platform and makes misconfiguration fail loudly instead of silently, which lowers the cost of trying it and reduces the chance of a misleading green build. The caveat is unchanged maturity: it is a young, low-adoption open-source project from a consultancy, so the ask remains a time-boxed spike, not a platform commitment. If the spike pays off, we fold it into the security roadmap as a merge gate and reuse the output as audit evidence.

To engineering: Install as a dev dependency, run it in CI, and treat the report as a checklist of routes missing an access check. It slots alongside PHPStan and your test suite. v3.1.0 is a minor release with no breaking changes, but it does touch dependency resolution: it recognizes api-platform/symfony as well as api-platform/core, prevents api-platform/core from being pulled in alongside the bundle, and errors clearly if no supported API Platform package is installed — so composer conflicts surface at install time rather than as confusing empty reports. Three things to validate in the spike: (1) it correctly understands our attribute/voter patterns, including inherited and API Platform resource routes, (2) the false-positive rate is low enough that the gate won't get disabled in week two, and (3) the new dependency guard behaves correctly in our monorepo/CI image. Assume we own this code — pin the version, keep the fork path open, and don't let it become a single point of failure in the pipeline.