Connecting Cyberismo to your tool chain
Compliance status, metrics and reports should update as engineering work proceeds, without anyone copying data by hand into a compliance tool.
Cyberismo does this in three quite different ways. They often get grouped together under the word “integrations”, so it is worth taking them separately.
Source control
Any Git host, with nothing to integrate
A Cyberismo project is an ordinary Git repository of plain text files. So it works with GitHub, GitLab, Azure DevOps, Bitbucket, Gerrit or a Git server of your own, for the same reason your source code does: there is nothing host-specific in it.
Source control is not on the connector list below because it does not need a connector: your content lives there, and connectors read data from other systems.
The practical consequences are branches and pull requests for security documentation, review before merge, history and diffs, and the same repository checked out by your pipeline.
Connectors
External data becomes facts the engine can reason about
A connector fetches data from another system and turns it into logic facts. Once the status of a ticket is a fact, an automated check can require that the issues linked to a control are closed, and a progress metric can span both systems.
Atlassian Jira
AvailableIssue status becomes a fact the reasoning engine can use, so a control can require that its linked tickets are closed, and your progress metrics can combine Jira and Cyberismo without anyone copying data between them.
Dependency-Track
AvailableComponent vulnerabilities from your SBOMs land beside the assets and products they affect, so third-party vulnerability management is part of the same status view as everything else.
In development
Atlassian Confluence
Evidence that lives in Confluence stays there, and the engine can still check it. An automated check can require that a referenced page exists and that its page properties, such as an approval state or a review date, are what the control expects, so missing or out-of-date evidence surfaces as a failed check rather than a dead link.
DefectDojo
Security testing findings feed the same issue tracking and policy checks as everything else, closing the loop between testing and the controls that require it.
Azure DevOps
Work items in Azure Boards become facts the reasoning engine can use, in the same way as Jira issues, so a control can require that its linked work items are closed and your progress metrics can span both systems. Keeping your Cyberismo content in Azure Repos needs no connector.
These are under development and not yet available. If your timeline depends on one of them, ask us where it currently stands.
Connectors are a subscription component, priced per connector. See the offering.
If your system is not on the list
Every connector follows the same open contract. A connector declares itself, describes each external item it imports, and emits the facts that describe those items. That contract is published as part of the documentation, and our own connectors use it. There is no privileged internal API that only we can reach.
This means your integrations do not depend on our roadmap, and the systems you depend on stay reachable whether or not we build a connector for them ourselves.
So you have two routes. Your own developers can write a connector against the published contract, for an internal system or one we do not cover. Or we can build it for you, and maintain it: getting the data model right for compliance reasoning, handling authentication and rate limits, and keeping it working as the other system changes its API underneath you. That maintenance is most of the long-term cost of an integration, and it is included in a supported connector.
Your pipeline
In CI, it is the same command line tool
Because your content is a Git repository, running Cyberismo in CI needs no special mode and no separate product. It is the same command line tool your team runs locally, checking out the same content.
So a release candidate that has drifted from your process can fail the build before it reaches your stakeholders, evidence can be published on every merge, and the status your management sees is generated from the content instead of being assembled for the meeting.
Validate
Run the automated policy checks and fail the build when they fail.
Publish
Export the project as a static site or a PDF, and archive it with the release.
Report
Generate the metrics and compliance reports on a schedule, from the current content.
Whichever Git host you use, the pipeline step is the same: check out the content and run the command line tool.
Identity
Your people sign in with the accounts they already have
Cyberismo Cloud authenticates through OIDC and federates to your own identity provider, such as Microsoft Entra ID, with role-based access control for administrators, editors and readers.
This is part of the hosted service rather than a connector: no external data is imported, and the reasoning engine is not involved.
Dependency-Track, hosted by us
Dependency-Track is the OWASP flagship platform for tracking component vulnerabilities from your SBOMs. If you would rather not run it yourself, we host it for you in the same environment as your Cyberismo Cloud tenant, on its own subscription.
Paired with the Dependency-Track connector, third-party vulnerabilities show up beside the assets and products they affect, inside the same status view as the rest of your security work.
Contact
- 01
A short conversation
Thirty minutes on what you are trying to achieve and which standards apply.
- 02
A concrete proposal
Which modules, hosted or self-run, what adoption support you would want, and what it costs.
- 03
You try it first
We recommend that your team tries the open-source version before you buy anything.
Cyberismo is based in Tampere, Finland. We work smoothly with teams anywhere in the world.