Hey everyone! 👋 I've been diving into Recorded Future for the past couple of weeks, mostly for threat intelligence monitoring at my new company. It's been really cool to see all the data, but I'm hitting a specific wall and could use some advice.
Our main goal is to get a clear, filtered view of vulnerabilities that actually matter to our tech stack. Right now, my feed is overflowing with CVEs—thousands of them—and it's impossible to manually sift through. We're a SaaS shop using a pretty standard set of libraries (like React, specific versions of .NET Core, and a handful of Python packages). I know Recorded Future has all this detail, but I feel like I'm missing a step.
How are you all handling this? Is there a way to set up a persistent filter or alert that only surfaces CVEs mentioning specific software components we use? I've poked around the rules and alerts section, but setting it up feels a bit overwhelming. Do I need to create a custom "watchlist" of our technologies first, or is there a smarter query syntax I should be using?
Any pointers on your workflow would be super helpful! I just want to make sure our dev team isn't bombarded with noise and can focus on the real, actionable stuff.
You're right that the naive approach of just filtering by product name in Recorded Future won't scale well. Your stack is a composition of many transitive dependencies - React alone pulls in dozens of packages, and .NET Core has a massive surface area at the runtime level. Relying on manual watchlists for each component will miss the vulnerabilities that don't mention the top-level package name but affect a nested library you're actually shipping.
What I've found more effective is to decouple the "what's in our stack" problem from the "what CVEs exist" problem. Use a software bill of materials (SBOM) generator like Syft or Trivy to produce a machine-readable inventory of your exact dependencies, including versions. Then pipe that into a vulnerability matching tool - Grype, for instance, can cross-reference your SBOM against the NVD and OSV databases directly. That gives you a precise, version-scoped list of CVEs without any manual filtering.
If you're set on staying within Recorded Future, you can still use their API to pull CVE data into a custom pipeline. Write a small script (Python or Go) that reads your SBOM, queries the Recorded Future API for each CPE or software identifier, and merges the results. That way you keep the enrichment from RF's threat intelligence but automate the filtering. The alerting side can then be triggered by a delta between your SBOM scan and the matched CVEs.
One caveat: SBOMs are only as good as your build reproducibility. If you're using lockfiles (package-lock.json, packages.lock.json for .NET, etc.) you're fine. If not, get that sorted first. Otherwise you'll be chasing phantom CVEs for packages you don't actually use.
You're absolutely correct about the SBOM approach being the proper way to filter signal from noise. However, your final point about custom scripts highlights the operational burden. Running a separate pipeline for vulnerability matching means you're now managing another system, and your findings are siloed from your core monitoring and incident workflow.
The better integrated approach is to generate the SBOM and feed it directly into a platform that can correlate it with your runtime data. Datadog SCA, for instance, will ingest that SBOM, match CVEs, but then also tie those vulnerabilities to the specific services and pods running the affected version. You get the precision without building and maintaining glue code.
null
That's the ideal, but Datadog SCA's pricing scales with hosts. If you're running a large container fleet, the cost can become a major line item, easily surpassing Recorded Future itself.
The glue code you're avoiding is a one-time engineering cost. The platform subscription is a permanent, often opaque, operational expense. You need to calculate which one actually has the lower total cost over 2-3 years for your scale.
Show me the bill