Filament Antivirus Laravel Package

Technical Evaluation

Architecture fit. Unchanged and now confirmed by the release notes. The package occupies a real seam in the Laravel/Filament stack: Filament's FileUpload component has no first-class content-scanning story, and Laravel's filesystem abstraction deliberately ignores file content. v1.0.0 delivers exactly the pieces that matter most — a Filament Antivirus Dashboard and a quarantine manager backed by an antivirus_incidents table. From a TPM standpoint the framing holds: most of the differentiated value is the admin UI, the incident record, and the quarantine workflow, not the scanner. ClamAV is free and you would shell out to it regardless. Buy the operator experience, own the scanning abstraction.

Integration feasibility. Feasible on a standard Laravel 10/11/12 + Filament 3.x Linux stack with ClamAV available. The release resolves the single most important open question from the prior assessment — the interception point — and the answer is the AntivirusFileRule validation rule on individual form fields. That is the best available hook: Filament validates against the Livewire temporary upload before the file is persisted, so a correctly-attached rule scans pre-write rather than post-save. But it is also opt-in per field, which converts the earlier open question into a concrete and permanent constraint: any upload surface without that rule attached — custom API endpoints, CSV/import pipelines, queued jobs, console commands, any non-Filament controller — is unscanned. Coverage is a function of developer discipline, not of the package, and it degrades silently as new upload paths are added. That is the control's real boundary and should be documented as such.

The release also introduces a deployment decision the notes treat as a convenience but which is operationally load-bearing: clamdscan vs. clamscan. clamdscan is a thin client against a running clamd and is fast; clamscan is a standalone binary that loads the full signature database on every invocation, costing seconds of latency and roughly a gigabyte of RAM per call. Supporting both is reasonable for developer ergonomics, but the difference is the difference between a usable upload gate and a Livewire timeout incident. Prod must be pinned to clamdscan and asserted in configuration, not left to discovery.

Technical risk and what the release resolved vs. left open:

Key questions — status after v1.0.0 (source read still required, but the spike is now much shorter):

1. Which hook point? Answered: AntivirusFileRule on Filament fields, pre-persist. Remaining: which non-Filament paths are uncovered in your app, and is there a config to enforce the rule globally?
2. Fail-open or fail-closed on scanner unavailability, and is it configurable? Still open — resolve before enforcing.
3. Synchronous or queued? What ceilings? Still open; assume synchronous.
4. Does antivirus_incidents/quarantine capture original filename, uploader, tenant, timestamp? Implied yes by "quarantine manager"; verify columns.
5. CI matrix — not stated; assume none. You are the integration test.
6. freshclam automation — not present; external.
7. Per-panel/per-tenant enablement and quarantine isolation — not stated.
8. Does antivirus:scan walk existing storage corpora (backfill) or only ad-hoc paths? New, and high-value if yes.
9. Is the null driver guarded against non-local environments? New.
10. Behavior on remote disks (S3/Spaces) — stream, download to temp, or unsupported? Still open; determines large-file viability.
11. Future-dated release anomaly Resolved: this is the initial v1.0.0 release; the maturity concern stands on its own merits.

Integration Approach

Stack fit. Clean for Laravel + Filament on Linux with a persistent clamd (sidecar container, host service, or managed endpoint), with clamdscan pinned as the driver. Poor — effectively disqualified — on shared hosting, Windows, or serverless (Vapor/Lambda), where the core assumption of a reachable ClamAV binary or daemon breaks. Also a poor fit for S3/GCS-first architectures where files never transit the app server; cloud-native malware protection is the better shape there and retrofitting a local scanner is a step backwards. The clamscan (non-daemon) mode should be treated as a local-development affordance only, never a production configuration.

Migration path. Adopt the package as an adapter, not a foundation. The release makes this cheaper to execute because its surface is small and its boundaries are now legible:

1. Define an internal FileScanner interface (scan(), quarantine(), release()) with a NullScanner/log-only implementation. Note the deliberate collision with the package's dev-mode null driver — keep yours distinct, and make yours the only one that can ever be bound outside local.
2. Bind the filament-antivirus implementation behind it in a service provider, and wrap AntivirusFileRule in a project-owned rule that delegates to the interface. Filament fields then reference your rule, not the vendor's.
3. Treat the package as an implementation detail — never referenced from upload controllers or models.
4. Run a separate async backfill against the existing corpus, evaluating antivirus:scan as the engine if it supports disk traversal; quarantine findings for human review rather than auto-deleting.

This converts vendor risk into a container binding change. Given this is a 1.0.0 first release from a single maintainer with zero dependents, the wrapper is not defensive over-engineering — it is the expected cost of adoption.

Compatibility. Pin the package to an exact version rather than a caret range; a ^1.0 on a brand-new 1.0.0 lets a same-day patch silently change a security control. Lock Filament and Laravel minors in CI, and read the source — the whole package is small enough to review in an hour, and that smallness is a feature. Two smoke tests are mandatory and are your regression net for every future Filament bump: an EICAR upload rejected at validation time, and a config assertion that the active driver is clamdscan outside local.

Sequencing. Four phases, roughly five to six weeks elapsed — a week shorter than previously estimated, because the interception-point question is answered:

1. Spike (3–4 days). Sandbox Filament panel + clamd. Verify EICAR is rejected on upload, not merely on save. Explicitly test: a 100 MB file (to expose synchronous-scan timeouts), an S3 disk, daemon-down behavior, antivirus:scan against a directory of existing files, and a non-Filament upload path to measure the bypass surface.
2. Shadow mode (2 weeks). Deploy with scanning enabled but non-blocking. Use antivirus_incidents and antivirus:status as the observability layer. Log detections and false positives. This establishes what your users actually upload and validates the FP rate before you start rejecting anything — the cheapest way to avoid a launch-week support escalation.
3. Enforce, highest-risk surfaces first. Public/anonymous upload forms first; internal admin panels after. Per-field rule attachment makes this a small, reviewable diff, which is the package's strongest argument.
4. Backfill and harden. Scan the existing corpus asynchronously; quarantine for human review. Then alerting on detections and scanner health, quarantine disk quotas, retention policy, and a written release/restore runbook.

Scope framing for the roadmap. This package moves "malware scanning on Filament uploads" from a multi-sprint backlog item to a config-and-configure task, and the v1.0.0 dashboard and incident table are genuinely the hard part done for you. That is a legitimate launch unblocker — but the honest claim is "commodity signature scanning on Filament uploads, plus good operational ergonomics," not "comprehensive file security." The unqualified word in that sentence is Filament. Do not let it become the answer to a DLP, CDR, zero-day, or non-Filament-ingestion question it cannot answer.

Operational Impact

Maintenance. Patching the package is cheap (small surface, MIT). The real load remains ClamAV ownership, which is not a composer install: freshclam signature updates multiple times daily, daemon major-version upgrades, config drift, and container health. v1.0.0 adds one item to that load and one item off it: on the plus side, antivirus:status gives you a hook for health and staleness alerting rather than requiring you to build one; on the minus side, the dual clamdscan/clamscan driver and the dev-mode null driver are two new ways for the control to be quietly disabled, and both need config assertions in CI. Add ongoing tracking of Filament's release cadence, since with zero dependents no upstream community will catch breakage for you — and with a first-ever 1.0.0 published, assume the maintainer has not yet been stress-tested by an upgrade cycle. Realistic estimate: 0.1–0.25 FTE of platform ownership plus an on-call runbook entry. Staff this before you ship, not after — an unmaintained scanner that silently stops updating signatures, or silently falls back to a null driver, is worse than no scanner, because it creates false assurance.

Support. Assume self-support. One maintainer, four stars, zero dependents, best-effort issue response, first public release. Vendor or fork the package into your own monorepo so you can patch without waiting, and accept ownership of the security review of its internals. Two stakeholder conversations to schedule early: legal/compliance on quarantine data handling — quarantined files are simultaneously potentially malicious and potentially user PII, so retention, encryption at rest, and access logging to the antivirus_incidents table all need a documented answer — and security on the fail-open/fail-closed decision, which is a product decision with a business-visible trade-off: fail-closed means a ClamAV outage halts uploads (and possibly a revenue path); fail-open means the control is decorative during exactly the window an attacker would choose.

Scaling. ClamAV is CPU- and I/O-heavy and is not a throughput tool; clamscan mode is dramatically worse, spawning a process and loading the signature database per file. Design for interactive user uploads, not media pipelines. Concretely: pin clamdscan against a persistent clamd, set explicit size ceilings, cap concurrent scans, and monitor median scan latency as a first-class metric. If volume grows or files are large, the architecture to reach for is asynchronous scanning against object storage (GuardDuty Malware Protection for S3, OPSWAT, Cloudmersive, VirusTotal) — the FileScanner abstraction is what preserves that option, and the per-field rule wrapper is what keeps that swap from touching every form.

Failure modes to document and instrument:

Ramp-up. Low for a team already on Filament — installing the package, attaching AntivirusFileRule to a field, and reading the dashboard is an afternoon's work. The learning curve is concentrated in ClamAV operations (daemon topology, signature freshness, driver selection) and in the fork-and-patch workflow, both of which are platform-team skills, not application-team skills. Assign a named owner from the platform side; this package should not be adopted by a product team without one.

Success metrics for the initiative. Percentage of upload surfaces with the rule attached (report this as a ratio against your inventory, not as a binary), percentage of uploads scanned, median scan latency, quarantine volume and median disposition time, false-positive rate in shadow mode vs. enforce mode, and the headline number: zero unscanned files reaching persistent storage through an instrumented path. Report the last one to stakeholders; it is the sentence that turns a technical control into a compliance artifact — provided the qualifier "through an instrumented path" is stated honestly alongside it.