小型企業不看 CVE，所以我打造了 AlertCadence 安全通報翻譯工具

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

AlertCadence — a tool that turns raw security advisories into plain-English briefs a small business can actually read.

Security advisories are written for engineers. A small-business owner doesn't read "path traversal via crafted request" — they skim it and move on. Managed IT providers (MSPs) feel this constantly: they need to tell clients, "here's what to patch and why it matters," but translating CVEs into calm, clear language by hand eats their Monday mornings.

AlertCadence does the translation. It pulls CISA's feed of actively exploited vulnerabilities, keeps the ones affecting software small businesses actually run, and rewrites each into three plain sentences: what happened, why it matters to your business, and what we're doing about it — generated by a model running entirely on the user's own machine.

The person who'd pay for it: an MSP who wants to send clients a credible weekly security brief without writing it from scratch and without sending client data to a cloud AI.

Demo

🔗 Live: alertcadence.tech

The landing page explains the tool; "See this week's brief →" opens a real brief generated from live CISA data by a local model — six current advisories (Fortinet, Apple, SharePoint, WordPress, Magento, Google Pixel), each translated into plain English, with ransomware-linked ones listed first.

Code

Tash925 / alertcadence

Plain-English security briefs for small businesses, generated by a local open model. Hacktoberfest 2026.

AlertCadence

Plain-English security briefs for small businesses — generated by a local open model.

Built for the Hacktoberfest 2026 Open-Source AI Challenge, Week 2: Side Hustle A project by DataSec Chronicles.

Live site: alertcadence.tech

A real brief, generated from live CISA data by a local model — each advisory in plain English, ransomware-linked ones first.

What it does

Security advisories are written for engineers. A small-business owner doesn't read "path traversal via crafted request" — they skim it and move on.

AlertCadence translates. It pulls CISA's feed of actively-exploited vulnerabilities, keeps the ones affecting software small businesses actually run, and rewrites each into three plain sentences:

• What happened — the issue, in plain English
• Why it matters to your business — the practical risk
• What we're doing — reassuring, proactive language an MSP would use

The result is one clean HTML brief an MSP can review and send…

A Python pipeline: fetch → extract → summarize → store → render. The README walks through each step.

How I Built It

Local open-weight model — Google Gemma (gemma2:2b) via Ollama.

The whole pipeline runs on my own machine. But the interesting part was how I used the model — and what I decided not to let it do.

A 2B model is small. Feed it a raw advisory, and it leaks exploit syntax into the "plain English," drifts into Markdown, and — worst of all for security — invents details when the source is vague. Tightening the prompt helped a little. It wasn't enough.

What worked was giving the model a smaller job. A deterministic Python step extracts a small fixed set of facts first — vendor, product, type of flaw, ransomware flag — and the model only ever receives those. It can't leak exploit syntax it never sees. It can't misjudge relevance it never evaluates. The guardrail is the architecture, not the prompt.

When an advisory's details are genuinely thin, the model is told to say so plainly rather than guess. I tested that deliberately — fed it a vulnerability with almost no public detail — and instead of inventing a mechanism, it said: "the specifics aren't public yet." For anything going out under an MSP's name, that honesty is the whole ballgame.

Storage — MongoDB Atlas, keeping a durable history of every brief generated, with a local JSON fallback so the pipeline never breaks if the database is unreachable.

Data — CISA Known Exploited Vulnerabilities, where everything is confirmed exploited, so risk is pre-filtered at the source.

Why Does Open Innovation Matter?

Three reasons, and they're the reason the project works at all:

• Privacy. This is a tool an MSP would run against their client list. A cloud API would mean sending that to someone else's servers. A local open model means the data never leaves the machine — which, for a security tool, isn't a nice-to-have; it's the whole reason it can be trusted.
• Cost. Open-weight + local = $0 per brief. No per-token bill, so an MSP keeps full margin on comms they should be sending anyway.
• Control. I could constrain a small open model exactly how I needed — feed it only pre-extracted facts, force it to admit uncertainty. That tight control over the model's inputs is what made it safe for security content. A closed API gives you less of that.

The open pieces aren't decoration. They're what make the tool trustworthy enough to exist.

My First User

No paying users yet — but I built this in public, and the response from the people closest to the problem has been the real early signal.

A few reactions stood out as I shared the approach: that a local model turning CVE text into plain English is exactly the translation layer small businesses without a security team need, and that filtering for relevant software before the model runs is the right order — the model should only ever see what survived the logic, not the raw feed.

The most useful exchange came from someone who runs a chatbot on a testing lab's site. They zeroed in on the part where the model admits when a detail isn't public, because in their world a made-up answer is worse than no answer at all. They suggested saving those "detail not available" cases as a regression test — so if a future model update quietly starts filling in the blanks, it fails loudly instead of slipping through. That's my next build.

That's exactly why I build in public: someone who'd been burned by hallucination handed me my next feature. The step after that is a round of feedback from actual small-business owners to check how clearly the briefs land for the people they're written for.

Prize Categories

• Best Use of Gemma — Gemma (open-weight, via Ollama) is the engine; the whole project is built around constraining a small local model to produce safe, calm, non-technical security writing.
• Best Use of MongoDB Atlas — stores every brief's advisories and summaries, with a graceful local fallback.
• Best .tech Domain — live at alertcadence.tech.

Built with 💜 by DataSec Chronicles. The tool changes, the question doesn't.