↓Skip to main content

My Pipeline: From Raw CVE Data to a Friday Brief

·3 mins
Table of Contents

The big picture #

In the last post, I explained what an AI agent is. Now it is time to show the design of CVE Friday Brief: how raw CVE data becomes a short, useful report every Friday.

The system has two very different parts:

  1. A daily part that collects data. It runs every day, in the background.
  2. A Friday part that generates the brief. It runs once a week.

Here is the important design decision: the daily part uses no AI at all. The Friday part is where the agents work.

C4 container diagram of CVE Friday Brief: daily collectors feed PostgreSQL, and the agent pipeline generates the Friday PDF

Part 1: The daily collectors (plain code) #

Every day, the system downloads fresh data from four public sources:

  • NIST NVD - new and updated CVEs
  • CISA KEV - vulnerabilities that attackers are already using
  • EPSS - a daily probability score: how likely is an exploit?
  • GitHub Security Advisories - advisories for open-source packages

The collectors store all of this in one PostgreSQL database. This database is the single source of truth for everything that happens later.

This job needs no AI. It is simple and repeatable: call an API, parse the response, save it. The steps never change. When you can define the steps yourself, you don’t need an agent - that was the point in the last post. Plain Go code is faster, cheaper, and easier to test.

Part 2: The Friday agents #

On Friday, four agents take over. They work on the week’s data, one after another, like a small editorial team:

  1. The Selector reads the week’s CVEs from PostgreSQL and picks the few that really matter, not the loudest ones.
  2. The Enricher takes each selected CVE and adds context: vendor advisories, affected products, links, and a short plain-language explanation.
  3. The Detection Writer writes a Sigma or KQL rule for each CVE - when detection from logs is possible. When it is not, it says so, and recommends patching or a version scan instead.
  4. The Editor puts everything together into one clean, consistent brief, and the system renders it as a PDF.

Each agent has one job. Each agent reads from and writes to the same PostgreSQL database. The order is fixed - but inside each step, the agent decides how to do its work.

A hybrid, not a “fully autonomous” system #

The overall pipeline itself is a workflow: I fixed the order of the steps. The agents only have freedom inside their own step.

This is by design. A fixed spine makes the system predictable and easy to debug. The agents add intelligence exactly where fixed rules are not enough: judging importance, explaining context, writing detection logic.

In my experience, this hybrid shape is where most real systems end up. Full autonomy sounds exciting, but a Friday report must arrive every Friday - boring reliability wins.

The stack #

  • Go - collectors, pipeline, and PDF rendering
  • Google Agent Development Kit (ADK) - the agent layer
  • PostgreSQL - one database for raw data, enriched data, and finished briefs

Thanks for reading. The next post is coming soon - subscribe via RSS if you want to follow the build.