Building a Cybersecurity News Pipeline I’ll Actually Use

Keeping up with cybersecurity news sounds simple until you actually try to do it consistently. There is no shortage of information. The problem is the opposite: too many feeds, too many tabs and too much repetition. I wanted a way to keep up without spending part of every day manually sorting through the same stories from different sources.

That became the first working module in Project Daedalus, my self-hosted automation and intelligence platform. The goal was straightforward: collect cybersecurity stories from sources I trust, clean them up, remove duplicates, decide which ones are worth my attention and send me a short daily report.

The easy version wasn't good enough

I could have made an n8n workflow that pulled a few RSS feeds and emailed every result. Technically, that would have worked. It also would have moved the problem from my browser into my inbox.

I wanted the automation to reduce noise rather than relocate it. The finished first version ingests eight RSS/API sources, normalizes the records into a common structure, filters them, removes duplicates across both the current run and previous executions, applies deterministic priority scoring and selects the ten stories that make the final briefing.

I deliberately kept the ranking deterministic. AI can be useful in an automation platform, but I don't want to add it just because I can. For this workflow, predictable rules are easier to test, easier to explain and less likely to turn a simple free system into something dependent on a paid API.

Self-hosting n8n was part of the project

The workflow itself is only half the story. Before trusting n8n with scheduled automation, I wanted the platform underneath it to have a proper baseline.

The Daedalus foundation is self-hosted with persistent storage, HTTPS through a reverse proxy, restricted network access, protected encryption-key handling and automated integrity-checked backups. I also documented the baseline rather than treating “the container is running” as the finish line.

That probably sounds like overkill for an email about security news, but that is exactly why I wanted to do it. I am using these projects to practise building systems I can explain and recover, not just demos that survive long enough for a screenshot.

The report needed to be something I would read

The final output is a formatted HTML briefing containing the Top 10 stories rather than a dump of raw feed entries. It is delivered through Gmail SMTP on a schedule, and failures are sent through a separate alert workflow so a broken daily job does not quietly disappear.

That separation matters to me. A scheduled workflow that fails silently is not really automated; it has just found a new way to require manual checking.

The result is intentionally small. I don't need Daedalus to become another news website. I need it to do the boring collection and filtering work so I can spend my time reading the few things that are actually worth reading.

Publishing automation without publishing my environment

I wanted this project to be useful portfolio evidence, which created another problem: workflow exports can contain things that should never be sitting in a public repository.

Before publishing the workflow, I reviewed and sanitized the export for credentials, tokens, internal addresses, personal information and other environment-specific values. The public version is inactive by default and is accompanied by implementation documentation. The point is to show how the system works without giving away the private details of the system running it.

That process has become a useful rule for the rest of Daedalus: build the working system first, then decide what evidence can be shared safely.

What I learned from the first module

The biggest lesson was that automation is not the same thing as connecting two services together. The useful work was deciding what counted as a duplicate, how to rank stories consistently, what should happen when something fails and how I would know the next morning that the workflow had actually done its job.

It also changed how I am thinking about Daedalus as a whole. I originally started with n8n because I wanted an easy way to automate a few things. Now I am treating it as an orchestration layer: specialist systems keep doing the jobs they are good at, while Daedalus handles the workflows around them.

The cybersecurity intelligence pipeline is complete and running. I later applied the same rule to Daedalus's certification lifecycle manager: if the automation does not make something genuinely easier or more reliable, there is no reason to build it.

Explore Project Daedalus on GitHub ↗