Security assessment as code

Security decisions you can trace back to evidence.

Dokimos validates a signed engagement scope, human-adjudicated findings, hashed evidence and release criteria agreed before testing. Then it builds the assessment report or the pre-production gate decision from that one validated record.

δόκιμος · dokimos, “tested and found genuine”

Fail closedMissing, invalid or unassessed blocking criteria never become GO.
Human adjudicationScanner and AI output is candidate evidence until a named person decides.
Hashed evidenceEvery artefact is hashed at collection and checked again before delivery.
One recordHTML, PDF, Markdown, CSV and JSON outputs come from the same validated data.

How it works

From scope to deliverable, with every step checked.

  1. 01

    Scope

    An engagement file records the targets, modules, evidence policy and, for a gate, the criteria agreed with the product owner before testing starts. Unknown fields are rejected.

  2. 02

    Findings

    Tool output comes in as candidates. A named adjudicator confirms, rejects or re-rates each one; tool severity is never accepted automatically.

  3. 03

    Evidence

    Requests, tool results and run manifests are stored with SHA-256 hashes, so a reviewer can confirm nothing changed after collection.

  4. 04

    Build

    Validation profiles (draft, final, gate) decide what may ship. The build writes the report and a manifest that records exactly what it was built from.

Full assessment

A broad, multi-source review and remediation record. It covers the complete finding register and gives no release verdict.

s1-review build assessment ./engagement

Pre-production gate

A time-boxed decision against criteria agreed before testing. Only declared rules and manual criteria are evaluated.

s1-review build gate ./engagement

Outputs

Reports written for the person who has to decide.

Quiet typography, colour only where it carries meaning, and one signature element per document. Each page states its intended audience.

Screens come from the bundled worked example. Every system, name and value in it is fictional.

Gate verdicts

A verdict is a decision about recorded criteria.

GO

Every configured criterion passed for the recorded target, scope and window.

GO WITH CONDITIONS

No blocking failure remains, but a non-blocking criterion did not pass. Each condition needs an owner and a due date.

NO-GO

A blocking criterion failed or was not assessed. The release waits until it is closed and re-verified.

NO VERDICT

The input was incomplete or invalid, so no decision is issued. The gate fails closed.

A GO does not mean the product is secure, free of vulnerabilities or approved outside that decision. Dokimos makes claims consistent and traceable; it does not create assurance that the scope and evidence do not support.

What it is not

Clear about its limits.

  • Not a vulnerability scanner. Scanner output is input for human triage.
  • Not authorization to test. Intrusive work needs its own written approval and an isolated environment.
  • Not an issue tracker or a signing service.
  • Not proof that a product is secure.

Bring your next assessment or release gate.

Dokimos is developed by CyberTwierdza. Get in touch to see it on your own engagement.

Contact CyberTwierdza