SignalSciences

Web applications may need to inspect incoming requests and block traffic that matches configured attack rules. The Signal Sciences agent forms part of the technology now documented as Fastly Next-Gen WAF, a web application firewall. It works through a chosen module-and-agent or reverse-proxy integration. The traffic path is essential: placing an agent container beside an application does not by itself route requests through inspection. Verify both accepted and blocked requests, including how the application behaves when inspection components fail.

Current guidance

The historical chart installed the Signal Sciences web application firewall agent. Fastly’s current documentation calls it the Next-Gen WAF agent and explicitly identifies the former name. That continuity does not make the old stable/signalsciences chart current.

Choose the deployment architecture before selecting a Kubernetes manifest. Fastly documents a module-and-agent integration and a reverse-proxy approach; an agent sidecar by itself does not prove that application requests pass through inspection. Its container guide identifies signalsciences/sigsci-agent and describes sidecar or specialized service deployment. Match the module, agent configuration and traffic path to the chosen mode.

Keep workspace keys in managed secrets, provide the required network access and allocate agent resources alongside application resources. Test both permitted and blocked requests, an agent restart and an unavailable analysis connection. Decide the intended application behavior during failure and verify it experimentally before enforcement. Also check drain timing so a terminating pod does not cut off in-flight requests. The chart, module and agent image require separate version and support checks; no WAF ruleset or failure behavior was tested for this entry.