Summary
Radar started as a joke about needing a hobby outside cloud infrastructure. It ended up becoming a small personal side project that pulls in selected security advisories and makes them easier to read, filter and think about.
People sometimes ask whether I have any hobbies outside building cloud infrastructure.
Fair question.
The honest answer is that the boundary between work and hobby has never been particularly strict. If you spend enough time around systems, architecture, infrastructure and security, the line has a habit of disappearing. At some point, however, I realized that “reading advisories for fun” is probably not what most people mean when they ask whether you have hobbies.
So I did what any reasonable person would do.
I decided to get a hobby.
Predictably, it also ended up involving code.
That became Radar: a small personal side project where I pull in selected advisories from CISA and Zero Day Initiative, with more feeds likely to come later, and try to make them a bit more readable, structured and easier to digest.
Not a threat intel service. Not exhaustive. Not a replacement for primary sources. Just a small place for the things that make me stop, read twice, and think.
Why I built it
One thing I have noticed over time is that many advisories are technically important, but not always very readable in practice. They are often written for accuracy first, which makes perfect sense, but that also means they can be difficult to scan quickly if you are trying to understand why something matters, how broadly relevant it is, or whether it has any practical implications outside a narrow technical context.
That is the gap Radar is meant to sit in.
Not by replacing the original advisory, but by sitting next to it.
The point is not to rewrite everything, or to pretend that every CVE deserves a grand narrative. The point is simply to take selected advisories, preserve the link back to the original source, and add just enough structure and context to make them faster to understand.
Sometimes that means highlighting a detail that could easily be missed. Sometimes it means pointing out patterns across products or vendors. Sometimes it just means turning a wall of advisory text into something more human-readable.
What Radar actually is
Radar is a personal, editorial side project.
It currently pulls in selected advisories from sources such as CISA and Zero Day Initiative, and I use WAYSCloud LLM to help make them more readable, structured and easier to digest. The goal is not to generate “AI threat intelligence”, but to make raw advisories less cumbersome to work through.
That distinction matters.
Radar is not trying to compete with security vendors, dedicated threat intelligence teams or formal advisory databases. It is closer to a technical reading notebook: a place where selected items are pulled in, cleaned up, given a bit of structure, and presented in a way that is easier to scan.
That is also why I am deliberately keeping the framing modest. It is not comprehensive. It is not authoritative in the way a vendor advisory is authoritative. It is not a real-time alerting platform. It is simply a small project that reflects how I already read and think about these things.
Why this is interesting to me
Part of the reason I enjoy this is that advisories are often more interesting than they first appear.
A single vulnerability note can say something about software quality, patch culture, vendor maturity, attack surface, operational dependency or how infrastructure is actually put together. Sometimes the interesting part is the CVE itself. Sometimes it is the age of a bug. Sometimes it is the product class. Sometimes it is the fact that the same pattern keeps showing up again and again in slightly different forms.
Radar gives me a place to collect those observations without pretending every item is world-changing.
It also fits quite naturally with the way I already think about infrastructure: not just as isolated technical issues, but as systems, dependencies and operational realities.
That is why the project is intentionally selective. I am less interested in publishing everything than in surfacing the entries that are actually worth pausing on.
Why not just read the original advisories?
You should read the originals.
That is why the primary source remains central in Radar.
But in practice, many people do not need another feed of raw advisories. They need faster orientation. They need something that answers simple questions quickly:
What is this? Why does it matter? What kind of system is affected? Is there something unusual here? Is this noise, or is it worth paying attention to?
Radar is my attempt at making that first pass easier.
Not simpler in the sense of dumbing it down, but simpler in the sense of reducing friction.
A small project on purpose
One reason I like side projects is that they are allowed to be small.
Radar does not need to become a company, a product category, or a giant platform. It can just be useful. It can be a compact place for selected advisories, short notes and a bit of structure. That is enough.
In some ways, that is also what makes it enjoyable. There is no need to pretend it is more than it is. It is a hobby project, even if it happens to look suspiciously similar to the kind of thing someone would build when infrastructure, security and code already take up a noticeable part of life.
Which, to be fair, they do.
Closing
So yes, I suppose I now have a hobby.
It just happens to involve advisories, CVEs, a little classification, and more code than most people probably had in mind when they recommended getting one.
That hobby became Radar.
You can find it here: Radar