Ingesting findings
Two ways in, both code-blind: upload files you export yourself, or connect a source and pull findings directly. Either way, findings land in the same model with the same identity — you can start with uploads and switch to a connector without creating duplicates.
SARIF import
Any SARIF 2.1.0 file is accepted. Verified with Semgrep and Trivy against real projects; Grype, ZAP, Gitleaks, Checkov and CodeQL output is recognised and mapped to its proper source. Severity is read the way each tool intends — including from the rule's default configuration where the result itself carries none.
semgrep --config p/owasp-top-ten <repo> --sarif > results.sarif
trivy fs <repo> --format sarif --output results.sarifGitHub Code Scanning connector
Connect once, and every scanner that publishes into GitHub code scanning — CodeQL, Semgrep, Trivy and dozens more — becomes pullable through a single integration. Sinterly fetches the newest analysis per tool on each repository's default branch — synced automatically every day, or on demand with one click from the Integrations page.
Setup (Integrations → GitHub Code Scanning → Connect): create a fine-grained personal access token with Code scanning alerts: read-only on the repositories you list. That token cannot read your source code — that is the point. It is encrypted with AES-256-GCM before it reaches the database and never displayed again.
CSV import
For tools without SARIF export. Your CSV needs a header row; columns are recognised case-insensitively by any of the names below (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 |
Threat models (OTM)
Sinterly ingests Open Threat Model 0.2.0 files — exported from IriusRisk, or produced from a pytm script via the OTM adapter. Threats enter as design-time findings: they appear in the Threat register rather than mixing into scanner output, and your AppSec Lead links each threat to the implementation findings that evidence it in code. A threat with links is demonstrably addressed; one without is an open design risk.