An ISMS fed by hand is out of date the day after the audit. OdySecure pulls incidents, vulnerabilities and assets from the systems you already operate, and pushes tasks back to where your team works on them.
The chain is short and it is continuous. Between detection and an assigned task, nobody retypes anything.
Wazuh, Zabbix, Graylog, CrowdSec, TheHive and others deliver alerts, vulnerabilities and assets into the platform.
The alert becomes an incident or a vulnerability in the management system, with origin, timestamp and a link to the affected asset.
OdyAgent reads the incident, knows the catalogue of severities, searches comparable cases and submits a classification.
From that, a ticket can be created in Jira or ServiceNow, with a lock against duplicates and its own audit trail.
And here it ends, explicitly: OdySecure does not write back into Wazuh or Zabbix and fixes nothing there. The connectors to monitoring and alerting systems read. Writing happens into the ticket systems.
“Reads” means OdySecure pulls from the system. “Writes” means OdySecure creates something there. What a connector delivers is listed beside it.
| System | Delivers | Direction |
|---|---|---|
| Security monitoring and alerts | ||
| Wazuh | Incidents, vulnerabilities, assets | reads |
| Graylog | Events and alerts as incidents | reads |
| CrowdSec | Local API alerts as incidents | reads |
| TheHive | Alerts and cases as incidents | reads |
| Shuffle | Workflow alerts as incidents | reads |
| Keycloak | Security relevant events as incidents | reads |
| Vulnerabilities | ||
| DefectDojo | Findings into the vulnerability module | reads |
| Dependency-Track | Findings from dependencies | reads |
| Assets and inventory | ||
| Zabbix | Assets and incidents, two streams | reads |
| Greenbone (GVM) | Hosts from the scan inventory | reads |
| NetBox | Devices and virtual machines | reads |
| Snipe-IT | Inventory | reads |
| Fleet with osquery | Host inventory | reads |
| Velociraptor | Host inventory | reads |
| Tasks and operations | ||
| Jira | Tickets from incidents and measures | writes |
| ServiceNow | Incidents in, tickets out, plus the CMDB | reads and writes |
| Others | ||
| GoPhish | Campaigns and results of phishing simulation | reads |
| Rating providers | Cyber ratings for supplier risk | reads |
The registry holds 21 connector types. Two of them are generic connections for systems without a dedicated connector (SIEM/SOAR and an API key based access), and the CMDB connection is marked in the source as a stub. That is why eighteen are named here rather than twenty-one.
No. Both connectors read. The alert becomes an incident in OdySecure that is classified and assigned; remediation happens where it belongs and is tracked as a measure.
For systems without a dedicated connector there is a generic API key based connection. Whether it carries in your case is something we settle against a concrete example, not in advance.
No. Creation runs against a per-object lock, and every operation gets its own line in the audit trail.
Integrations are not a separate product but the supply line: they fill the same data foundation from which risks, measures and evidence arise.