Core concepts

A short vocabulary. These terms mean something specific in Sentrasec, and the rest of the documentation uses them precisely.

Workspace

The top-level tenant boundary. A workspace owns apps, users, policies and findings. Access control, retention and billing are all scoped to it.

App

A logical unit of software you are securing: typically a service, a repository or a deployable component. An app groups everything scanned about that unit so its findings, history and posture stay together over time.

Target

A specific thing a scan runs against: a repository path, a container image or a running URL. One app usually has several targets: the source, the image built from it, and the deployed instance.

Scan

One execution of one or more scanners against a target. A scan is immutable: it records what ran, against what, when, and with which rule versions. Reproducibility depends on that.

Finding

A single detected issue, anchored to a location in a target. Findings carry:

• What matched: the rule, and the code path or configuration that triggered it.
• Classification: CWE, OWASP category, and CVE where applicable.
• Severity: on one scale across every scanner.
• Evidence: the artefacts supporting the detection.
• Context, which app, environment and owner it belongs to.

Findings come from Sentrasec's own scans or are imported from existing scanners such as Snyk, Semgrep, SonarQube, Checkmarx, Veracode, Trivy, Qualys, Tenable, Prisma Cloud and GitHub code scanning. They are deduplicated across scanners within a scan, and correlated across scans over time, so the same underlying issue stays one finding as it moves through its lifecycle.

Triage decision

For each finding, Sentrasec decides whether it needs action (remediate) or can be deferred. The decision uses evidence from the app: is the endpoint reachable, does attacker-controlled input reach it, does the vulnerable code ship to runtime, is there a compensating control. Decisions are deterministic and keep their evidence. A language model writes only the explanation prose.

Remediation plan and test plan

For a finding that needs action, the remediation plan describes the change to make and the files, endpoints and tests it touches. The test plan lists the tests and the SAST recheck that prove the change worked. Sentrasec does not edit your code or run your tests: your coding agent receives both plans over MCP, makes the change and runs the tests.

Rule

A detection definition. Rules are versioned, and a rule declares its relationships: the weakness class it detects and the categories above it. That is what lets a finding explain itself.

Knowledge graph

The connected store of security knowledge: rules, CVEs, CWEs, OWASP categories, packages, remediations and the relationships between them, plus your apps and findings. Reasoning follows those relationships rather than performing a series of isolated lookups.

Policy

The rules governing what happens to findings: severity thresholds, gating behaviour in CI and rule overrides.

Evidence

The artefacts that justify a finding or a decision about one. Evidence is what makes a deferral checkable months later. Scans, triage decisions, remediation plans and re-scans are kept as records mapped to SOC 2, ISO 27001, PCI DSS, HIPAA, GDPR and DORA controls.

Where things run

On Sentrasec Cloud, scanning and storage run on our infrastructure. In a self-hosted deployment, they run in your environment and your code stays there. See self hosting.