Projects · personal project · October 2026 to date
How I built Industrial Cyber Brief
A daily OT/ICS threat briefing that reads the news so plant managers, OT engineers and security teams do not have to. AI does the reading and the first draft; published rules decide what goes out; the editor stays in charge.
Today's issue · Archive · Methodology · Executive report
- 30public sources read every morning
- 10:00 ISTdaily, plus a weekly edition on Mondays
- ~5 minunattended run, a few cents of AI per issue
- 0servers: scheduled jobs and a static site
The problem
Industrial security news is scattered across government CERTs, vendor advisories, trade press and threat research. Most of it is written for IT. The people who run plants need three things from it: does this touch my site, how bad is it, and what do I do this week if I cannot patch. I was reading dozens of sources before my first meeting each day to answer those questions for myself. The Brief does it once, in public, for everyone.
What I built
Two pieces. A pipeline that wakes up at 10:00 IST, reads the sources, decides what matters and sends the email. And a website that shows the same issue, keeps the archive and gives each story a page that can be shared. Every story carries three facts stated by the source, then a clearly labelled editor's reading: the Purdue level and why, who should act, how to check exposure, what to do if you cannot fix it yet, what to watch for, and the MITRE ATT&CK for ICS techniques involved.
How a morning runs
- Collect. 30 public feeds, plus CISA's list of vulnerabilities known to be exploited.
- Dedupe. Anything seen on an earlier day is dropped.
- Enrich. CVE ids pulled out, matched against the exploited list; CVSS kept only when the source states it.
- Triage, with a small fast model. Is it relevant to industrial sites, how severe, which vendors and sectors, what kind of action.
- Select, by rule. Severity floor, exploited first, official advisories before commentary, top ten.
- Write, with a stronger model. The three facts and the editor's reading, in structured fields, checked against fixed vocabularies.
- Render and send. HTML and plain-text email, with a fallback mail route if the newsletter service fails.
- Remember and publish. State and archive saved as a commit; the website update opens, passes its checks, merges and deploys itself.
Design decisions
Facts and inference kept apart
The model may only restate what the source says in the three facts. Anything it infers sits in a separate, labelled block. Scores are quoted, never estimated.
Rules in code, not in the prompt
What gets selected is decided by published rules in ordinary code. The model rates; it does not choose.
No server, no database
The pipeline runs once a day and saves its memory to git. Nothing to patch, nothing listening, full history and rollback for free.
Fail closed
If the AI provider fails, nothing is sent. If the website fails a check, the email still goes and the site keeps yesterday's issue.
Every change is gated
100+ automated tests, accessibility checks, a strict content security policy and secret scanning run before anything reaches readers.
Small models where they suffice
Triage uses the cheapest model on every item; the stronger model only writes the ten that made the cut.
Stack
PythonAnthropic Claude (Haiku, Sonnet)Structured outputsJinja email templatesScheduled CICloudflare PagesStatic HTML, CSS, JavaScriptpytest, Playwright, axeButtondown
The rules it keeps
- Personal, in my own time. Not connected to, reviewed by or speaking for any employer, and nothing learned inside one is used.
- Free, and not for sale. No advertising, no sponsorship, nothing sold.
- Facts and judgement, kept apart. The source is named; scores are quoted, never guessed; what the AI infers is labelled as inferred.
- A human in charge. AI does the reading and the first draft; I decide what goes out.
- Open about the method. The rules, the sources and the corrections are published.
What I learned, and what is next
- The hard part was never the AI. It was deciding what a plant manager needs to see first, and keeping the model from sounding sure about things the source never said.
- Email clients are the strictest renderer there is. The same story card had to work in Outlook, Gmail and a phone, and in plain text.
- As a publication it scales to thousands of readers. Matching advisories to one organisation's own asset inventory would need a different back end: sign-in, private delivery and data isolation.