How Cyberismo works

Cyberismo is a content format, a reasoning engine and a set of reusable modules. The engine reasons over your content, so when something is not done it can tell you why, and not only that a box is unticked.

This page goes through the four parts and what each one does.

One: the content

Everything you author is a card, and every card is a file

A card is the unit of information: a risk, a control, a security requirement, a threat, an architecture decision, a review task, a controlled document. Technically it is a directory with an AsciiDoc document, a JSON metadata file and any attachments, which makes a Cyberismo project an ordinary Git repository.

Cards have types, types have workflows, and cards link to each other with typed links: this control mitigates that risk, this test verifies that requirement, this data flow crosses that trust boundary. The result is a graph that the machine can reason about.

Because it is plain text in version control, you get code review, history, branching and diffs for your security documentation.

Two: the reasoning engine

A logic engine reads the graph and explains itself

Cyberismo embeds Clingo, a mature Answer Set Programming solver. Rules about what compliance means for your content are written as logic programs, and the engine evaluates them against the whole project every time it runs.

The progress percentages, the maturity view, the calculated fields, the reports and the policy checks all come out of that evaluation, and so does the sentence of explanation attached to every verdict.

A table with columns for control, assessment and assessment explanation. Rows read Not OK or Open, each with a written reason such as 'The control is in scope but the linked evidence is not ready'.
Four controls, with a different reason given for each.
A maturity overview showing six lifecycle stages (Foundation, Design, Implementation, Verification, Releases, Operations), each with a computed completion percentage.
Progress metrics are computed from the content, so they cannot drift away from it.

What the engine checks

It verifies structure and relationships: that required evidence is linked, that a reviewer is not also the owner of the document under review, that a control is in scope, and that a periodic review happened inside its period. It does not judge whether a threat model is a good threat model. That still takes an expert, and what Cyberismo adds is that the state of the work is visible while it is going on.

Three: AI assistance

How AI assistants fit in

Cyberismo ships an MCP server, so an AI assistant can work directly on the content: drafting documents, filling in evidence, building data flow models from a description, finding the gaps and chasing them. Language models are good at this kind of repetitive compliance work.

What makes this workable is the reasoning engine described above. Whatever the assistant produces still has to satisfy the logic program before anything reads as compliant, and a human still approves the result. An auditor who asks how you know the AI-generated documentation is correct has something concrete to look at.

Four: the modules

Modules you import and adapt

A module is a reusable package of card types, workflows, templates, link types and logic programs. Modules stack, so an EU CRA project sits on top of a secure development project instead of replacing it.

Base

Open source

The foundation every Cyberismo project imports.

Details Source

ISMS Essentials

Open source

Building blocks for an information security management system.

Details Source

Secure Development Essentials

Open source

What a development team needs to start doing secure development.

Details Source

EU CRA Essentials

Open source

The essential requirements of the EU Cyber Resilience Act.

Details Source

ISO/IEC 27001

Subscription

Full coverage of the information security management standard.

Details

IEC 62443-4-1

Subscription

Secure product development lifecycle for industrial systems.

Details

IEC 81001-5-1

Subscription

Secure development lifecycle for health software. In development, not yet available.

Details

Threat modelling, worked through

Threat modelling is the clearest example of all four parts working together. You model processes, data stores, external entities and trust boundaries as cards, and the data flows between them as links. The diagrams are generated from that model.

The modelling experience is graphical and there is no new notation to learn, but the result is plain text under version control, and the risks and requirements it produces are linked back to the components they belong to.

Threat modelling docs
An automatically generated data flow diagram with processes, external entities, a data store and a labelled trust boundary.

Three ways to use the same content

One project, one content format. What changes is how you work with it, and what format it comes out in when you hand it over.

The app

A browser interface for everyday work: navigating, editing, moving cards through their workflow and reading generated reports. Run it locally, or use Cyberismo Cloud.

The command line

The same operations as scriptable commands, plus validation, report generation and every export format. This is what runs in CI.

A publication

cyberismo export turns the content into something you can hand over: a self-contained static website, or a PDF.

You choose the scope: a single card, a card and everything beneath it, or the whole project. So a threat model can go out as one controlled document while the full project is archived alongside a release.

The Cyberismo application showing the status and next steps page of a project.

Architecture

Cyberismo solution architecture diagram

Read the architecture documentation →

Run it yourself or let us run it

The application is the same either way, and your content stays in your own Git repositories. What you choose is who operates the software.

On your own machines

The open-source app and command line tool run locally and in your CI/CD pipeline, free of charge. This is a good starting point for a single team.

Get started →

Cyberismo Cloud

We host the same application for you in your own isolated tenant in the EU, with single sign-on through your identity provider. Your team works in the browser, and nobody on your side has to look after servers, upgrades or backups.

About Cyberismo Cloud →

A custom deployment

For regulated environments where the software has to run inside your own perimeter. We scope it to what your environment needs and agree it case by case.

Trust and security →

Try it

In your browser

A hosted demo project with a full secure development example. Takes a minute or two to start up.

Open the demo →

In a container

The same demo, running locally, with nothing to install but Docker or Podman.

docker run --init --rm -it -p 3000:3000 cyberismo/cyberismo-demo

On your machine

Install the tool and start a project of your own.

Installation guide →

Contact

  1. 01

    A short conversation

    Thirty minutes on what you are trying to achieve and which standards apply.

  2. 02

    A concrete proposal

    Which modules, hosted or self-run, what adoption support you would want, and what it costs.

  3. 03

    You try it first

    We recommend that your team tries the open-source version before you buy anything.

Henry Haverinen

Henry Haverinen

Managing Director

+358505944899 / Send email

Sami Lempinen

Sami Lempinen

Principal DevSecOps Advisor

+358504876750 / Send email

Cyberismo is based in Tampere, Finland. We work smoothly with teams anywhere in the world.