Continuous security, verified

Proof, not alarms.

ZprotectZ finds the known security holes in your servers, container images and code dependencies, warns you the moment something shows signs of compromise, proposes a fix you approve — and only marks it fixed when an independent retest of the deployed version proves it.

Start with one server and one repo See how verification works

Read-only by default. Nothing changes without your approval.

Example finding
Vulnerable OpenSSL in api-gateway image
Verified fixed
  1. 09:12
    Detected by scheduled scan
    target sha256:4f1c…a9e0 · scanner 0.76.2 · db 6h old
  2. 09:14
    Investigated: reachable from the public API
    3 evidence references · severity, criticality and confidence kept separate
  3. 10:02
    Repair approved with MFA
    diff sha256:b72e…11c4 · base image bump · PR #418
  4. 10:31
    Deployed by your pipeline
    new target sha256:9d07…5b2f
  5. 10:33
    Independent retest of the deployed digest: clean
    Closed by evidence, not by a person or a model
Every step links to stored, immutable evidence.
A fix isn't fixed until it's proven.

Findings close only after a retest of exactly what you deployed.

Silence is not safety.

An unreachable server shows as stale, never as clean. A failed scan never counts as a pass.

AI explains. It never signs off.

Scanning, approvals and verification all work with AI switched off.

What it protects you from

Most breaches start with a known hole nobody closed.

Attackers rarely need something new. They use published vulnerabilities in software that was never updated, on systems nobody was watching. ZprotectZ closes that gap, and proves it stays closed.

Known vulnerabilities

Outdated packages on your Linux servers, in your container images and in your code's dependencies — the published CVEs attackers scan the internet for.

Forgotten systems

The server nobody owns, the repository nobody checks. Everything you connect stays on the list, and anything that goes quiet is flagged, not assumed safe.

Fixes that never shipped

A patched branch is not a patched server. Findings close only when the version actually running is retested clean — and reopen if the problem comes back.

Rushed or unreviewed changes

Repairs arrive as pull requests. Nothing changes until a named person approves that exact change with two-factor sign-in.

Signs of compromise

Know early when something has already gone wrong: system or website files changed without a deployment, new user accounts or SSH keys, new open ports, unusual outbound connections or logins. Every signal arrives with its evidence, in the same audited workflow — and works alongside your existing antivirus and firewall.

How it works

One loop, from discovery to proof.

01

Discover

A small Linux agent and a read-only GitHub connection build your inventory. Outbound connections only.

02

Check

Sandboxed scans of images and dependencies, recording target digest, scanner version and data age.

03

Investigate

Each finding gets context: what's affected, how exposed it is, and the evidence behind every claim.

04

Repair

A proposed change as a pull request. You approve the exact diff, with MFA. Your pipeline deploys it.

05

Verify

An independent retest of the deployed version closes the finding — or reopens it.

Verification

Most tools stop at the alert. We stop at the evidence.

Typical scanner
ZprotectZ
When is a finding closed?
When someone marks it resolved
When a retest of the deployed digest is clean
A server stops reporting
No new findings, so it looks fine
Coverage marked stale, shown first
Approving a fix
A ticket comment
Bound to the exact diff and version, with MFA
Role of AI
Often decides severity or closure
Explains with cited evidence; never verifies
Audit trail
Editable logs
Append-only, tamper-evident, exportable

Security by design

Built for people who read the fine print.

Your data stays yours

Tenant isolation is enforced by the database itself, and tested on every build with real roles.

MFA where it matters

Privileged roles always use two factors. Approving a change asks you to confirm again.

An audit trail you can trust

Every decision — allowed or denied — is recorded in a hash-chained log that shows any tampering.

Read-only first

Start with visibility. Repair permission is separate and only used for changes you approve.

Scans in a sandbox

Scanners run isolated, with pinned and signature-checked versions, and never inside your network's trust.

Honest coverage

See what is covered, what is stale and what failed — separately from what is vulnerable.

For teams that ship software and run it.

ZprotectZ sits alongside the scanners, firewalls and backups you already have, and closes the loop between finding a problem and proving it's gone.

Software companies

Repositories, images and the servers they run on, in one view.

SaaS operators

Evidence you can show customers when they ask how you handle vulnerabilities.

Hosting businesses

Many servers, many owners — every one accounted for, none silently stale.

Getting started

Your first useful assessment, the same day.

Start small: one server and one repository. Add more when you've seen what it finds.

  1. 1
    Create your organisation
    Sign in, set up your authenticator, invite your team with the roles they need.
  2. 2
    Connect a repository, read-only
    Install the GitHub app on the repositories you choose. Nothing else.
  3. 3
    Enrol a Linux server
    One single-use enrolment command. The agent only connects out; no inbound ports.

Simple plans, priced per monitored asset.

Starter

Inventory, scanning, evidence and verified repairs.

Professional

Adds AI investigation within your budget, and evidence exports.

Enterprise

Dedicated deployment, your region, contract retention and support terms.

Know what's exposed. Prove what's fixed.

Book a walkthrough Read the security overview