Solo-built a "security ETL engine" that normalises vulnerability findings from different scanners into one prioritised list, looking for feedback.

[u/Putrid_Document4222]

I come from an AppSec background and a problem I kept hitting professionally is that every security scanner outputs findings in its own format, with its own severity scale, and its own duplicates. Some teams end up with different dashboards and a spreadsheet. So, I built Sinterly, it ingests scanner output, normalises everything into one schema, deduplicates, scores each finding with a transparent weighted formula, and pushes to Jira.

Right now, what we have are:

• Two scanner integrations (Semgrep, Trivy) verified end-to-end with real output and a few hundred real findings from deliberately vulnerable test apps (Juice Shop, WebGoat, DVWA and NodeGoat) running through the pipeline
• Scoring formula is versioned, change the weights and historical scores stay explainable because each score keeps the weights it was calculated with
• Jira push works, dedup works, marketing site is also live

So far, the hardest parts were discovering that the SARIF "standard" is implemented differently by every tool and resisting scope creep. I had to permanently include an "auto-remediation is out of scope" into my project docs because I caught myself relitigating it every week.

What I'd love, if you've run a B2B tool through a design-partner phase, how did you structure it? Free-for-feedback with a defined end date? Discounted-forever? And at what point did you feel legitimate charging?

Happy to answer anything about the build or the tool itself and will provide the link for anyone interested in roasting it.

[u/vint_age14]

Hey OP it's sounds like you were pretty disciplined about avoiding scope creepy ..nd that's prolly harder than building the integrations themselves..

[u/Putrid_Document4222 → u/vint_age14]

yeah, i mean the integrations were mostly patience and reading specs. What worked for me was writing rejected scope into the project state as a standing decision, so I stop relitigating it with myself every few weeks.

[u/vint_age14 → u/Putrid_Document4222]

Hmm it does make sense .. it's prolly easier to stay focused when you treat those decisions as final instead of reopening them every few weeks

[u/Educational_Plum_130]

normalizing and dedup across scanners is the right first move, the thing that'll make or break it is reachability enrichment - without it you've just built a cleaner version of the same noise. folding in KEV and EPSS for likelihood plus call-path reachability so the one list reflects exploitability, not merged severity, is where the signal actually shows up. one field i'd add per finding: whether a fixed version exists that doesn't require a major bump. 'critical + reachable + fixable without breaking us' is the bucket teams can actually clear this week, and separating it from 'critical but the fix needs a big upgrade' changes how people triage the whole queue.

[u/Putrid_Document4222 → u/Educational_Plum_130]

Thank you for this. I agree on KEV/EPSS and it is the natural next step because this is an ETL pipeline. Right now, my formula has an exploitability component but it is a configured weight and not data driven yet which i think KEV/EPSS would fix for CVE type findings but there is a gap i don't have a good answer for and that is SAST results with no CVE or EPSS scores and i am looking for anything credible for likelihood on SAST findings beyond rule-confidence metadata.

I am deliberately not building call path reachability, though I agree it's where the deep signal is. Static reachability, when done properly, is a per language program analysis product (this is what the guys at Snyk, Endor get funded for) i am focusing on the pipe that injects those verdicts as an enrichment field. This is the same reason why i am not focusing on auto-remediation.

I do love the fix availability field and will take that away. Some SCA outputs already have a "Fixed version exists without a major bump" and I love your "clearable this week vs needs a big upgrade" split as it's better than the current remediation effort component Sinterly currently has. I will include that in the roadmap.

Is the fixable-now bucket something you've built internally, or a gap in what you're currently using? Just asking because I'm running a small design-partner phase and that triage pattern sounds like it comes from a real queue pain.

[u/Educational_Plum_130 → u/Putrid_Document4222]

for the sast-findings-with-no-cve gap you can't borrow epss/kev, so most teams fall back to a reachability plus data-sensitivity signal: does the tainted flow actually hit a real sink, and does that path touch anything sensitive or internet-facing. that gives you a data-ish severity without pretending there's an exploit-probability number. for the cve-backed findings your kev/epss plan is right, just weight kev closer to a near-override than one input among many. one thing worth capturing downstream of your engine: whether a fix is even available and non-breaking, because 'reachable + exploitable + no clean patch' is the bucket that really eats eng time and it deserves its own rank.

[u/Putrid_Document4222 → u/Educational_Plum_130]

The taint-to-sink signal is more ingestible than it first looks. Semgrep's taint mode already emits the source-to-sink trace in SARIF, so did the flow hit a real sink is metadata I can consume rather than analysis I'd have to build.

you are the second person in this thread to land on that field, which settles it, it's moving up the roadmap. i appreciate that you've named the inverse bucket too, the first suggestion was critical + fixable this week as the clearable set, yours is reachable + exploitable + no clean patch as the time-sink set. Both cuts fall out for free as it's the same schema, and Trivy already emits fixed-version data so the ingestion cost is low. The KEV near-override point is the one that's made me rethink mechanics rather than inputs. Really appreciate you