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?
10 feeds is exactly the failure mode. Each feed individually filters for 'might be relevant' which means none of them are tuned to the actual deployed version, the actual risk surface, or the actual customer impact. I had 7 a year ago and missed two by exactly the same dynamic. Cut to 2 sources after that, both gated on the libraries actually in our SBOM. Coverage went down on paper, real coverage went up. The lesson I keep relearning: more inputs is the wrong axis. The right axis is whether the inputs you have are filtered by deployment reality.
“Coverage going down on paper and real coverage going up” <- this framing really clicked for me.
I think that’s exactly the trap I fell into as well: optimizing for more visibility instead of actual operational awareness.
And yeah, the “deployment reality” part feels like a key layer.
I see it like this: a feed can tell me a vulnerability exists, but that still leaves a huge gap between: “this happened somewhere” -and- “this affects my running stack right now”
The more feedback I get on this, the more I realize the hard part isn’t aggregation at all.. it’s contextual relevance and trust.
And SBOM-gated sources are great for dependency/CVE relevance… but I keep running into the question of how far that model extends beyond the software graph itself... Because things like infra exposure, third-party vendors, cloud tooling, CI/CD compromises, OAuth integrations etc don’t always map cleanly to “is this package in my lockfile?”
Curious how you think about that side of the problem?
You named the actual edge. SBOM-gating works because the dependency graph has a clean ownership question - is this in my lockfile, yes or no. The moment you cross into OAuth scopes, CI/CD secrets, or third-party SaaS, that question doesn't even have a knowable answer from inside your repo. Last quarter I burned two days tracing which staging service was still trusting an OAuth scope we'd revoked three months earlier the answer wasn't in any manifest, it was in a half-forgotten Postman collection on a former contractor's laptop. The asymmetry that bites is blast-radius: a CVE in your lockfile is bounded and rollback-able, a compromised CI/CD runner or a supply-chain hit in a vendor you OAuth'd into is effectively unbounded until you do the audit by hand. Curious if you've found anything resembling a first-pass discovery layer for those non-package surfaces, or whether you've also accepted that piece is just operationally manual for now.
That Postman/OAuth example is exactly the kind of thing I mean.
With dependencies there's at least some kind of source of truth:
lockfile, SBOM, deployed version etc...
But with vendors / OAuth / CI/CD / forgotten staging services, the source of truth is often scattered across dashboards, configs, secrets, or just people’s memory.
That feels like the next hard layer:
not “is this package affected?” but “where are we operationally exposed, even if it’s not in the repo?”
And honestly, I dont think thatt part should stay operationally manual long term. To me, that’s exactly where the real gap is right now.
Right now I’m exploring whether lightweight discovery + better onboarding can already build enough operational context without requiring deep access or agents.
Curious what you would consider “good enough” there?
Because if BreachEcho could not only tell you about a security incident, but also surface operational risks (for example pointing out which forgotten OAuth scope or stale integration is still trusted in your environment) it feels much closer to the real problem than CVE aggregation ever will.
'Where are we operationally exposed even if it's not in the repo' is the framing I've been missing. Good-enough for me would be a pass enumerating every external trust the company depends on - active OAuth scopes, SaaS we auth'd to once, CI runners reading prod env - even without ranking risk. The naming forces the conversation; you can't audit what you can't enumerate. Lightweight onboarding beats deep agent access - agents inherit the same blindspots if the map isn't drawn first.
The "close tab and pray" line made me laugh because that's literally how I treat 80% of my alert surface too. Honest answer to your question: I skim, I tell myself I'll come back, I don't.
The part I keep turning over in your post is the "does it affect me" filter. That's the actual hard problem — not aggregation, not summarization. Anyone can pipe HN + CISA + GitHub advisories into a feed. The unlock is knowing my stack well enough to throw away 95% of it before I see it. I'm curious how you're handling that — pulling from package.json / lockfiles, or asking users to declare their stack? Because the gap between those two is huge in terms of trust.
I'm Shirley, building ZooClaw — we're turning expert playbooks into agents, and the same signal-vs-noise tension shows up everywhere. "Less but better" is the right north star, but it's brutal to tune. The week I thought I had it dialed in was always the week a user told me I'd filtered out the one thing that mattered.
Good luck with BreachEcho — the niche is real.
That tension you describe is exactly the part that keeps getting harder the deeper I go into this 😅
The moment you filter aggressively enough to feel useful, you also risk filtering out the one thing that mattered. (relevance)
Right now I’m somewhere in between:
partly user-declared stack/tags, partly trying to infer relevance from broader context/signals. I also experimented with automatic stack detection during onboarding just to reduce friction and improve the initial “does this affect me?” feeling.
But yeah, the trust gap between “user told me” and “I inferred this correctly” is HUGE.
And honestly, I think that trust layer is probably the actual product.. way more than the alerts themselves.
Really appreciate this comment. Thanks, Feels like you’ve run into a very similar problem with ZooClaw.
curious tho, how are you thinking about that tradeoff on your side?
more aggressive filtering/automation vs surfacing too much “just in case”
feels like every system trying to reduce noise eventually runs into the fear of hiding the one thing that mattered..
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?
That’s the right question.
I’d think about it this way:
If the product is still helping people consume alerts, keep the descriptive name.
If the product is already helping people decide what matters in production, the abstract infra-style name starts making sense sooner.
Because the name does not just follow the product.
It also tells users what level to evaluate it at.
BreachEcho makes people evaluate it like a security signal/feed.
Davoq makes them evaluate it more like an operator decision layer.
So the sequencing question is really:
are you trying to validate alerts,
or are you trying to validate trust in the decision layer?
If it’s the second, waiting too long can make the product feel smaller than what you’re actually building.
this framing actually helped clarify something for me
“validate alerts” vs “validate trust in the decision layer” are two different products.
I think right now I’m somewhere in between:
the product started as signal aggregation, but the real pull is clearly around reducing operator uncertainty fast enough to act.
and you’re right that this changes the evaluation layer entirely.
Still feel tho that trust is the part that has to be earned before the product can fully present itself at that higher abstraction level... but I can definitely see the direction more clearly now
Really appreciate the depth of your feedback here. Gave me a lot to think about.
That makes sense, but I’d be careful with waiting too long.
Trust is earned through the product, yes.
But the name decides what standard people use to judge the product in the first place.
If it looks like a feed, they judge it like a feed:
is this useful information?
If it looks like a decision layer, they judge it differently:
can this reduce uncertainty fast enough for me to act?
That second frame is much closer to what you’re actually building.
So I don’t think the question is whether the product has fully earned the abstraction yet.
It’s whether BreachEcho is already causing people to evaluate it one level too low.
That’s where Davoq makes sense.
Not as a cosmetic rename, but as a way to move the product into the category you’re actually validating.
Yeah, I can see your point !
Not really “descriptive vs abstract naming”.. but what level people instinctively evaluate the product at from their first impression.
And honestly, that probably is happening to some degree already.
At the same time, I think there’s still a trust/discoverability tradeoff early on, especially in security. A name like BreachEcho immediately tells people roughly what world they’re entering, while a more abstract infra-style name has to earn that context from scratch.
But think you’re right about the bigger direction:
the real value is probably much closer to “reducing operational uncertainty” than “helping people consume security information.” (there is enough of that)
One thing from this thread stayed with me.
BreachEcho is not just a naming question. It is a category decision.
If users evaluate it as a security feed, they ask: “is this useful information?”
If they evaluate it as a production decision layer, they ask: “can this reduce uncertainty fast enough for me to act?”
That difference will affect the landing page, trust proof, onboarding, alert language, and the name itself.
Since you were already thinking through that tradeoff, I can do a focused naming/positioning audit around BreachEcho: current name risk, category frame, security trust signal, decision-layer positioning, and whether the product should stay descriptive or move toward a more infrastructure-grade brand.
Not a long consulting thing. Just a sharp written breakdown you can use before more users, pages, and product memory build around the current frame.
I’m doing a few of these at $99 while refining the format.
If useful, connect here and I can give you a clear outside read:
https://www.linkedin.com/in/aryan-y-0163b0278/
Exactly — but that tradeoff is why I’d move earlier, not later.
BreachEcho gives instant category context, but it also traps the product inside “security information.”
That helps discovery, but it weakens the bigger value:
reducing operational uncertainty fast enough to act.
If the product is moving toward decision confidence, the name should help users evaluate it at that level from the start.
Davoq works because it does not sound like a newsletter, feed, or breach tracker.
It sounds like infrastructure.
That is the point.
You can still explain the category in the tagline:
production security decisions, compressed
But the brand itself should not keep pulling the product back into alert/news territory.
If you are serious about validating the decision-layer version, I would not wait too long to separate that from BreachEcho.
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.
So I started experimenting with a public Telegram channel that only posts CRITICAL alerts in the same compressed format.
Basically: what changed → who it affects → what to do
No account needed. No dashboards. No feeds to manage. Just high-signal incidents in real-time.
Also a small preview of what I’m building with BreachEcho :)
https://t.me/BreachEcho