DEV Community: Saint Zero Day

One install, many customers: building airtight multi-tenancy into a self-hosted security platform

Saint Zero Day — Tue, 02 Jun 2026 04:39:38 +0000

I build a self-hosted security platform in Go. Today I shipped one of its biggest capabilities: one install that can host many customers, each one fully sealed off from the others. Multi-tenancy, done so the walls between customers are airtight.

Here's what I built and how it works.

The goal: two deployment models from one codebase

I wanted both of these to be true at the same time:

One install per customer — the simple, self-contained mode (everything defaults to a single tenant).
One install, many customers — a central server hosting a whole book of clients, each isolated.

The second is just the first with more than one customer in it. The hard part is the word airtight: Customer A must never read or touch Customer B's data, by any path. So I designed isolation in two directions — the read side (what an operator sees) and the write side (what agents on customer machines send in).

Read side: every query knows its customer

Every table already carried a tenant_id. The work was making sure every by-id lookup is scoped to the customer you're actually viewing:

func (db DB) GetIncident(id, tenantID int64) (IncidentRow, error) {
    // ... WHERE id = ? AND tenant_id = ?
    // an id from another customer simply returns "not found"
}

The operator's current customer lives in their session; the dashboard and the API both resolve it the same way and thread it down to the store. Pick a customer in the switcher and the entire dashboard — every page, every alert, every agent — follows it. Default to a single tenant and the behavior is identical to the single-install mode, so nothing about the simple path changes.

I locked this down at the data layer rather than trusting handlers to remember, and I proved it with an adversarial test: stand up two customers, then assert one can't read or mutate the other across every domain. That test is the real deliverable — the scoping is just what makes it pass.

Write side: bind the agent to the customer at install time

Agents run on a customer's machines (think a ZDS agent on their domain controller) and report back. Their data has to land in their tenant and nowhere else. Before building this I went and read how the people who do it at scale handle it.

Some folks bind an agent to a customer at install time with a token — a per-organization secret baked into the deploy. The agent never gets to say which customer it belongs to; the token already decided. While others pins its agent channel with a certificate so nothing can impersonate it. That's the model, and it's a good one, so I built the same thing.

Each customer gets a per-tenant enrollment secret. An agent can only register into the customer whose secret it presents:

// constant-time compare; empty secret = "no token required" (single-install back-compat)
if enrollSecret != "" &&
   subtle.ConstantTimeCompare([]byte(req.EnrollSecret), []byte(enrollSecret)) != 1 {
    writeError(w, http.StatusForbidden, "invalid or missing enrollment secret")
    return
}

Every agent also carries its own mTLS client certificate, issued at enrollment. So when an agent reports in, the body's agent_id has to match the certificate's common name, and the tenant always comes from the enrolled record — never from anything the request claims:

// the agent id is client-supplied; bind it to the verified cert so an agent
// can't report (and write) as another agent / another customer
if !s.agentCertMatches(r, req.AgentID) {
    writeError(w, http.StatusForbidden, "client certificate does not match agent id")
    return
}

The control plane gets the same treatment: an operator can only see and command agents that belong to the customer they're viewing.

// 404 unless the agent belongs to the caller's tenant — you can't read, control,
// or even confirm the existence of another customer's machines
func (s Server) agentInTenant(w http.ResponseWriter, r http.Request, agentID string) *model.Agent {
    a, _ := s.db.GetAgentByAgentID(agentID)
    if a == nil || a.TenantID != tenantID(r) {
        writeError(w, http.StatusNotFound, "agent not found")
        return nil
    }
    return a
}

Products per customer

The same platform sells differently to different customers, so add-on capabilities — EDR, identity threats, attack-surface, patch management, and the rest — are toggled per customer. The nav, the route gating, and the settings toggles all key off the current customer. A new customer starts with the core platform and nothing else; you turn on what they bought. There's a Customers screen to create a customer (which hands you its one-time enrollment token), a switcher to move between them, and a one-click way to rotate a token if it's ever exposed — old agents keep running, only new enrollments need the new one.

Proving it, not assuming it

Isolation isn't a property you design in — it's a claim you have to attack until it stops being true. So there are two layers of adversarial tests: a store-level suite that proves cross-tenant reads and writes fail across every domain, and an end-to-end HTTP test that stands up two customers and an agent and confirms one can't read another's data or dispatch a command to another's machine. A couple of deliberate trade-offs are written down rather than left implicit — the operator API key is the admin credential, not a tenant boundary, and mTLS has to be on for the agent-identity binding to hold.

Tamper-evidence: the records can't be quietly rewritten

Isolation keeps customers apart. The other half of trust is making sure the record of what happened can't be silently altered — including by someone who's already inside the box. For that, the platform anchors its important events to an immutable, hash-chained, signed ledger I built called SaintChain.

Four kinds of event get anchored: audit actions (who did what), finding creation and state changes, backup events (including each scan run's Merkle root), and chain-of-custody evidence handling. Each one is a hash chained onto the last and signed, so any after-the-fact edit breaks the chain and chain verify catches it.

It runs in two modes:

# embedded ledger — zero config, on by default
zds-core serve --chain
# tamper-PROOF — anchor to a separate SaintChain daemon (its own OS user/process)
zds-core serve --chain-endpoint http://127.0.0.1:7433

Embedded is the convenient default. Remote is the strong one: because the SaintChain daemon runs as its own process and owns the signing key, a compromised app can append to history but can't rewrite it — the thing holding the pen isn't the thing being audited. Add an off-host checkpoint of the chain head and even a fully-compromised host can't quietly edit the past without the discrepancy surfacing somewhere it doesn't control.

So multi-tenancy gives you walls between customers; SaintChain gives you a record of what happened inside those walls that you can actually trust.

Then I made it teach itself

A capability you can't explain isn't worth much, so the second half of the day was documentation — an architecture write-up and a full operator manual for the dashboard.

Then I built a pipeline to turn that manual into narrated how-to videos, entirely locally, no paid services:

Voice — Piper TTS, a neural voice rendered offline.
Screenshots — headless Chrome driving the real dashboard, seeded with demo data.
Assembly — ffmpeg: clean slides with soft fades, a mouse pointer that glides to whatever the narration is describing, and live subtitles synced sentence-by-sentence (I render each sentence's audio separately so the timing is exact).

A few hard-won ffmpeg notes, in case they save you an evening:

ffmpeg inside a while read loop eats the loop's stdin and corrupts your file list — pass -nostdin.
An unbounded -loop 1 overlay input makes ffmpeg encode frames forever — bound it with -t and overlay=...:shortest=1.
The Ken Burns zoompan jitters on slow moves because it crops on integer pixels; static slides look smoother than bad motion.
TTS that peaks at 0 dB clips and sounds harsh — loudnorm to -16 LUFS with headroom fixes it.

Nine videos, about five and a half minutes, the whole dashboard explained in its own voice. The pipeline is four small scripts; adding a section is editing a spec file.

Where this leaves the platform

One server can now run a whole roster of customers with real walls between them, agents that can only ever belong to the customer they were deployed for, products sold per customer, and a documentation set that explains the whole thing. It's the difference between a tool I run for myself and a platform I could run for many — built the way I want to build everything: airtight, and proven.

You can find the platform at szdsecurity.com.

It ran it works: I audited my own security platform and found a detection engine that never ran

Saint Zero Day — Mon, 01 Jun 2026 06:56:43 +0000

I build a security platform. Last night I stopped adding features and did something less fun and more honest: I sat down to make every capability prove it actually works — end to end, with real data, demanding a real pass or fail.

"It ran" is not a pass. A page that renders is not a feature. A green checkmark is a claim, not evidence. So I went capability by capability and tried to break each one.

I found four real bugs and one of them was a gut-punch: a whole detection engine that was wired into the UI, unit-tested, and never actually ran in production.

Here's how the night went.

The rule: drive it, don't admire it

My method was boring on purpose. For each capability:

Feed it real input through the real entry point (CLI or API), not a test fixture.
Check the data actually landed (query the DB, don't trust the success message).
Feed it a malicious input and a benign input — it has to fire on one and stay quiet on the other.

The detection engine passed cleanly. I threw a PsExec process event at it and it lit up:

$ zds-core detection eval --event '{"event_type":"process_create","process_name":"psexec.exe"}'
1 alert(s):
  [high] PsExec Execution — (matched: map[process_name:psexec.exe])

A wevtutil cl Security event tripped a critical "Log Clearing" rule. A plain notepad.exe matched nothing. Good — it detects, and it doesn't cry wolf.

(Small UX papercut I fixed while I was there: if you forgot the event_type field, the engine silently matched nothing and printed "no rules matched" — which reads exactly like "you're safe." Now it warns you that the event can't match any rule. Silence that looks like safety is the most dangerous output a security tool can produce.)

The one that hurt: ITDR

Identity Threat Detection and Response. The engine has detectors for impossible travel, credential spraying, brute force, privilege escalation. All unit-tested. All green.

I ran the real flow: POST two login events for one user — New York, then London thirty minutes later. That's ~5,500 km in half an hour. Textbook impossible travel. Then I asked for the alerts.

Nothing. Zero alerts.

The events were in the database. The detector logic was correct in isolation. But the alerts endpoint was empty. So I read the ingest handler:

func (s Server) handleRecordITDREvent(w http.ResponseWriter, r http.Request) {
    var evt itdr.IdentityEvent
    json.NewDecoder(r.Body).Decode(&evt)
    id, err := s.db.InsertIdentityEvent(&evt)  // store it...
    // ...and return. That's it.
    writeJSON(w, http.StatusCreated, evt)
}

It stored the event and returned. It never called the detector. Every identity event in the system was being filed and forgotten. The engine that was the entire point of the feature had no caller. In production the alerts list would have been empty forever, and it would have looked like good news.

The fix was small once I saw it — hold a persistent detector on the server and run every event through it:

id, err := s.db.InsertIdentityEvent(&evt)
// ...
if a := s.itdrDetector.RecordEvent(&evt); a != nil {
    s.db.InsertIdentityAlert(a)
    alert = a
}

Re-ran the exact same two logins:

ALERT: impossible_travel  high  "impossible travel detected: 5570 km in 30m0s"
risk: critical (80)

That's the moment the night paid for itself.

The other three

CSAF export (vulnerability advisory) returned zero vulnerabilities even when findings carried CVEs. It built the advisory only from the vulnerabilities table, but a CVE imported from a scanner lands on the finding first. I ran a real Nuclei scan, it found a Log4Shell template match (CVE-2021-44228), imported clean — and the export dropped it. Fix: synthesize the advisory entry from the finding when the vuln table hasn't caught up. Now the CVE shows up where it belongs.
GRC compliance reported 0% against every framework. The "supported frameworks" list and the controls being scored were two different control-ID namespaces that never intersected. The command was structurally incapable of returning anything but zero. Pointed it at the frameworks the controls are actually tagged with — now it scores.
Workflow executions stored started_at in UTC and completed_at in local time. Same row, off by my timezone offset, quietly corrupting every duration. One column was using the SQLite CURRENT_TIMESTAMP default while the other came from the app.

What actually held up

Plenty did, and I made it prove it: incident lifecycle and timelines, the workflow engine, Diamond Model events, threat-hunting hypotheses, forensic hashing + YARA validation, case management with a real state machine, UEBA (I trained a baseline on nine normal logins and it correctly flagged a 3am login from Russia pulling 900 events as unusual hour + location + volume), and the Active Directory scanner against a real Windows Server 2022 domain controller — real findings, real MITRE mappings, no invented kerberoasting that wasn't there.

The lesson I keep relearning

The bugs that scare me aren't the ones that crash. They're the ones that return success while doing nothing. A detector with no caller. An advisory that silently drops the one CVE that matters. A compliance score that's structurally pinned to zero. Each one renders fine. Each one would demo fine. Each one is a lie your own dashboard tells you.

If you ship anything people rely on, spend a night being your own adversary. Don't ask "does it run." Ask "show me." Feed it the bad input. Query the table. Make the green checkmark earn it.

The detector runs now.

My test suite was green. My software was lying to me.

Saint Zero Day — Sat, 30 May 2026 05:22:16 +0000

My CI was green. 1,885 tests, 66 packages, zero failures. go vet clean. The build was a single self-contained binary. By every signal a Go project gives you, it worked.

Then I pointed it at something real, and watched it lie to my face.

This is the story of six bugs I found in my own security platform — ZDS Core — by refusing to trust a green checkmark. Five of the six belonged to the same scary family: the code reported success and stored nothing. No error. No stack trace. A 200 OK and an empty database.

If you ship anything that ingests data from the outside world, you have at least one of these right now. Let me show you what they look like.

The setup: test against reality, not fixtures

ZDS Core is a security platform written in Go — vulnerability scanning, an endpoint agent, EDR integrations, vuln-data feeds, compliance exports, the works. My unit tests were thorough. They were also, I realized, all talking to fixtures and in-memory SQLite. They proved my logic. They proved nothing about what happens when a real Wazuh server, a real OpenSearch cluster, or a real CVE feed shows up with data shaped slightly differently than I assumed.

So I spent a weekend wiring up the real things:

podman containers for an nginx target, a Wazuh 4.7 manager, an OpenSearch node
nmap for actual scanning
Live feeds: CISA KEV, FIRST.org EPSS, Google OSV, NVD
The endpoint agent running on my actual Fedora box

Rule for the weekend: "it ran" is not a pass. Data has to land, and it has to be correct. Then I went looking for lies.

Bug #1 — The endpoint agent that threw everything away

The agent registered with the server. It collected 2,343 software packages and a pile of open ports off my machine. The server logged results accepted for every batch. The agent was happy. I was happy.

The software table had zero rows.

failed to insert port finding 38810/udp: FOREIGN KEY constraint failed
failed to insert port finding 40319/udp: FOREIGN KEY constraint failed
...

The handler looked up the agent's asset by IP to get a parent asset_id. But nothing ever created that asset. So agentAssetID was 0, every insert violated the foreign key, and the error was logged-and-swallowed inside a loop while the endpoint cheerfully returned:

{ "accepted": true, "message": "accepted software_inventory results" }

The fix was to create the asset on first sight (idempotently), and — embarrassingly — to actually set AssetID on the port finding, which the original code never did. After that: 2,343 packages and 96 findings landed. The entire endpoint telemetry pipeline had been a no-op, and the API was reporting victory the whole time.

Lesson: an accepted: true you control is worth nothing. The only proof is the row.

Bug #2 — "Synced 1" / stored 0

Same family, different corner. My EDR alert sync said alerts synced: 1. The findings table was empty.

This one was a landmine hiding in a helper:

func (db DB) UpsertFinding(f model.Finding) (int64, bool, error) {
    ...
    if f.FingerprintHash == "" {
        return 0, false, nil   // <-- no error. no insert. nothing.
    }
    ...
}

A finding with no fingerprint returns (0, false, nil). No error. The caller increments synced++, logs success, moves on. Four different EDR code paths built findings without ever setting a fingerprint. Every alert and every vulnerability from those paths evaporated, silently, with a success message.

If you take one thing from this post: a function that returns nil for "I did nothing" is a trap. At minimum it should be loud. Ideally the type system shouldn't let you build the thing without the required field.

Bug #3 — The CVE that wasn't there

The OSV feed connector queried Google's OSV API for a CVE and reported Loaded 0 vulnerabilities. The API was returning 200 with a full record. I checked by hand:

$ curl -s https://api.osv.dev/v1/vulns/CVE-2021-44228 | jq '{id, aliases}'
{
  "id": "CVE-2021-44228",
  "aliases": ["GHSA-jfh8-c2jp-5v3q"]
}

The parser only scanned aliases for a CVE- prefix. But when you query OSV by CVE, the CVE is the record's id, and the alias is the GHSA. So the parser found no CVE, mapped to an empty ID, and dropped the result. Every CVE-keyed OSV sync had been a quiet no-op. One-line shape mismatch, total data loss.

Bug #4 — A removed endpoint nobody noticed

edr sync against a real Wazuh 4.7 manager: agents and vulns synced fine, alerts 404'd.

wazuh api GET /alerts?limit=500&offset=0 returned status 404

The code's own comment admitted the truth — "Wazuh 4.x alerts come from the indexer API" — and then queried the Manager API's /alerts endpoint anyway. That endpoint existed in Wazuh 3.x and was removed in 4.x; alerts now live in the Indexer (OpenSearch). The integration could never have worked against any modern Wazuh.

Fixing it meant actually implementing the Indexer query path (wazuh-alerts-*/_search), wiring an --indexer-url, and skipping gracefully when it isn't set instead of faceplanting on a dead URL. Then I stood up a real OpenSearch node, seeded an alert, and watched it flow all the way through to a stored finding:

scanner=wazuh  category=alert  severity=high
title=[5710] sshd: Attempt to login using a non-existent user

That end-to-end run is the only reason I believe it works. A unit test with a mocked response would never have caught that the endpoint itself was gone.

Bug #5 — The connector with no front door

I went to test the Nessus/Nuclei/OpenVAS importer and discovered there was no way to call it. The parsers existed, were unit-tested, and were registered in a nice little plugin registry — and absolutely nothing in the CLI or API ever invoked them. A whole feature with no door.

So I added one (connector import --tool nuclei --file ...), ran a real Nuclei scan against my nginx target, imported it — and immediately found:

Bug #6 — Nuclei findings, minus the CVE

Nuclei tags its CVE-template matches with a classification block:

"classification": { "cve-id": ["CVE-2021-44228"], "cwe-id": ["cwe-502"], "cvss-score": 10.0 }

My parser's struct didn't have a classification field, so encoding/json quietly dropped it. Every CVE that Nuclei detected lost its CVE on import — no correlation, no KEV matching, no CSAF export. The findings landed, but stripped of the one field that makes a vuln finding useful.

After the fix, the full chain finally worked: Nuclei scan → import → CVE finding → OSV enrich → correlate → CSAF-VEX 2.0 advisory. Six tools, one pipeline, and it took running every link to trust the chain.

What I actually learned

Green tests are a floor, not a ceiling. Mine proved the logic and hid every integration assumption I'd gotten wrong.
Silent success is the most dangerous failure mode. A crash gets fixed in an hour. A 200 OK that stores nothing survives to production and costs you a customer's trust.
"Accepted" is not "stored." Verify the row, not the response.
Field-shape mismatches are invisible in Go. encoding/json drops unknown fields without a peep. The CVE-in-id bug and the dropped classification block were both this. Decode strictly, or assert on the parsed result.
Run the whole chain against the real thing at least once. Every one of these six was only catchable with a live target.

All six are fixed, each with a regression test, and I wrote the evidence down — actual commands, actual output — in a VERIFICATION.md in the repo. If I'm going to ask people to trust this thing with their security, "trust me, the tests pass" isn't good enough. "Here's exactly what I ran and what it returned" is the bar.

The other thing that happened this week

In between bug hunts, I got the company site live: szdsecurity.com. Zero Day Security is the company I'm building this under — security and AI-adoption work, with the platform you just read about as the backbone. It's early. I'm pre-customer and building in the open, which is exactly why I'd rather publish the weekend I spent finding my own bugs than a glossy feature list.

If you build tools that ingest data, go try to break one this weekend. Point it at something real. I promise it's lying to you about something — the only question is whether you find out before your users do.

Building Zero Day Security. More war stories to come.

Has this site just turned into who can make the best stuff with Gemini?

Saint Zero Day — Sat, 18 Apr 2026 03:53:37 +0000

I'm Building a Full Security Operations Platform. Solo.

Saint Zero Day — Wed, 25 Mar 2026 03:16:39 +0000

I quit waiting for someone else to build the thing I needed.

For twenty years I've watched small organizations — government contractors, healthcare providers, critical infrastructure operators — get caught between two options: enterprise security tooling they can't afford, or nothing at all.

The enterprise stack costs six figures. It takes a team of twelve to deploy. It assumes you have a SOC, a SIEM, a dedicated compliance officer, and a budget that doesn't make your CFO cry.

Most organizations have none of that. So they run with nothing. Maybe an antivirus license and a prayer.

I'm building the third option.

What It Is

Zero Day Security (ZDS) is a full security operations platform designed for the organizations that the enterprise vendors forgot.

One platform. One deployment. Everything an organization needs to actually defend itself:

Vulnerability scanning — know what's exposed before an attacker does
EDR integration — pull endpoint telemetry from the agents you already run
Incident management — detect, investigate, respond, document
Compliance automation — NIST 800-171, CMMC Level 2, OSCAL exports that auditors can actually read
Threat intelligence — ingest feeds, correlate IOCs, know what's hunting you
Attack path analysis — see how an attacker chains vulnerabilities to reach crown jewels
Identity threat detection — catch credential abuse before it becomes a breach
External attack surface monitoring — know what you look like from the outside

This isn't a dashboard that shows you pretty graphs. This is the platform that does the work.

Why Solo

Because nobody else was going to build it.

I spent two decades in security. I've seen what works and what doesn't. I've watched vendors sell shelfware to organizations that needed real protection. I've watched compliance become a checkbox exercise instead of an actual security posture.

The problem isn't that the technology doesn't exist. The problem is that it's locked behind contracts, sales calls, and price tags that start at "call us."

So I'm building it myself. Every package. Every test. Every line.

Is that the smart way to do it? Probably not.

Is it getting done? Yes.

The Stack

Go. SQLite for portability. PostgreSQL when you need scale. HTMX dashboard because nobody needs another React app for a security tool.

No Kubernetes. No microservices. No twelve-factor ceremony. One binary. Deploy it. Use it.

The security industry has a complexity addiction. Every vendor adds layers because layers justify pricing. ZDS strips that out. You shouldn't need a platform team to run your security platform.

Where It Stands

The platform is built. Not "MVP built" — built built. The kind of built where you run the test suite and everything passes. The kind where the OSCAL export actually validates against the NIST schema.

What's next is production hardening. Real-world deployments. The unsexy work that turns software into a product.

What I'm Writing About

I'm going to document this build in public. Not the sanitized version — the real one.

How to design a security platform that doesn't require a team of twelve to operate
Integration patterns for EDR vendors who don't want you integrating with them
What NIST 800-171 actually requires vs. what compliance vendors tell you it requires
Building AI-driven security tooling that isn't just a ChatGPT wrapper with a vulnerability database
What it's like to build something this big alone and why I keep going

If you're a security engineer, a compliance professional, a solo founder, or just someone who thinks the security industry is broken — follow along.

This is Zero Day Security.

This is what I'm building.

I'm Saint Zero Day — GWOT veteran and security engineer. Find me here on DEV at @saintzeroday or on GitHub.

If you're interested in what I'm building with Notion MCP, check out SaintChain — a tamper-proof security blockchain inside Notion.

I Built a Tamper-Proof Security Blockchain Inside Notion

Saint Zero Day — Wed, 25 Mar 2026 02:13:37 +0000

Everyone else built todo apps. We built a security blockchain inside Notion.

What I Built

SaintChain turns Notion into a tamper-proof security event ledger. Vulnerability scans, incident reports, compliance checks, policy violations -- every event gets cryptographically hashed into blocks, chained with SHA-256 double hashing, signed with Ed25519, and stored directly in Notion databases via MCP.

Modify a single character in any record. The chain breaks. SaintChain proves exactly where.

This is the same integrity architecture that NIST 800-171 and SOC 2 require for tamper-evident audit logging -- running inside Notion, orchestrated by Claude Code, with Solana-style checkpoint anchoring as a proof of concept.

The pitch: What if Notion wasn't just a wiki, but a block explorer for your security audit trail?

How It Works

13 security events (real CVEs, incidents, compliance checks, policy violations) get ingested and sealed into 3 blocks, plus a genesis block that bootstraps the chain
Full chain verification -- double-SHA-256 hash linkage, Merkle root validation, Ed25519 signature checks on every block
Tamper detection -- modify one hash and every downstream block breaks. SaintChain pinpoints the exact failure
AI-driven forensics -- when tampering is detected, Claude writes a forensic incident narrative directly into Notion: what changed, what it means cryptographically, what to do about it
Solana-style checkpoint anchoring -- chain state gets signed and recorded for third-party verification. This is a local simulation -- no live Solana transactions. I'd rather build that correctly with real Solana developers than ship something half-broken for a contest

The Notion Workspace

Three databases and four pages, all created and populated by Claude Code via MCP:

Component	Purpose
Blocks DB	4 blocks with double-SHA-256 hashes, previous hashes, Merkle roots, Ed25519 signatures, verification status
Events DB	14 security events with type, severity, source, target, payload hash, block reference
Checkpoints DB	Solana-style anchor point with chain hash, Merkle root, TX signature
Dashboard	Chain health at a glance -- block count, event breakdown by type and severity
Verification Report (PASSED)	Block-by-block integrity check -- all green
Incident Narrative	CRITICAL alert -- forensic timeline of chain tampering at block 2
Verification Report (FAILED)	Post-tamper report showing the exact failure point

Full SaintChain workspace -- 3 databases, 4 pages, all populated via MCP

Blocks database -- each row is a sealed block with its double-SHA-256 hash, previous hash, Merkle root, and event count

Events database -- 14 security events across scanning, incidents, compliance, and remediation. Color-coded severity selects.

Checkpoints database -- Solana-style anchor with chain hash, Merkle root, and TX signature

Security Dashboard -- chain health status, event breakdown by type, severity distribution

Verification Report -- all 4 blocks pass integrity checks

Tamper detected at block 2. CRITICAL callout, incident timeline, forensic analysis, and remediation steps -- all written by Claude into Notion.

Post-tamper verification -- block 2 FAILED with hash mismatch and invalid signature. Exact failure details shown.

Demo

The demo walks through the full pipeline:

Generate Ed25519 keypair, create genesis block
Ingest 13 security events across scanning, incident response, and remediation
Batch events into 3 signed blocks with Merkle trees
Run full chain integrity verification (passes)
Sync all chain state to Notion databases and pages via MCP
Tamper with block 2's hash (simulating direct database manipulation)
Re-verify -- chain breaks at block 2, all downstream blocks invalidated
Claude writes a forensic incident narrative into Notion
Post-tamper verification report shows the exact failure point

Show us the Code

GitHub: saintzeroday/saintchain-notion

Architecture

saintchain/
├── crypto.py            # Ed25519 keys + SHA-256 double hashing (PyNaCl)
├── merkle.py            # Merkle tree construction + inclusion proofs
├── events.py            # Security event model, canonical JSON serialization
├── block.py             # Block model, double-SHA-256 hashing, chain linkage
├── chain.py             # Append-only ledger, verification, tamper detection
├── solana_anchor.py     # Solana checkpoint anchoring (local simulation)
├── notion_sync.py       # Chain state -> Notion database property payloads
├── notion_dashboard.py  # Dashboard page generator
└── notion_reporter.py   # Verification reports + incident narratives

65 tests across 6 files. Crypto, Merkle trees, blocks, chain integrity, event serialization, and Notion payload generation all tested independently.

The Crypto Engine

Ported from Saint Blockchain, my Rust implementation of an immutable security event ledger.

Double SHA-256 -- hash the hash to prevent length-extension attacks. Same pattern Bitcoin uses:

def double_hash(data: bytes) -> str:
    first = hashlib.sha256(data).digest()  # raw 32 bytes, NOT hex
    return hashlib.sha256(first).hexdigest()

Ed25519 signatures -- every block is signed. Deterministic signatures mean no nonce reuse risk:

def sign(self, data: bytes) -> str:
    signed = self._signing_key.sign(data)
    return signed.signature.hex()

Merkle trees -- events within a block form a binary tree. The root hash commits to all events at once. You can prove a single event exists in a block without downloading the others:

def merkle_root(hashes: list[str]) -> str:
    if not hashes:
        return hash_str("empty")
    if len(hashes) == 1:
        return hashes[0]

    current_level = list(hashes)
    while len(current_level) > 1:
        next_level = []
        for i in range(0, len(current_level), 2):
            if i + 1 < len(current_level):
                combined = current_level[i] + current_level[i + 1]
            else:
                combined = current_level[i] + current_level[i]
            next_level.append(hash_str(combined))
        current_level = next_level
    return current_level[0]

Chain Verification

The verification engine walks every block from genesis, checking three things:

Hash linkage -- does previous_hash match the prior block's hash?
Merkle root -- does the recomputed event tree match the stored root?
Ed25519 signature -- was this block signed by the chain authority?

When any check fails, verification stops and reports the exact failure:

def verify_chain(self, from_height: int = 0, to_height: int | None = None) -> ChainVerification:
    # ...
    for h in range(from_height, to + 1):
        block = self._blocks[h]

        if block.previous_hash != prev_hash:
            return ChainVerification(
                valid=False, blocks_checked=blocks_checked,
                first_invalid_height=h,
                error=f"previous hash mismatch at height {h}",
            )

        validation = block.validate(public_key)
        if not validation.merkle_valid:
            return ChainVerification(
                valid=False, blocks_checked=blocks_checked,
                first_invalid_height=h,
                error=f"invalid merkle root at height {h}",
            )
        if not validation.signature_valid:
            return ChainVerification(
                valid=False, blocks_checked=blocks_checked,
                first_invalid_height=h,
                error=f"invalid block signature at height {h}",
            )

        prev_hash = block.hash
        blocks_checked += 1

    return ChainVerification(valid=True, blocks_checked=blocks_checked)

Five independent integrity checks per block -- hash, Merkle root, signature, event payload hashes, and event count. Any single modification anywhere in the chain cascades into a verification failure.

Notion Sync via MCP

The sync layer converts chain state into Notion database rows. Each block becomes a database entry with its hash, previous hash, Merkle root, signature, and real-time verification status:

def block_to_notion_properties(block: Block, verified: bool = True) -> dict:
    return {
        "Height": {"number": block.height},
        "Hash": {"rich_text": [{"text": {"content": block.hash[:32] + "..."}}]},
        "Previous Hash": {"rich_text": [
            {"text": {"content": (block.previous_hash[:32] + "...") if block.previous_hash else "genesis"}}
        ]},
        "Merkle Root": {"rich_text": [{"text": {"content": block.merkle_root[:32] + "..."}}]},
        "Timestamp": {"date": {"start": block.timestamp}},
        "Event Count": {"number": block.event_count},
        "Verified": {"checkbox": verified},
        "Signature": {"rich_text": [{"text": {"content": block.signature[:32] + "..."}}]},
    }

The sync payload generator runs real-time validation on every block before pushing to Notion. If a block has been tampered with, its Verified checkbox shows up unchecked -- no manual flagging needed, the crypto does it.

When tamper detection fires, Claude generates a forensic incident narrative -- not a template fill, but a contextual analysis of what the hash change means, which blocks are affected, and what the response should be:

def generate_incident_narrative(chain: Chain, tampered_height: int, original_hash: str) -> dict:
    block = chain.get_block(tampered_height)
    current_hash = block.hash if block else "unknown"
    # Builds a Notion page with:
    # - CRITICAL callout block
    # - Numbered incident timeline (original hash -> modified hash -> detection -> cascade)
    # - Forensic analysis: what the hash change means cryptographically
    # - Remediation: isolate, restore from checkpoint, investigate, rotate keys, re-anchor
    # ...

How I Used Notion MCP

Notion is not a display layer here. It is the block explorer.

The same way Solana Explorer lets you browse transactions on Solana, the SaintChain Notion workspace lets you browse a security audit blockchain:

Blocks database = block explorer -- click any block to see its hash, previous hash, Merkle root, signature, event count, and verification status
Events database = transaction ledger -- every security event is a row with type, severity, source, target, payload hash, and block reference
Checkpoints database = anchor registry -- Solana-style checkpoints with TX signatures for third-party verification
Dashboard page = chain health monitor -- overall chain status, event breakdown by type and severity
Verification reports = integrity proofs -- block-by-block results that auditors can read without running code
Incident narratives = AI forensics -- when tampering is detected, Claude writes the investigation report directly into Notion

Claude Code drives the entire pipeline: key generation, event signing, block sealing, chain verification, Notion database creation, data population, dashboard generation, tamper simulation, and incident narrative writing. It is not calling a single API endpoint. It is orchestrating cryptographic operations and reasoning about what the results mean.

Technical Stack

Layer	Technology
Crypto	SHA-256 double hash, Ed25519 (PyNaCl), Merkle trees
Chain	In-memory append-only ledger with full verification
Anchor	Solana-style checkpoint signing (local simulation -- not live)
Interface	Notion databases + pages via MCP
Orchestration	Claude Code
Tests	65 tests across 6 files

Why This Matters

SaintChain is not a hackathon toy. It is a piece of something I have been building for over a year.

I am building Zero Day Security (ZDS) -- a full security operations platform for small and mid-size organizations. Government contractors, healthcare providers, critical infrastructure operators -- they need real security tooling but cannot afford the enterprise stack. They are stuck choosing between "too expensive" and "nothing."

ZDS is 130,000 lines of Go. Vulnerability scanning, EDR integration (Wazuh, CrowdStrike, SentinelOne, Defender), attack path analysis, incident management, workflow automation, OSCAL compliance exports for NIST 800-171 and CMMC Level 2, threat intelligence feeds, external attack surface monitoring, identity threat detection. 62 packages, 1,163 tests. One engineer.

SaintChain is the audit backbone of that platform. Every scan result, every incident, every compliance check that flows through ZDS needs a tamper-proof record. When you submit a NIST 800-171 assessment, an auditor needs to know your logs have not been modified after the fact. That is what SaintChain does -- cryptographic proof that the record is intact.

The Notion MCP integration adds something ZDS does not have on its own: a universal interface anyone can read. The ZDS dashboard is built for security engineers. But compliance officers, executives, auditors, and clients need to see the audit trail too -- and they already use Notion. SaintChain via MCP puts integrity proofs where non-technical stakeholders can browse them without VPN access or training on a new tool.

And when something goes wrong -- when a record gets tampered with -- Claude does not just log a hash mismatch to stderr. It writes a forensic incident narrative in plain English, directly into Notion, explaining what changed, what it means, and what to do about it. That is the difference between a security alert nobody reads and an actionable response.

Every compliance framework requires this. NIST 800-171, SOC 2, CMMC, HIPAA, FedRAMP. Tamper-evident logging is not optional. SaintChain makes it real. Notion MCP makes it accessible.

Team

Solo build.

I'm Saint Zero Day -- GWOT veteran and security engineer, building Zero Day Security.

DEV: @saintzeroday
GitHub: saintzeroday/saintchain-notion

The cryptographic engine is ported from my Saint Blockchain Rust codebase. The Notion integration, orchestrator, dashboard, verification reports, and incident narratives are new for this challenge. The security domain knowledge -- the event types, the compliance frameworks, the incident response workflow -- comes from building ZDS and two decades of doing this for real.