01
Collect
Read-only connectors pull findings, cloud inventory, code results and open tickets. Nothing is installed on the assets themselves.
Platform
From raw scanner output to a verified closure
Zelient is not another scanner. It sits between the tools that find things and the teams that fix them, and it refuses to call an exposure closed until the fix is proven.
Stages
Seven stages, running continuously
02
Normalise
Every finding is mapped onto one asset model, so a host, a container and a repository are described the same way.
03
Correlate
Duplicates collapse into a single exposure with one owner, one score and one history.
04
Score
Reachability, exploit intelligence, data sensitivity and business weight combine into a score your team can defend.
05
Route
The exposure is assigned to the team that owns the asset, inside the ticketing tool they already work in.
06
Verify
Zelient re-checks the asset, collects the evidence and only then marks the exposure closed.
07
Record
Every step is written to an immutable trail: who decided, what changed, when it was proven.
Verification
A ticket marked done is not a fix
Verification is the stage most platforms skip, and the one that changes what your reporting means. Zelient treats the closure as a claim that has to be tested.
- The original finding is re-run against the asset after the change ships.
- Evidence is attached automatically: the check output, the commit or change record, and the timestamp.
- If the check fails, the exposure reopens with the previous owner and a note on what did not hold.
- Closures that were never verified are reported separately, so a clean dashboard cannot hide an open hole.
Deployment
How it lands in your estate
Photo Albert Stoynov on Unsplash
Deployed in your cloud
Runs inside your own account or VPC. Findings and asset data stay in your tenancy, and nothing is proxied through ours.
Read-only first
Connectors start read-only. Write access, such as opening tickets or commenting, is granted per integration when you turn it on.
Live in a week
One scanner, one cloud account and one ticketing project is enough to see the deduplicated queue. Expansion is incremental.
Audit-ready by default
Every decision is written to an immutable log with the actor, the reason and the evidence attached.
Walk through it with your own scanner export
Thirty minutes, one export, no installation required.