Key concepts

Every term here appears in the product. If a page confuses you, the definition is probably on this page.

Finding

One security issue, in one place, as reported by one tool. Findings are the unit everything else is built on. A finding has an identity that does not change when the same issue arrives again from a different route, which is why switching from uploads to a connector does not duplicate your backlog.

Implementation finding and design finding

An implementation finding is a defect in something that exists: a vulnerable dependency, an injection flaw, a misconfiguration. Every scanner produces these.

A design finding is a threat from a threat model. It describes something that could go wrong by design, before any code is examined. These live in the Threat register rather than mixing into scanner output, because they are answered differently. See Threat models.

Target and tier

A target is an application or system. Each carries a business-context tier from A to D describing how exposed and how valuable it is. Tier A means public-facing and revenue-generating; tier D means an internal system with no public surface.

The tier feeds the business-context score, the CI gate, and the cost figures. It is the setting most worth getting right.

Project

A container beneath a target, usually corresponding to one repository or one scanner feed. Closure detection works per project and per tool, which is why it is better to give each repository its own project than to pile several into one.

Priority score

A number from 0 to 100 combining five components with weights you control. It exists to order your backlog, not to be a risk rating in any formal sense. See Priority scoring.

Exploitability verdict

Sinterly's own judgement about whether a finding is exploitable, with the evidence attached. A verdict is one of:

• Exploitable. There is positive evidence, such as presence in the CISA Known Exploited Vulnerabilities catalogue or a high EPSS probability.
• Unlikely. Evidence points the other way.
• Unverified. There is no evidence either way, so the score falls back to the severity the scanner reported. This is common and is not a failure.

The distinction matters because the CI gate acts only on verified verdicts. It will not block a build on a label a scanner asserted without evidence.

Finding status

See Risk decisions for what each one obliges you to record.

Closure detection

When a finding stops appearing in scans of the same project and tool, it accrues an absence. After three consecutive absences it is marked as fixed. One absence is never enough, because scan scope changes. If it reappears while marked fixed, it reopens, because still being detected means not fixed.

An empty or failed scan increments nothing, so uploading the wrong file cannot close your backlog.

The gate

A small, explicit policy evaluated after every ingest, which can tell your CI pipeline to fail a build. It uses conditions rather than a score threshold. See The CI gate.

Override

A finding that meets the blocking policy but has been suppressed by a human decision. Overrides are legitimate and expected. What matters is that each one has a named owner, a written reason and a date it runs out. The proportion of must-fix findings currently running on an override is reported to your executives.

Roles

AppSec Lead is the operating role and the only one that can change findings, policy or settings. Executives read tenant-wide. Developers see the work routed to them. Guests are time-boxed and expire on their own. See Roles and views.

Tenant

Your organisation's isolated space. Tenant separation is enforced in the database itself on every table, not in application code. See Security architecture.