1. Architecture Purpose
SentriScope is designed as a Cyber Risk Intelligence Platform, not a vulnerability consolidation tool. The architecture structures all security telemetry into canonical layers:
- Multi-tenant SaaS readiness — All data is tenant-attributed by design.
- Canonical data normalization — Data from all sources (scanners, SIEM, ITSM, threat intel, CMDB) is normalized into a single model regardless of origin.
- Risk-based prioritization — Deterministic, explainable risk scoring over canonical data.
- Business impact integration — Business Impact Analysis (BIA) feeds directly into risk weighting.
- Control effectiveness modeling — Security controls are measured against assets and exposures.
- AI-ready data structure — Schema grounding enables safe LLM queries over canonical data.
2. Architecture Layers
| Layer |
Name |
Purpose |
| A |
SaaS Foundation |
Tenant lifecycle, RBAC, audit, MFA, notifications |
| B |
Asset and Identity |
CanonicalAsset, CanonicalApplication, CanonicalIdentity, BIA |
| C |
Threat and Assessment |
CanonicalAssessment, CanonicalIncident, CanonicalThreatMonitoringEvent |
| D |
Control and Coverage |
CanonicalControl, ControlImplementation, SecurityCoverage |
| E |
Exposure |
CanonicalExposure, CanonicalVulnerability, CanonicalCredentialLeak |
| F |
Threat Actor |
CanonicalThreatActor, CanonicalCampaign, CanonicalIOC |
| G |
Connector Ingestion |
CanonicalConnectorSession, ConnectorType, ingestion pipeline |
| H |
Risk Scoring |
RiskSnapshot, RiskSnapshotItem, RiskScoringProfile, risk explainability |
| I |
Intelligence |
CanonicalThreatIntelItem, CanonicalIntelAssessment, FeedArticle |
| J |
LLM and Schema |
Schema grounding, LLM context, canonical bundle |
3. Key Canonical Models
Layer B — Asset and Identity
| Model |
Purpose |
Tenant-Scoped |
CanonicalAsset |
Physical/virtual/cloud asset from any source |
Yes |
CanonicalApplication |
Application with BIA context (criticality, RTO, RPO) |
Yes |
CanonicalIdentity |
User identity (from AD, Entra, HR system) |
Yes |
CanonicalIdentityCredential |
Authentication method metadata (no secrets) |
Yes |
CanonicalIdentityAuthEvent |
Authentication event log |
Yes |
CanonicalBIA |
Business Impact Analysis record |
Yes |
CanonicalBusinessUnit |
Business unit organizational unit |
Yes |
CanonicalTeam |
Team within a business unit |
Yes |
Layer C — Threat and Assessment
| Model |
Purpose |
Tenant-Scoped |
CanonicalAssessment |
Security assessment (pentest, tabletop, ASM) |
Yes |
CanonicalAssessmentFinding |
Individual finding from an assessment |
Yes |
CanonicalIncident |
Normalized incident from SIEM, ITSM, or security tool |
Yes |
CanonicalThreatMonitoringEvent |
Suspicious activity / detection (pre-incident) |
Yes |
Layer D — Control and Coverage
| Model |
Purpose |
Tenant-Scoped |
CanonicalControl |
Security control definition |
Yes |
ControlImplementation |
Control deployed on an asset/segment |
Yes |
SecurityCoverage |
Effective coverage measurement per asset |
Yes |
Layer E — Exposure
| Model |
Purpose |
Tenant-Scoped |
CanonicalVulnerability |
Normalized vulnerability (CVE or internal QID) |
Yes |
CanonicalExposure |
Finding hub linking asset + vulnerability + severity |
Yes |
CanonicalCredentialLeak |
Leaked credential record |
Yes |
Layer F — Threat Intelligence
| Model |
Purpose |
Tenant-Scoped |
CanonicalThreatIntelItem |
Normalized TI item with CTI lifecycle |
Yes |
CanonicalThreatActor |
Threat actor profile |
Yes |
CanonicalCampaign |
Attack campaign |
Yes |
CanonicalIOC |
Indicator of Compromise |
Yes |
CanonicalIntelAssessment |
Produced intelligence linked to assets/risks |
Yes |
CanonicalIntelEdge |
Directed relationship between intel entities |
Yes |
Layer H — Risk Scoring
| Model |
Purpose |
Tenant-Scoped |
RiskSnapshot |
Point-in-time risk calculation result |
Yes |
RiskSnapshotItem |
Per-exposure risk item with explainability |
Yes |
RiskScoringProfile |
Tenant-configurable scoring weights |
Yes |
RiskSnapshotDrift |
Change tracking between snapshots |
Yes |
4. Provenance and Source Model
Every canonical record stores the origin of the data:
| Field |
Required |
Purpose |
source_system |
Always |
Which system produced this record (e.g. TENABLE, DEFENDER) |
external_id |
Always |
Stable ID in the source system |
source_updated_at |
Always |
When the source system last updated the record |
Provenance enables:
- Deduplication — Upsert key: (tenant_id, source_system, external_id)
- Traceability — Trace any canonical record back to its origin
- Audit — Who changed what, when, from which source
5. Information Sources
| Source |
Description |
Canonical Models Fed |
| CMDB |
Configuration Management Database |
CanonicalApplication, CanonicalAsset |
| Assessments |
Pentesting, Tabletop, Threat Hunting, ASM |
CanonicalAssessment, CanonicalVulnerability, CanonicalExposure |
| EDR (endpoint) |
CrowdStrike, Defender, SentinelOne, Cortex XDR, Trellix |
CanonicalAsset, CanonicalIncident, CanonicalThreatMonitoringEvent |
| Microsegmentation |
Akamai Guardicore |
CanonicalAsset, CanonicalAssetNetworkFlow, CanonicalSegmentationPolicy |
| Threat intel feeds |
IOCs, actor profiles, campaigns |
CanonicalThreatIntelItem, CanonicalIOC, CanonicalThreatActor, CanonicalCampaign |
| ITSM |
ServiceNow, Jira |
CanonicalIncident |
| SIEM |
Security incidents and alerts |
CanonicalIncident, CanonicalThreatMonitoringEvent |
| Vulnerability scan |
Tenable, Qualys |
CanonicalVulnerability, CanonicalExposure, CanonicalAsset |
| Credential leaks |
Tempest Prospero, DRP feeds |
CanonicalCredentialLeak, CanonicalExposure, CanonicalIdentity |
| ASM |
Attack Surface Management |
CanonicalAsset, CanonicalApplication, CanonicalVulnerability |
| BIA |
Business Impact Analysis |
CanonicalBIA, CanonicalApplication |
| Security ratings |
BitSight, SecurityScorecard |
CanonicalExposure (rating issues) |
6. Severity Normalization Standard
All severity values from all sources are normalized to a 0–100 canonical scale before storage:
| Canonical Range |
Meaning |
| 90–100 |
Critical |
| 70–89 |
High |
| 40–69 |
Medium |
| 10–39 |
Low |
| 0–9 |
Informational |
Normalization Rules
- All connectors must call
normalize_severity(value, source_system, source_scale) from apps.canonical.services.severity_normalization.
source_scale must be explicit — never inferred (avoids ambiguity on 0–10 vs 0–100).- Categorical severity (critical/high/medium/low/info) is mapped to numeric before normalization.
- No connector may write raw severity into canonical fields.
7. Risk Scoring Architecture
7.1 Determinism Guarantee
Risk scoring is deterministic: identical inputs always produce identical outputs. Historical snapshots are never retroactively altered.
| Property |
Rule |
| Algorithm versioning |
Scoring algorithm is version-controlled |
| Immutability |
Historical snapshot scores never change after calculation |
| Explainability |
Every RiskSnapshotItem carries scoring lineage |
7.2 Risk Score Components
- Inherent risk: Base vulnerability severity × asset criticality
- Residual risk: Inherent risk after control effectiveness reduction
- Business impact: BIA weight (criticality, RTO, RPO)
- Threat intelligence influence: Intel source type × tier × confidence × decay factor
- Control effectiveness: Coverage quality per asset and control type
7.3 Scoring Profile
One RiskScoringProfile is active per tenant at a time. Changing the profile generates a new snapshot; historical snapshots retain the profile used at calculation time.
8. Database Strategy
8.1 Database Layout
| Database |
Content |
Isolation |
default |
Platform tables + shared-mode tenant data |
tenant_id scoping via ORM |
tenant_{id} |
Dedicated-mode tenant data |
Physical DB isolation |
8.2 Router
TenantDatabaseRouter routes all ORM queries:
1. Checks get_current_tenant().isolation_mode
2. If DEDICATED, returns the tenant's database alias
3. If SHARED, returns default
8.3 Platform Data Segregation
| Data Type |
Database |
Why |
| Tenant, TenantDomain, TenantDatabaseConfig |
default |
Platform control — must always be accessible |
| User, Group |
default |
Cross-tenant — one user may be in multiple tenants |
| AuditLog |
default |
Platform-level — never deletable by tenant |
| CVE, CWE, MITRE references |
default |
Platform-shared — one copy, all tenants |
| CanonicalAsset, CanonicalExposure, etc. |
Tenant DB |
Business data — fully tenant-scoped |
9. Schema Governance
All schema changes must follow:
1. Propose migration with documented impact (tenant isolation, PII, sensitive fields)
2. Architecture or security review for changes affecting isolation, PII, or access boundaries
3. Approval before production apply
4. Post-apply record_schema_version management command
5. CI schema hash verification
See:
10. JSON Schema Layer
Canonical schemas are stored in:
foundations/schema/canonical/ ← CanonicalAsset.schema.json, etc.
foundations/schema/canonical_bundle.json ← Combined bundle for LLM context
The canonical bundle is loaded by the LLM pipeline for schema grounding. All new canonical models must have a corresponding JSON schema. See:
Related Articles