Inspiration
Security scanners tell you a package has a flaw. They can't tell you whether it matters. That answer needs to know what the pipeline feeds, whether it's still running, and which columns hold personal data which is exactly what a data catalog already stores. Nobody was using DataHub for it.
What it does
BLASTRADIUS matches each pipeline's dependency list against public vulnerability feeds, then uses DataHub's lineage to decide which flaws are actually reachable. It dismisses the ones that aren't, writes an OpenVEX document proving why, and writes the results back into DataHub as searchable properties, tags, incidents and assertions.
The part nobody else does: it records the exact facts behind every dismissal and keeps watching them. When someone un-retires a job, it takes its own dismissal back and says what moved.
How I built it
Python, on a live DataHub no sandbox. SBOMs give the join key that CVE databases lack (package plus version), matched against OSV, CISA KEV and FIRST EPSS. DataHub is read over GraphQL and written via structured properties, tags, incidents and external assertions.
Deployed on Azure: DataHub on a VM behind Caddy for TLS, the demo page as an App Service running the same engine from a container image.
Challenges we ran into
Almost every real bug was invisible in tests. Column tags came back empty against a real DataHub, so the sensitivity signal the thing the whole product rests on silently contributed nothing while the output looked healthy. EPSS moved hosts and broke every live scan while offline tests passed.
The worst one was our own scoring: ranking on raw exploitation probability crushed every real finding into 0.1–3.6 out of 100, making our own alert threshold unreachable.
Accomplishments that we're proud of
The demo dismisses half its own findings. Two pipelines run the same old Python install, so they carry the identical 23 flaws one scores 55, the other 0.9, purely on what DataHub knows about them.
And it stays quiet: un-retiring a job withdraws 23 dismissals as one alert, not 23 pages.
What we learned
A passing test suite proves the cases you thought of. Eight of our worst defects passed all 259 tests and only appeared against a real catalog including an AI agent that wrote to the live catalog on every tool call, and a "read-only" tool that raised real incidents.
Also: the asset a security tool most needs to update is the one that was just fixed, and that's the one it's most likely to skip.
Log in or sign up for Devpost to join the conversation.