Integrations
Integrations are how the CyberOptix CTEM Platform learns about things it cannot reach on its own. Almost every section depends on one: Cloud Exposure needs a cloud account, Application Exposure needs source control, Endpoint Security needs an EDR vendor.
An entitled section that looks empty is usually an integration that has not been connected yet.
What can be connected
Cloud
| Vendor | Contributes |
|---|---|
| AWS | Resource inventory, CloudTrail activity, CloudWatch logs, GuardDuty findings, posture assessment |
| Azure | Resource inventory, activity and resource logs, Entra ID, sign-in, provisioning, directory audit and risk detection logs, Defender, Intune, Power Platform, posture assessment |
| GCP | Resource inventory, audit logs, posture assessment |
Each is read-only. Nothing is deployed into your account and nothing is changed.
The one exception to a read-only grant is Power Platform. The CyberOptix CTEM Platform only reads, but Microsoft requires an admin-level registration to read Power Platform inventory. See Power Platform.
Source control
| Vendor | Contributes |
|---|---|
| GitHub | Repositories, Dependabot alerts, code scanning alerts, secret scanning alerts |
| Azure DevOps | Repositories and pipeline activity |
Endpoint
| Vendor | Contributes |
|---|---|
| CrowdStrike | Alerts, devices, vulnerabilities, event stream |
| SentinelOne | Threats, agents, activities, deep visibility |
| Carbon Black | Devices, alerts, vulnerabilities, watchlists |
| Microsoft Defender | Devices, vulnerabilities, software inventory, recommendations |
Network and security appliances
| Vendor | Contributes |
|---|---|
| Palo Alto | Traffic, threat and URL logs; configuration and review; host and network discovery; NAT policies |
| Fortinet | Traffic, threat and event logs; configuration and review; host and network discovery; NAT policies |
| Cisco | ASA and FTD logs; configuration and review; host and network discovery; NAT policies |
The appliance integrations do more than collect logs: configuration review assesses the device itself, and host and network discovery uses what the firewall already knows about your network - which often sees further than a scanner can reach.
Ticketing
| Vendor | Contributes |
|---|---|
| Jira | Two-way issue sync, reconciliation, ticket automation |
Connecting one
Integrations → Available Integrations, choose a vendor, follow its flow. What is needed differs:
SCREENSHOT: the Available Integrations catalogue.
- Cloud - a read-only role or service principal you create. See Cloud Exposure.
- Source control and Jira - an OAuth authorization.
- EDR and appliances - API credentials from the vendor.
Active Integrations
Everything you have connected, with its status and sync configuration, lives under Active Integrations. It is where you go to check an integration is still healthy, change which sync types are enabled, or re-authorize one whose credentials have expired.
Worth checking periodically rather than only when something looks wrong: an integration whose token has been revoked usually reports no error at all, because nothing is failing - the vendor has simply stopped answering.
Sync configuration
An integration is not all-or-nothing. Each exposes sync types you enable individually, which is how you take a vendor's inventory without its log volume, or its alerts without its telemetry.
That granularity is worth using deliberately. Log-shaped sync types - traffic logs, CloudWatch, deep visibility - carry far more volume than inventory ones, and volume is the largest consumption dial in the platform. See Detection engineering.
Network-local targets
Where a target has no public endpoint - an on-premises Jira, an internal source control server - the platform reaches it through an integrator deployed inside your network.
When an integration stops working
Almost always credentials:
- Expired or revoked credentials. OAuth grants get revoked, API keys rotate, service principal secrets expire. This usually presents as "data stopped updating" rather than an error, because nothing is failing - the vendor has stopped answering.
- Reduced permissions. A scope or role narrowed on the vendor side removes some sync types and leaves others working, so the integration looks healthy while part of it is not.
- Removed webhooks. For source control, a repository or organization policy change can remove the webhook registration. See Webhooks.
Reconnecting re-authorizes and re-registers, which fixes most of these.
API
The endpoints behind this section are in the API reference.
Next
- API keys - for integrations you build yourself
- Webhooks - the inbound endpoints vendors post to
- Power Platform - the registration Power Platform inventory needs
- Cloud Exposure - connecting a cloud account