I had 10 security feeds and still missed a critical vulnerability in production
Staying on top of security is part of the job as a developer. And with AI accelerating both attacks and discovery, the volume of CVEs and breaches is only going up. But for years, my approach was a mess:
- newsletters
- RSS feeds
- Slack / Discord messages
- the occasional GitHub email: "A security advisory… affects one of your repositories"
- Snyk, Trivy, CI scanners
- Dependabot PRs piling up
Individually useful.
Together? Just noise.
I'd see an alert → not sure if it affects me → close tab.
Full YOLO mode.
Then one day it caught up with me.
A critical vulnerability in a library I was using had been public for days. I completely missed it.
I only found out through a chain of Slack → Reddit → advisory.
By then, the vulnerable version was already running in production.
I patched it. Got lucky.
But that wasn't the scary part.
That same week I also missed:
- a supply chain attack on a npm package I could've used
- a critical framework vulnerability I was evaluating
All of it was "out there".
I just didn't see it...
That was the moment it clicked:
The problem isn't access to information.
The problem is having to read everything just to figure out if anything matters.
So I tried to fix it
I buil a small prototype in a weekend that pulled in security signals and tried to filter out the noise.
I posted it on Hacker News.
And then things got interesting:
- people actually signed up
- I got brutally honest feedback
- someone sent me UX improvements
- someone else did a full onboarding teardown
- and at some point an actual hacker ran a security scan on my site and sent me the results
I didn't ask for any of this.
That's when I knew I was onto something.
But the feedback also made one thing clear:
I didn't need more data.
I needed less, but better.
What I actually wanted was simple:
- what happened
- does it affect me (based on what I actually use)
- what should I do
That's it.
So I rebuilt everything around that idea
That became BreachEcho.
Now it turns signals from sources like HN, BleepingComputer, GitHub advisories, Dark Reading, SecurityWeek, CISA… into short, structured alerts - filtered to things I actually care about:
Critical vuln in X → affects Y → patch to Z
No dashboards. No digging. No long writeups.
Just something you can read in a few seconds and decide if you need to act.
I'm still tuning the signal vs noise balance (harder than it sounds).
But it already feels a lot better than my previous system:
close tab and pray.
How do you currently handle security alerts?
Do you actually read them… or also just close the tab and hope?
You did not have a security feed problem.
You had a triage problem.
That is the real wedge here.
Most teams already have too many alerts.
They do not need another source.
They need something that collapses “should I care?” into a decision fast enough to act on.
That is the right framing.
The stronger version of this is probably not “security news.”
It is “production relevance.”
Not what happened.
What changed for me.
That is the layer people actually pay to outsource.
Also: BreachEcho is decent, but still slightly “security newsletter.”
If this keeps moving toward infra-critical decisioning instead of alert aggregation, Davoq.com would age better.
This is a really good way to put it.
“ should I care into a fast decision layer” is basically the core of what I was trying to get to , but I see now I just didn’t phrase it that cleanly.
I also felt that shift while building:
it started as “collect signals” and quickly became “what actually changed for me”
still figuring out how far to push that, because the line between an “alert” and “decision” is where it gets interesting (and tricky)
curious tho, how would you approach that layer? more context? tighter filtering? Or something else?
I’d approach it less as filtering and more as decision compression.
Filtering says:
here are fewer alerts
Decision compression says:
here is what changed, why it matters, and whether you need to act
That is a much stronger category.
The product should not feel like it is helping people read security news faster.
It should feel like it is removing the “should I care?” step from production security.
That also changes the naming bar.
If this becomes a decision layer, BreachEcho may start feeling too event/news-driven.
The name has to carry something more durable:
risk judgment
production relevance
fast operator confidence
That is why Davoq fits better to me.
It feels more like infra decisioning than another breach feed.
Decision compression. That is a great way to phrase it. That really clicks.
and yeah, its exactly the shift I’ve been feeling while building it. less “here are some alerts” and more “this changed for you, here’s what to do”
I think the tricky part is making it feel trustworthy enough that people actually rely on it for decisions, not just as input
on the naming .. I get your point. Right now it probably still leans a bit “event-driven”
but not 100% sure yet if the product has earned a more abstract / infra-style name like that, or if that comes later once it’s clearly operating at that layer
feels like there’s a sequencing question there
curious how you’d think about that?
If you’re wondering what an alert actually looks like, it’s basically this:
---
[CRITICAL] OpenSSH flaw → unauthenticated root access
Who: OpenSSH 8.5p1–9.8p1 on Linux (~14M exposed servers)
Action: Upgrade to 9.8p1+ or temporarily set LoginGraceTime 0
---
That’s the whole idea -> compress everything into something you can read in ~5 seconds and act on.
Happy to share more if useful.