Just made the switch from Imperva to Signal Sciences after two years on their platform. The trigger was our latest sprint where we needed to tweak some blocking rules and the dev team hit a wall with Imperva’s configuration flow. The delay pushed a deployment back by a full day.
The core difference I’m seeing is in the developer experience. With Imperva, it often felt like security and development were siloed. Making changes felt like submitting a ticket into a black box. Signal Sciences, with its agent-based approach and real-time dashboard, feels like it’s part of the toolchain.
A few concrete things our team prefers:
* **API & Integration:** Signal Sciences’ API feels more modern and granular. We’ve hooked it into our CI/CD pipeline to adjust rules per environment, which was clunkier with Imperva.
* **Visibility:** The request feed is immediate and the tagging system makes it way easier for devs to diagnose false positives. Imperva’s reporting was powerful but felt more geared toward security analysts.
* **Support & Docs:** Found Signal Sciences’ documentation more actionable for developers. Imperva’s felt geared toward infrastructure teams.
Pricing is a different beast—Imperva felt like a monolithic package, while Signal Sciences’ usage-based model aligns better with our cloud spend. For teams that deploy frequently and need devs to own more of the WAF logic, the switch has been a net positive.
Curious if anyone else has gone down this path? Especially interested in how you handled the migration of existing rulesets or if you found any gaps in coverage.
Still looking for the perfect one
Backend lead at a mid-sized fintech (150 devs), Python/Go shop running k8s. We've had both Imperva's cloud WAF and Signal Sciences (now Fastly) in production over the last three years.
**Dev Loop Speed**: Imperva changes took ~15 mins to propagate in our tests, Signal Sciences' agent updates were near-instant. That's the difference between a CI/CD gate and a deployment blocker.
**Pricing Surprise**: Imperva's enterprise quote started at $45k/year and scaled with bandwidth. Signal Sciences' agent model ran us ~$22k, but it's CPU-heavy on the hosts; expect a 5-10% hit on app nodes under load.
**False Positive Triage**: Imperva's logs needed parsing and enrichment. Signal Sciences' request feed with tags let a dev find and tweak a rule causing a 429 in under two minutes. That's a daily win.
**Support SLA**: Both met their contracts. But Imperva's support assumed a dedicated security team. Signal Sciences' engineers would hop on a call directly with a confused SRE, which saved us cycles.
If you need deep, policy-heavy WAF managed by a security team, Imperva's probably still the call. For a devops-led shop where engineers own the rule tuning, Signal Sciences is a clear win. Tell me your team size and who manages the rulebase, I'll refine it.
The CI/CD integration point is key. We had the same pushback with Imperva's API - its bulkiness meant we couldn't reliably script rule updates as a pipeline stage. Had to fall back to manual steps, which broke the automation contract.
With Signal Sciences, we dropped a step in our Jenkinsfile that applies environment-specific rule tweaks via their API. The agent model means the change is live by the time the deployment finishes. That's what unblocking dev speed looks like.
Just watch the resource overhead on your app nodes. It's fine for most workloads, but can pinch if you're already CPU-bound.
The clunkier CI/CD integration with Imperva is the exact reason we started looking elsewhere. That "black box" feeling you mentioned creates a real bottleneck.
I'm with you on the API and visibility, but my team found the pricing model switch requires a full TCO review. The agent model isn't just a line item swap.
You're trading a predictable, albeit high, bandwidth-based fee for a variable cost in engineering hours and infrastructure. That 5-10% CPU hit user91 mentioned translates to needing more or larger app nodes. For us, that added about 15% to our cloud compute bill, which ate into the direct license savings.
Did you run a load test to quantify the agent's overhead on your specific stack? The financials only make sense if you have the headroom.