Sinterly documentation

Sinterly takes the output your security scanners and threat-modelling tools already produce, normalises it into a single finding model, removes the duplicates, decides what genuinely matters, and then holds a line on the worst of it in your build pipeline.

It does not scan your code. It does not modify your code. It never needs a copy of your source. You bring findings; Sinterly brings order, a decision record, and an enforcement point.

What problem it solves

Most teams running three or four scanners have the same three problems:

Sinterly answers all three, and then adds the part almost no tool does: it can refuse to let the worst findings through your pipeline, and it can tell you honestly how often that refusal is being waved through.

How it works, in one line

Ingest, transform, prioritise, act. Findings arrive from connectors or file uploads. They are deduplicated and enriched. Each is scored on five visible components. The result reaches your dashboard, your Jira board, and if you choose, your build.

A note on what Sinterly will not do

Two things are deliberately absent, and both are design decisions rather than gaps:

Where to start

If you areStart here
New, with a trial just approvedQuickstart
Wondering what the words meanKey concepts
Connecting your scannersIntegrations
Wiring this into CIThe CI gate
Reviewing us before buyingSecurity architecture
Stuck on somethingTroubleshooting

Getting help

Every page in the application has a help menu with a contact option that opens a support request. During a trial you also have a named human who set your tenant up. You are not routed to a queue.