Cutsign

A personal, defensive threat-intelligence pipeline. Each weekday Cutsign ingests a public daily cyber-threat brief (an emailed digest of published security news and vendor advisories), reads the public sources behind each story, and produces a structured record for defenders:

• the adversary behaviors described, mapped to MITRE ATT&CK — the point of the whole system;
• the evidence the sources print (command lines, log lines, HTTP requests, file paths), byte-exact;
• the detection guidance vendors and researchers have published;
• the atomic indicators the sources state — last and least;
• an exposure check: affected and fixed versions, preconditions, quick exclusions.

It emails a morning brief, publishes the same material as a small site (analyst, CISO, agent-JSON, IoC-corpus and search views), keeps a watch on ongoing stories so material developments — new advisories, KEV listings, vendor fixes, confirmed exploitation — surface the same day (one development, one line: a write-up that only reports a KEV listing the catalog probe caught in the same tick folds into that event and lends it its link), and for the stories that matter most carries hand-written one-page verdict cards (patch / hunt / prepare, with detection coverage per vendor and tool-neutral inferred detections).

Named for the tracker's "cutting for sign": reading the sign an adversary can't avoid leaving.

Live: https://cutsign.vercel.app · License: Apache-2.0 · Built by Marcus Liberto.

What it is not

Cutsign is blue-team only. It extracts what adversaries did and how defenders detect it. It does not write exploits, payloads or attack tooling; it does not scan, probe or touch any system other than reading public web pages; and nothing it produces is executed anywhere — detection logic is published as text for a human to review and run. The material is intrinsically about attacks (CVEs, in-the-wild exploitation, malware, command-and-control infrastructure, verbatim attacker artifacts) because that is what detection engineering is made of; all of it comes from public reporting.

The one rule: zero employer data

This system never receives, stores or references anything from the author's employer — no internal hostnames, index names, sourcetypes, usernames, ticket numbers or results. Inputs are public OSINT only (the brief and public URLs); outputs are generic. There is no table column that could hold an internal value, and there must never be one. Every email says so in its banner. test/hygiene.test.js fails the build on anything shaped like an internal identifier.

How it runs

brief email ─ Resend inbound ─┐
Vercel crons (UTC) ───────────┴─ /api/cron ─ intake ─ driveRuns ─ stages… ─ email + site + Discord ✔/✖
daily 14:30–23:30, ten ticks ───  /api/watch  (story watches: page diffs, KEV, feeds, NVD, GitHub; batch answers; card coverage)
daily 13:45 ─────────────────────  /api/selfcheck (validates the public contracts the site and cards depend on)

Inbound. The brief is forwarded to a Resend receiving address. The Message-ID is checked before the body is downloaded (re-delivery is a no-op); messages must carry a DKIM pass and a sender on BRIEF_SENDER_ALLOWLIST, or they are stored as rejected with no body and a Discord warning.

Stages. runs.stage is always the last stage that completed; any error marks the run failed and the next tick retries from that stage (3 attempts), resuming what was persisted.

from → to	what happens
received → parsed	MIME → clean text; the brief split into one story per item
parsed → fetched	each story's sources, with timeouts, size caps, redirect limits, robots.txt, a 7-day cache, and a prompt-injection screen that excludes suspicious pages from extraction
fetched → extracted	a light read of every story, scored on what it found; the top stories get a deep read with more sources. Structured output validated by zod; ATT&CK IDs checked against a local mirror. Titles and summaries claim outcomes only as strongly as the sources confirm
extracted → normalized	IoCs refanged and canonicalized, placeholders and private ranges dropped, upserted on (type, value); stories matched to the trailing 14 days and linked as updates; two items in one brief on one campaign (shared CVE, specific malware, or actor plus an IoC) are linked the later to the earlier and take the group's strongest priority, since the model rated each alone — the views say "continues an earlier item in today's brief", the card thread carries both, and the sweep scores the pair once
normalized → … → sent	email, site, Discord. The validated / queried stages are seams for the detection-validation companion (see below)

This is the beginning of the README. Read the rest at the original. Read the full README ↗