- Is th0masso/ssacc-bundle a Laravel package?
- No. It is a Symfony bundle that extends Symfony\Component\HttpKernel\Bundle\Bundle and depends on Symfony firewall and security.access_control semantics. Laravel has no access_control list, no security.yaml, and no firewall model, so a Laravel service provider cannot meaningfully wire it in. Treat it as a false positive for Laravel intake.
- Can I install th0masso/ssacc-bundle in a Laravel application?
- You can Composer-require it, but it will not do anything useful because there is no Symfony security configuration for it to read. Its config keys such as project_path, controllers_path, and security_requirement are Symfony-shaped concepts. If your target is Laravel, reject it at intake rather than trying to adapt it.
- Which Laravel versions does this package support?
- None. The package does not declare Laravel framework support and does not ship a Laravel service provider, facade, or middleware. Its lifecycle is tied to Symfony bundle registration in config/bundles.php. Any claim of Laravel version compatibility would be inaccurate.
- What does th0masso/ssacc-bundle actually do?
- It is a static route-coverage auditor. It scans controller source files under a configured path, extracts declared routes, applies path and route exclusions, and evaluates each remaining route against a declared security_requirement. It reports routes that appear not to be covered by a security rule. It does not boot the Symfony kernel or use the real AccessMap and RequestMatcher.
- How do I install and configure it in a Symfony application?
- Install with composer require --dev th0masso/ssacc-bundle, then register the bundle in config/bundles.php scoped to dev and test environments. Commit a config file containing project_path, controllers_path, exclude_all_routes_that_start_with, exclude_full_routes, and security_requirement. Run it through its console command, optionally passing an alternate config path as the first argument, and keep registration env-scoped so nothing loads in production.
- Which routes will the scan miss?
- It will not see routes declared in YAML or XML routing, routes registered by bundles or vendor packages, invokable controllers outside controllers_path, imported route files with prefixes, resource-generated routes, or conditionally loaded route collections. Each of those is a blind spot that can surface as a false all-clear, which is the worst failure mode for a security-adjacent tool. Treat a pass as a hint, not a certification.
- What does the security_requirement config option mean?
- It is undocumented in the release notes, so verify it against the source before relying on results. It could mean a route must match an access_control entry, must require at least one role, or must sit behind a named firewall. Each interpretation changes what a pass actually certifies, so do not assume.
- Is it safe to run in production?
- There is no production traffic path provided bundle registration stays scoped to dev and test. The real risks are operational: absolute project_path and controllers_path values that differ between developer machines and CI containers can yield zero scanned routes and a vacuous pass. Pin ^1.0 if you adopt it, but do not read the tag as evidence of adoption or support.
- How should I use it in CI or testing?
- Run the console command in a CI job and fail the build when uncovered routes are reported. Guard against vacuous passes by asserting a minimum scanned-route count, and check for unused exclusions because prefix and exact-string exclude lists silently widen after URL refactors. For Laravel projects, use route:list output plus route middleware inspection instead.
- Is the package maintained, and what are the alternatives?
- It has roughly 12 stars, 0 dependents, a solo maintainer, and no downstream validation; the 1.0.0 tag stabilizes the config schema but is not evidence of support. For Laravel, the alternatives are framework-native Gates and Policies, route middleware review, and route:list audits backed by authorization tests. For Symfony, prefer kernel-boot approaches that use the real AccessMap when you need higher fidelity.