Skip to main content

What is the CyberOptix CTEM Platform?

The CyberOptix CTEM Platform is a continuous threat exposure management platform. It finds what you have, works out which parts of it are a problem, and tracks the problems through to fixed.

The thing that distinguishes it from a collection of scanners is that everything lands in one findings queue with one severity scale, one set of statuses, and one set of deadlines - whether it came from a network scan, a cloud misconfiguration check, a code dependency, an endpoint agent, or a breach corpus.

That matters because the alternative is what most organizations actually have: six consoles, six severity scales, and no way to answer "what is our most urgent problem?" without a spreadsheet.

What it does​

Finds what you have​

Discovery runs from several directions, because no single vantage point sees everything:

  • From outside, against your verified domains - what an attacker can see.
  • From inside, using scanners you deploy.
  • From your cloud providers, through read-only integrations.
  • From your source control, for applications and their dependencies.
  • From your EDR, for endpoints.

Works out what is wrong​

Each source contributes findings: vulnerabilities, misconfigurations, exposed credentials, insecure code and dependencies.

They are normalized into one model, so a Critical is a Critical regardless of which scanner found it. See Findings, severity, and risk.

Tracks it to fixed​

Findings are assigned, worked, and closed - and closed means a subsequent scan stopped seeing it, not that someone said so. Deadlines come from SLA policy you set.

Watches what is happening​

Optionally, the platform also collects logs, runs detections, and raises alerts. This part is off by default and is opt-in per organization. See Security Operations.

How the parts fit​

        discovery                     assessment                work
  ┌────────────────────┐        ┌──────────────────┐      ┌─────────────┐
  │ attack surface     │        │                  │      │             │
  │ cloud accounts     │───────▶│    findings      │─────▶│ remediation │
  │ applications       │        │  one queue, one  │      │  with SLAs  │
  │ identities         │        │  severity scale  │      │             │
  │ endpoints          │        │                  │      │             │
  └────────────────────┘        └──────────────────┘      └─────────────┘

        collection                    detection              response
  ┌────────────────────┐        ┌──────────────────┐      ┌─────────────┐
  │ logs from your     │───────▶│  rules, opt-in   │─────▶│ alerts and  │
  │ estate             │        │                  │      │ incidents   │
  └────────────────────┘        └──────────────────┘      └─────────────┘

The top row runs from the moment you verify a domain. The bottom row collects as soon as you point logs at it, and does nothing further until you enable detection.

Who it is for​

Security teams who need one view of exposure rather than one per tool.

Engineering teams who need to know which of their things are a problem, without reading someone else's estate. Business units are what make that work.

Service providers running the platform on behalf of several clients, each in its own organization with its own data, users and branding.

Auditors and leadership, who need evidence and trend rather than access - which is what the auditor role and reporting are for.

What it is not​

It is not an EDR. It connects to yours rather than replacing it.

It is not a ticketing system. It tracks findings to closure and integrates with Jira, but the work happens in your tools.

It does not fix things. It tells you what to fix, how urgent it is, and confirms when it is done.

Where to start​

Getting started is the shortest path to useful results: create an organization, verify a domain, and read your first findings. Most of what follows depends on those two steps.

If you would rather understand the model first, Concepts covers what sits underneath every screen.