Skip to content
Back to Projects

Security News Agent

Autonomous intelligence pipeline that monitors security news RSS feeds, classifies vulnerabilities with AI, cross-references organizational SBOM data, and delivers real-time Slack alerts when packages are affected.

N8N POSTGRES AI_AGENT SLACK
Security News Agent architecture diagram
Click to expand

Overview

An autonomous pipeline built on n8n that continuously monitors security news and determines whether published vulnerabilities affect the organization. When a new article is detected, the system fetches it, runs it through an AI agent, and extracts structured data about affected packages and version ranges.

The extracted packages are immediately cross-referenced against a live SBOM database that tracks every package running in the organization, down to the exact version. If any organizational software falls within the affected version range, the system fires an alert to the SecOps team’s Slack channel within minutes of the article being published.

The pipeline is supported by a separate SBOM collection workflow that continuously syncs package inventories from security scanning vendors, keeping the database current so the matching step always has accurate data to work against.

Architecture

News Monitoring Pipeline

The agent subscribes to RSS feeds from major security news sources (TheHackerNews, BleepingComputer, and others). Each new article triggers the pipeline. The scraper fetches the full article URL and strips it down to clean, structured text, removing navigation, ads, and other irrelevant content before passing it downstream.

Intelligence Processing

The cleaned article text is passed to an AI agent with two responsibilities: relevance classification and data extraction. First, the agent determines whether the article describes an actual vulnerability or active exploit. Articles about webinars, executive news, opinion pieces, and security recaps are filtered out. Only confirmed vulnerabilities and exploits in the wild proceed.

If the article is relevant, the agent extracts the affected package or product name and any version information present. A dedicated code node then normalizes the extracted version data into proper semver format. For example, if the article states “versions 2.0 through 2.4 are affected,” the code node converts this into a semver range that can be evaluated against the SBOM database.

SBOM Cross-Reference

The normalized package name and version range are used to query the Postgres database. The matcher looks for any organizational packages with a matching name, then checks whether the installed version falls within the vulnerable range. A single article may match multiple packages across different teams or environments.

SBOM Collection

A separate n8n workflow runs on a schedule to keep the SBOM database current. It connects to security scanning vendor APIs, paginates through full package inventories, and normalizes the data into a consistent schema. A database sub-workflow handles the read and upsert operations, ensuring no duplicates and no stale records.

Alert Delivery

When the matcher finds one or more affected packages, a Slack alert is built and delivered to the SecOps channel. The message layout is generated dynamically by a code node that adapts the Block Kit structure based on how many results were found. A single match produces a focused card. Multiple matches across vendors each get their own section with a direct deep link into the vendor’s UI with the package name pre-filtered, so the engineer lands exactly where they need to be.

Workflow Example

  1. The RSS monitor detects a new article: a critical remote code execution vulnerability in a widely used logging library
  2. The scraper fetches the full article and reduces it to clean text
  3. The AI agent classifies it as a relevant vulnerability (active exploit, not a recap) and extracts the package name and the affected version range
  4. The semver converter parses the version range from the article’s natural language into a structured semver expression
  5. The SBOM matcher queries the Postgres database and finds the organization has three services running a version that falls within the affected range
  6. The system builds a dynamic Slack alert with the vulnerability summary, the three affected packages listed with their versions, and direct links into each vendor’s interface for each result
  7. The SecOps team receives the alert within minutes of the article going live, with all the context needed to begin triage and remediation