Ssacc Bundle Laravel Package

Technical Evaluation

Architecture fit — still not a Laravel package. v1.0.0 changes nothing here. th0masso/ssacc-bundle remains a Symfony bundle extending Symfony\Component\HttpKernel\Bundle\Bundle, built on security.access_control / firewall semantics. Laravel has no access_control list, no firewalls, and no security.yaml; its authorization surface is Gates, Policies, and route middleware. A Laravel service provider cannot meaningfully wire this in, and the new config keys (project_path, controllers_path, security_requirement) are Symfony-shaped concepts. If the sourcing intent was genuinely Laravel, this remains a false positive and should be rejected at intake.

What the package actually does — now clarified, and different from what was assumed. The v1.0.0 config surface is the most informative thing in the release. project_path + controllers_path + exclude_all_routes_that_start_with + exclude_full_routes + security_requirement describes a static route-coverage auditor: it scans controller source files under a configured path, extracts the routes they declare, applies path/route exclusions, and evaluates each surviving route against a declared security requirement. That is a coverage-gap tool — "which routes are not covered by a security rule" — rather than a pure access_control linter.

This resolves the most important open question from the prior assessment: it does not boot the kernel and use the real AccessMap/RequestMatcher. It parses source. That is a materially lower trust ceiling than the kernel-boot approach, and the assessment should be recalibrated accordingly. The concept (route→rule coverage diffing) is genuinely useful; the implementation is approximate by construction.

Integration feasibility. Feasible and low-effort in a Symfony estate, but the footprint is now larger than a one-line Composer addition: there is a per-application config file to author and maintain. Typical adoption is composer require --dev th0masso/ssacc-bundle, bundle registration in config/bundles.php scoped to dev/test, a committed config file, and invocation via console command with an optional alternate config path as the first argument. Still no production traffic path — provided registration stays env-scoped.

Technical risk.

• Fit risk (high for Laravel, low-moderate for Symfony): unchanged. Ecosystem mismatch is disqualifying for a Laravel target.
• Static-analysis fidelity (elevated, now confirmed as the core risk): controller-source scanning will not see routes declared in YAML/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. Every one of these is a blind spot that surfaces as a false "all clear" — the worst failure mode for a security-adjacent tool.
• Exclusion drift (new): exclude_all_routes_that_start_with and exclude_full_routes are prefix/exact string lists. A URL refactor that changes a path segment silently widens an exclusion and erodes coverage with no signal. Unless the tool warns on unused excludes, this decays invisibly.
• Semantics uncertainty (new): security_requirement is undocumented in the release notes. Whether it means "must match an access_control entry," "must require at least one role," or "must be behind a named firewall" changes what a pass actually certifies. This must be verified, not assumed.
• Portability (new): project_path and controllers_path invite absolute paths that differ between developer machines and CI containers. A misconfigured path likely yields zero routes scanned and a vacuous pass.
• Maturity risk: unchanged and still the dominant signal — 12 stars, 0 dependents, solo maintainer, no downstream validation. The 1.0.0 tag signals an intent to stabilize the config schema (reasonable to pin ^1.0), but should not be read as evidence of adoption or support.
• Correctness risk on rule modeling: allow_if expressions, env-var interpolation, custom voters, and IP/method/host/port matchers remain approximation hazards, as before.

Key questions for the maintainer / evaluation.

1. Which Symfony and PHP versions are supported, and is Symfony 7 covered?
2. How are routes extracted — attribute/annotation parsing only, or does it follow route imports, prefixes, and resource declarations? Which constructs are known-unsupported?
3. What exactly does security_requirement assert, and can it express per-route requirements or only a global floor?
4. Does it fail closed on unparseable controllers or unknown route attributes, or skip silently?
5. Are exclusions prefix/exact only or regex-capable, and does it report stale/unused exclusions?
6. Does it detect or warn about routes registered outside controllers_path (bundles, vendor, YAML routing)?
7. Are project_path/controllers_path resolved relative to the project root, and does a bad path raise an error or produce an empty, passing result?
8. Is the bundle strictly dev-only by design? What is the support commitment now that 1.0.0 is tagged?

Integration Approach

Stack fit. Assume Symfony 5.4/6.x/7.x on PHP 8.1+. If the actual target is Laravel, stop — there is no integration approach and the correct disposition is "reject — stack mismatch." Everything below assumes a Symfony target.

Migration path. No data model, no schema, no runtime surface. Adoption is: Composer dev dependency, env-scoped bundle registration, plus a committed config file (project/controller paths, exclusion lists, security requirement) that becomes a maintained artifact in the repo.

// config/bundles.php
return [
    // ...
    Th0masso\SsaccBundle\SsaccBundle::class => ['dev' => true, 'test' => true],
];

Compatibility checks before commitment.

• Resolve against the app's symfony/security-bundle version — still the likeliest install failure.
• Confirm routing is attribute/annotation-based in controllers under a single tree. Apps with significant YAML/XML routing or bundle-registered routes are poor fits and will get partial, misleading coverage.
• Confirm project_path/controllers_path can be expressed portably (relative to project root, container-safe).
• Confirm the app does not depend on allow_if expressions or a non-default access decision strategy, or accept reduced fidelity.

Sequencing.

1. Spike (1 day, up from 0.5): install in one representative service, author the config file, run against the real security.yaml, and diff output against a manual audit of a sample of routes.
2. Negative test (mandatory, before any trust): deliberately remove or weaken one access rule and confirm the tool flags the affected route. If it cannot detect a real, intentional gap, it cannot detect an accidental one — and the tool should be dropped rather than tuned.
3. Advisory adoption: add as a non-blocking CI job for one or two sprints; measure signal-to-noise and count skipped/silent routes.
4. Promotion: only if the negative test passes and skipped-route count is zero, promote to a blocking lint for services with externally exposed routes, documented in the platform runbook.
5. Contingency: keep the internal AccessMap-based script in the back pocket — it would be more faithful precisely because it uses the framework's real matcher rather than parsing source.

Compatibility caveat. Do not roll out as a shared or transitive dependency across services. Pin ^1.0 per service and template the config file so per-service drift is minimal.

Operational Impact

Maintenance. Consuming-team effort remains low (Composer bump, CI entry), but v1.0.0 adds a new maintained artifact: the config file. It must be updated when controllers move, when routing structure changes, and when routes are intentionally made public. Upstream remains thin — one maintainer, effectively a single release, no visible triage history. Budget for the package going unmaintained within 12 months and for absorbing ownership (fork under an org namespace — MIT makes it trivial — or replace with the internal script). Cost is engineering time, not licensing.

Support. Community-only. No vendor, no SLA, no verifiable security disclosure process. The 1.0.0 tag is a versioning statement, not a support commitment. It must never be the sole control preventing an access-control regression.

Scaling. Negligible runtime scaling if scoped to dev/test; seconds of CI per service. The scaling concern is organizational and now slightly worse: N services means N config files plus N pinned versions for the platform team to track. Template the config and treat the excludes as reviewable code, not local tweaks.

Failure modes.

• False negative via unparsed routes (highest severity): routes registered in bundles, vendor packages, YAML/XML routing, or outside controllers_path are never evaluated and never reported as skipped — the audit passes while exposure exists.
• False negative via exclusion drift: an over-broad or stale exclude_all_routes_that_start_with prefix silently exempts routes after a URL refactor.
• False negative via path misconfiguration: wrong project_path/controllers_path yields zero routes scanned and a vacuous pass, unless the tool errors instead.
• Misread security_requirement: a permissive global requirement passes routes that the team assumed were role-gated.
• False positive: intentionally public routes flagged, causing alert fatigue and eventual suppression of the check.
• Install/upgrade break: Symfony major bump strands a stale constraint, blocking upgrades until the dependency is removed under time pressure.
• Environment leakage: bundle registered in prod by mistake ships an unnecessary service and console command. Low blast radius, avoidable.
• Abandonment: no release across a Symfony major cycle; team must fork or drop.

Ramp-up. For a Symfony-fluent engineer, roughly one day including config authoring and the negative test; the real cost is establishing trust, not installation. For a Laravel-only team, ramp-up remains infinite — the tool does not apply, and the Gates/Policies ↔ access_control mapping is not a translation this package performs.

Recommendation. Reject for a Laravel target — wrong ecosystem, unchanged by v1.0.0. For a Symfony target, v1.0.0 makes the tool more usable (configurable paths, exclusion control) but not more trustworthy — it confirms a static-parsing approach rather than the kernel-boot approach that would have justified real confidence. Treat it as a nice-to-have audit utility, not a platform standard: run the one-service spike, require the negative test to pass, adopt only as a non-blocking CI advisory, keep excludes under code review, and retain an internal AccessMap-based replacement as the fallback. The 0.09 score and zero dependents remain accurate signals against promoting this to a required dependency across the estate.