File imports
File import is the fastest way to get value out of Sinterly and works with effectively any tool. Upload through the browser, or post the file from your CI pipeline using the ingest API.
How an upload behaves
- You select a file, up to 25 MB, in SARIF, CSV or OTM format.
- Sinterly parses it without writing anything and shows you a preview: the finding count, the severity breakdown and the first few titles.
- You confirm. Only then does anything enter your tenant.
- The pipeline deduplicates, enriches, scores and, if configured, creates tickets and evaluates the gate.
- A run report tells you what was created, updated and merged.
If the file cannot be parsed, the message tells you the specific reason rather than showing a generic failure.
SARIF import
Any SARIF 2.1.0 file is accepted. Severity is read the way each tool intends, including from the rule's default configuration when an individual result carries none, so a Semgrep file and a Trivy file both arrive with sensible severities rather than everything defaulting to medium.
Two commands that produce real SARIF:
semgrep --config p/owasp-top-ten <repo> --sarif > results.sarif
trivy fs <repo> --format sarif --output results.sarifWhere a SARIF file includes taint flow information, Sinterly stores the scanner's steps verbatim, so a developer can see the path the tool traced from source to sink.
CSV import
For tools with no SARIF export. Your file needs a header row. Columns are matched case insensitively against the aliases below, and the first match wins.
| Field | Recognised column names |
|---|---|
| Identifier | id, finding_id, issue_id, vulnerability_id, vuln_id, uid, ref, reference |
| Title | title, name, vulnerability, issue, summary, description_short, rule, vulnerability_name, issue_title |
| Description | description, details, detail, message, info |
| Severity | severity, risk, priority, level, criticality, cvss_severity, severity_level |
| CVSS score | cvss_score, cvss, score, cvss3_score, cvss2_score, cvss_base_score, base_score, cvss_v3_score |
| CVE | cve, cve_id, cve_number, cve_ids |
| CWE | cwe, cwe_id, cwe_number, cwe_ids, cwes, weakness, weakness_id |
| File path | file, file_path, path, location, filename, filepath |
| Line number | line, line_number, line_no, lineno, start_line |
| Component | component, package, package_name, library, module, affected_component, dependency, dependency_name, artifact, pkg |
| Repository | repository, repo, project, target, source |
| Tool | tool, scanner, source, source_tool |
| Vulnerability class | type, vulnerability_type, category, class, finding_type |
| Fixed version | fixed_version, installed_version |
Only a title and a severity are strictly required. Everything else improves scoring accuracy. Supplying a CVE is particularly valuable, because it unlocks the KEV and EPSS enrichment that drives the exploitability verdict.
Threat model import
OTM files are covered separately, because they behave differently from scanner output. See Threat models.
Uploads and connectors together
You can use both. A finding's identity is derived from the project, the source tool and the identifier the tool gave it, not from how it arrived. That means moving a scanner from manual upload to a connector does not duplicate anything.