Protection policy
Define which services and hostnames must sit behind WAF protection.
Secure
Web App & API Protection
Require WAF protection on a service before it ships
Manage the web-application and API protection your services run behind, and make it a condition of release. A policy requires WAF coverage on a hostname and the deploy gate checks it, so a service does not reach production unprotected.
- No service reaches production without verified WAF coverage
- One place to see which hostnames are protected and which are exposed
- A recorded reason behind every gate decision, ready for an auditor
The problem
When a new service ships, WAF coverage is often assumed rather than verified. You have no automated check that a hostname is actually protected before it reaches production, so gaps appear quietly and surface only when something goes wrong or an auditor asks.
Without IntegraCI
- WAF coverage assumed, not verified at deploy time
- Protection gaps go undetected until an incident or audit
- No single view of which hostnames are exposed
- Each team self-polices whether protection is in place
With IntegraCI
- Policy as code declares which services must be covered
- Deploy gate checks protection before a release proceeds
- One view shows which hostnames are protected and which are exposed
- Governs the WAF you already run rather than replacing it
What you get
Gated at deploy
The deploy gate checks protection coverage before a release proceeds.
Posture in view
See which hostnames are protected and which are exposed in one place.
On your provider
IntegraCI governs the WAF you already run rather than replacing it.
How it works
- 1
Set the policy
Declare which services must be protected and to what standard.
- 2
Sync posture
The platform reads protection coverage for your hostnames.
- 3
Gate the deploy
A release is blocked if a required service is not protected.
How it stays governed
The same gates everyone passes, applied here.
Gated by policy
Policy as code declares which services and hostnames must sit behind WAF protection. The deploy gate reads that policy and blocks a release if the required coverage is not confirmed, so the requirement cannot be bypassed by forgetting a step or working around the normal process.
Recorded, tamper-evident
Every gate decision writes once to a tamper-evident audit trail with the hostname, the policy rule evaluated, and the outcome. You can show an auditor exactly why a release was allowed or blocked, not just that it was.
Works with your stack
Connect the tools you already run.
Connects to the WAF and deploy pipeline you already run to read coverage posture and gate releases.
- Akuity
- Amazon Web Services
- Buildkite
- CircleCI
- CNCF Tekton
- Drone CI
- Harness
- Jenkins
- Apple
- Argo Project
- AWS
- Cloudflare
- CNCF
- Coder
- Crunchy Data
- Daytona
- Env0
- +37 more
Who it’s for
Where teams reach for it.
Gate a first production release
A new service is ready to ship but the WAF rule has not been applied yet. The deploy gate catches the gap and blocks the release until coverage is confirmed, so the service does not go live unprotected.
Audit protection posture across all services
Your team needs to know which hostnames are covered and which are exposed. A single posture view lists every hostname and its protection status without manually checking each provider console.
Bring a legacy service under policy
An existing service was never formally added to your WAF policy. You define the requirement in policy as code, and the next deploy is blocked until protection is verified, closing the gap without a manual checklist.
Questions, answered.
Does IntegraCI replace my WAF?
No. IntegraCI governs and gates the WAF you already run. Your WAF provider handles traffic inspection; IntegraCI reads your coverage posture and makes it a condition of release.
Which WAF providers does this work with?
IntegraCI connects to the protection provider you already operate. The capability governs coverage across your existing setup rather than requiring you to switch providers or adopt a new one.
How are protection policies written?
You declare which services and hostnames must be protected in policy as code. The same rule set is evaluated at every deploy, so the requirement cannot be skipped by a missed step or a team working outside the normal process.
What happens when a deploy is blocked?
The gate blocks the release and records the reason in the audit trail. The team sees exactly which hostname failed the protection check and can resolve it before retrying the deploy.
Put Web App & API Protection on your stack.
Request a demo, or read the docs to see how it fits the tools you already run.