APEA

No. The target is a deliberately vulnerable reference application placed behind the profile under test. That is what makes the result meaningful — if an attack reaches a vulnerable target, the profile did not stop it — and it means the measurement is safe to repeat whenever you like.

By design, any protection that sits in front of an application over HTTP: appliances, cloud services, reverse proxies with rule sets. Testing would happen through the profile rather than through a vendor integration, which is also what would make two vendors comparable.

By sending legitimate traffic patterns through the same profile: the uploads, long inputs, unusual parameters and character sets your application genuinely accepts. You describe what normal looks like for this application, and the run would measure how much of it the profile would have blocked.

It is a design-stage concept, not a product you can buy or run today. The approach described here is one we believe in, but it is not currently being built — it sits behind other work on our roadmap. You get our honesty about that; what you do not get is a self-service product with every case already written. If the measurement would help you, tell us, because early interest is what moves a concept up the list.

We expect the measurement itself to take hours, not weeks. The work around it is agreeing what legitimate traffic looks like for the application and, afterwards, applying the tuning list — which is usually where the calendar time goes.

A penetration test asks whether your application can be broken into. This asks whether the protection in front of it does its job, by holding the application constant and varying the profile. They answer different questions and organizations that take security seriously do both.

The traffic goes to a reference application, not to your systems, and the profile is exercised as it would be by any visitor. If the profile has rate limiting, the run respects it; the point is to measure the configuration, not to stress it.

That is the intent of the design: for a team with several profiles, it is meant to be scheduled, run after every rule-set change, with the results kept inside. Since it is still a design-stage concept rather than something you can install today, that self-service picture is where the product is headed, not what is on offer right now.

After every change that touches protection — a rule-set update, a new profile, a migration — and on a schedule besides, because profiles drift. A rule switched off during an incident tends to stay off.

Coverage by category for both directions, every gap with the request and response that prove it, a tuning list naming the rules and settings to change, and a comparison against the previous run once there is one.

Not for the measurement, which works through the profile from the outside. Access or a configuration export helps the tuning guidance name exact rules rather than describe them, so most teams provide read access at that stage.

VAaaS tests the application, ASM finds what is exposed, and this measures whether the protection in front of an exposed application actually works. They are useful separately; together they cover discovery, defence and the weakness itself.