Ssacc Bundle Laravel Package

Product Decisions This Supports

• Security-posture investment: The package statically checks a Symfony app's security.yaml access_control rules against its routes, so it answers a question executives actually ask — "is every endpoint covered by an authorization rule?" That number becomes the input to a hardening roadmap item rather than a guess.
• Build vs. buy vs. borrow: With 12 stars, 0 dependents, and a single maintainer, the honest decision is still borrow the idea, not the dependency. The v1.0.0 tag is a stability signal, not a support contract — MIT licensing means the approach is free to reimplement, and the adoption risk sits entirely with the package, not the concept.
• Framework scoping: This is a Symfony bundle, not a Laravel package. Its rules live in Symfony's security.yaml model; Laravel expresses authorization through route middleware, Gate, and Policy. For a Laravel roadmap this informs a decision to port the check rather than adopt the artifact.
• CI gate vs. manual review: Supports deciding whether authorization coverage becomes an automated build-breaking check or stays a periodic human audit. Automated wins on regression risk — new routes silently missing a rule is the classic failure mode.
• Policy definition, not just measurement: v1.0.0's security_requirement parameter lets a team declare what "covered" means for their service instead of accepting the tool's default. That turns the report from a generic scan into evidence of our standard — the difference between a number and a control.
• Audit and compliance evidence: Produces a repeatable artifact for SOC 2 / ISO access-control narratives and pen-test remediation prioritization, at near-zero cost versus a consulting engagement.

When to Consider This Package

Consider it when:

• You run Symfony 5/6/7 services whose authorization is declared in security.yaml access_control, and you want a static check with no runtime overhead.
• You have a material set of intentionally public routes (login, health checks, webhooks). v1.0.0 adds exclude_all_routes_that_start_with and exclude_full_routes, which is the difference between a usable signal and a noisy one — a coverage number inflated by known-public endpoints gets ignored after the first sprint.
• You need per-service or per-environment configuration. The command now accepts a config path argument and exposes project_path and controllers_path, so multiple services can share one runner with separate configs.
• You want prior art before writing your own checker — reading it may be more valuable than installing it.

Look elsewhere (or build) when:

• You are on Laravel. It will not run. Build the equivalent: enumerate artisan route:list, assert each route resolves to expected middleware or Gate/Policy coverage, and fail the build on gaps. A custom PHPStan/Larastan rule is the natural home.
• You need runtime enforcement. This is static analysis, not a WAF or a runtime authorization layer — different category entirely.
• You need a supported dependency. Bus factor is one, there is no community triage, and v1.0.0 is the project's first tagged release. Acceptable as dev-only tooling you're prepared to fork; unacceptable as a load-bearing production dependency or anything requiring a support contract. A 1.0 with one maintainer is a promise, not a guarantee.
• Your app authorizes primarily via #[IsGranted] attributes and Voters. A config-based checker may not see those paths, giving false confidence — the worst outcome for a security tool. Exclusions config does not fix this; it only suppresses noise on routes the tool can see.

If you do trial it: pin the version, keep it in require-dev, commit a config file with explicit exclusions and security_requirement, wrap it in CI, and confirm the MIT license lets you fork when maintenance stops.

How to Pitch It (Stakeholders)

To executives: This is a small, free, developer-only check that tells us whether every application endpoint has an access rule — the kind of evidence auditors and pen-testers ask for. There is no runtime risk and no vendor commitment. The new 1.0 release adds the configurability that makes the output credible: we define what counts as "covered" and exclude endpoints we've deliberately left public, so the report reflects our policy rather than a tool default. The caveat is unchanged — it's a one-person, low-adoption project, so we treat it as an internal utility we can fork, not a platform bet. Ask: approve a one-quarter CI pilot with a named owner.

To engineering: Two paths. If we have Symfony services, trial the bundle as a dev dependency and measure what it catches; the v1.0.0 config surface (project_path, controllers_path, route exclusions, security_requirement) is enough to wire it up without forking. For our Laravel services — the bulk of the estate — we implement the same check internally against route:list and middleware/Gate resolution, roughly one to two sprints, and it becomes a permanent build gate. Either way the deliverable is the same: a failing build when a route ships without an authorization rule.

The decision: fund the Laravel equivalent as the real product; treat the Symfony bundle as reference material and an optional tool for Symfony services only. The 1.0 tag makes the Symfony trial cheaper to justify but does not change its scope.