The Security ETL Engine.
Request a trialSecurity scanners produce thousands of findings and almost no direction. Sinterly ingests them, verifies exploitability and reachability, and ranks what actually matters — so teams act on the few findings that change your risk, not the many that do not.
These are screens from Sinterly running on Kademos Labs' own security data — not a mock-up. Each one is built around the same idea: every number can be traced to the findings that produced it.
A finding's priority is five weighted components — exploitability, reachability, business context, cost of delay, remediation effort. The weights are yours to tune, they must sum to 1.00, and every past score keeps the weights it was calculated with. The ranking is never a black box.
Open findings by severity, what is in remediation, what is ageing past thirty days, and the deduplication and Jira queues still waiting on a person — the whole tenant's posture on a single screen.
Critical exposure on your production-critical tier, quarterly fix rate, backlog by age, exposure by business tier — the board view, exportable as a summary, with every figure drilling into the findings behind it.
We measured it on production, not a demo rig: a SARIF upload was deduplicated, scored and ranked on the dashboard in 4.8 seconds. CSV took 4.1, a threat model 3.9. Your first ingestion is minutes of work, not a migration project.
Upload SARIF, CSV or OTM through the dashboard, or connect a source and pull findings directly.
Deduplicate, enrich, and verify reachability and exploitability.
A five-component score — every number citable to its evidence.
Role-aware views and Jira tickets, so the right work reaches the right team.
Only integrations that are built and verified today. Any SARIF 2.1.0 file is accepted — verified with Semgrep and Trivy; Grype, ZAP, Gitleaks, Checkov and CodeQL output is recognised.
Sinterly works on scanner findings — it has no path to your source code. Every trust claim below names its mechanism.
Security scanners produce findings in incompatible formats with no shared idea of severity, priority, or ownership. Sinterly ingests those findings (extract), normalises and deduplicates them into one finding model (transform), scores them with an explainable five-component formula, and routes the result to your dashboard and ticketing (load). The same discipline data teams apply to analytics pipelines, applied to security findings.
Ingestion: any scanner that produces SARIF 2.1.0 — verified with Semgrep and Trivy, with Grype, ZAP, Gitleaks, Checkov and CodeQL output recognised — plus CSV exports, OTM threat-model files (pytm, IriusRisk), and a direct connector for GitHub Code Scanning. Ticketing out: Jira. Asana and Azure DevOps are planned; you can register interest in the product and we build the most-requested first. We only list integrations that are built and verified.
No — and this is deliberate. Sinterly works on scanner findings, never source code. Upload scanner output you export yourself and we hold nothing else. If you use the GitHub Code Scanning connector, its token is scoped to scanner findings only — a fine-grained token with code-scanning read cannot read your repositories' contents — and it is encrypted with AES-256-GCM before it reaches our database, never displayed again after saving.
Findings are stored with row-level tenant isolation enforced by the database itself — other tenants' data is invisible by construction. Every administrative action is recorded in an append-only audit log protected by a database immutability trigger. Integration credentials are encrypted with AES-256-GCM before they reach the database and are never displayed again after saving.
Scanner severity tells you how bad a vulnerability class is in the abstract. Sinterly's score combines five weighted components — exploitability, reachability, business context, cost of delay, and remediation effort — into one number, and every score shows its inputs and the weights used at the time it was calculated. You can read the formula, tune the weights, and audit every historical score. No black boxes.
DefectDojo is a capable open-source findings warehouse you host, operate, and configure yourself, with prioritisation largely left to you. Sinterly is hosted and opinionated: explainable prioritisation, deduplication with human-confirmed merges, and ticketing sync are the product, not plugins you assemble. If you have the time and people to run your own instance, DefectDojo is a fair choice — Sinterly is for teams that do not.
No, by design. Sinterly tells you what to fix first and why — with evidence — and routes the work to your ticketing. It never modifies your code; auto-remediation is a different product with different risks, and bolting it on would compromise the thing Sinterly does well. Each finding carries a suggested fix as guidance for the engineer who owns it.
Not yet — certification audits cost more than makes sense at our stage, and we would rather be honest about that than imply otherwise. What we have done: verified the platform against ASVS 5.0 (L2 for the core chapters, L1 elsewhere), enforced tenant isolation at the database layer, made the audit log append-only, and encrypted credentials app-side. The full architecture is on our Security page. SOC 2 is planned when customer procurement requires it.
A real person from the team contacts you, sets up your tenant, and walks you through your first ingestion — typically starting with a SARIF export from a scanner you already run. From there the product is self-serve: upload through the dashboard and your prioritised backlog appears in seconds. Early trials are deliberately hands-on: you get direct support, and your feedback shapes the roadmap. No credit card, no automated drip campaign.
Nothing during the trial period. Pricing will be set with early customers rather than announced at them — if the tool proves its value to you, we will agree something fair.
Tell us where to reach you and we will be in touch.