Overview
The Governance pillar provides the organizational controls that ensure consistency, repeatability, and auditability across all ThreatZ projects. It encompasses four core capabilities: Policy Management for defining organizational security rules, Security Catalogs for maintaining reusable libraries of security artifacts, Blueprints for templating project configurations, and Baselines for tracking security state over time.
Policy Management
Policies are organizational rules that govern how cybersecurity analysis is conducted across projects. Each policy defines:
- Scope: Global (applies to all projects) or Project-Specific
- Enforcement Level: Mandatory, Advisory, or Informational
- Status: Active or Archived, with version tracking (major.minor)
- Applicable Modules: Threat Modeling, Incident Management, Risk Assessment, BOM Supply Chain
Policy Configuration Areas
| Area | What It Controls |
|---|---|
| Risk Calculation | Methods, impact boundaries (0–2), TAF boundaries (0–2), risk score boundaries (1–5) |
| Risk Acceptance | Accepted risk levels, permitted treatment strategies |
| Incident Management | Response SLAs, incident configuration |
| Trusted Sources | Accepted vulnerability databases (NVD, OSV), threat intelligence feeds |
| License Compliance | Accepted software licenses, SBOM format requirements |
| Impact & Feasibility | Boundary values for impact ratings and attack feasibility ratings |
Policy Lifecycle
- Create policy with scope, enforcement level, and module configurations
- Validate risk boundaries and method references
- Activate policy (one active global policy at a time)
- Associate policy with projects or programs
- Archive when superseded
Policies are enforced at the service layer — risk calculations, acceptance criteria, and treatment strategies are validated against the active policy during all TARA and risk assessment operations.
Security Catalogs
Security Catalogs are centralized, versioned libraries of reusable security artifacts shared across the organization.
Catalog Types
| Catalog | Content | Key Fields |
|---|---|---|
| Assets | Cybersecurity targets | Domain, category, security properties |
| Threats | Attack scenarios | STRIDE classification, category, tags |
| Damages | Impact scenarios | Safety, financial, operational, privacy impact |
| Controls | Mitigation measures | Type, validation method, cost, maturity level, framework reference |
| Goals | Security objectives | Framework standard, linked requirements |
| Requirements | Security needs | Type, validation type, acceptance criteria |
| Claims | Security assertions | Claim type, statement |
| Licenses | Software licenses (SPDX) | License terms, compliance classification |
Catalog Features
- Versioning: Major.minor version tracking with status (Active, Archived, Under Review)
- Framework Tagging: Map catalog items to ISO 21434, ISO 26262, ISO 27001, SAE J3061, and other standards
- Global vs. Project: Global catalogs are organization-wide; project catalogs instantiate global items with project-specific context
- Catalog Sync: Automated synchronization propagates catalog updates across all projects, tracking create/update counts for protocol packs, attack vectors, test cases, step templates, assets, threats, controls, goals, requirements, security events, vulnerabilities, claims, and damages
- Portable Catalogs: Import/export catalogs in portable format for cross-organization sharing
- Seeding: Default catalogs (SPDX licenses, risk methods, tool definitions, threat intelligence sources) are seeded automatically during tenant provisioning
Blueprints
Blueprints are reusable project templates that package module configurations into a ready-to-deploy starting point.
- Structure: Name, description, applicable modules, and status (Active, Archived, Under Review)
- Snapshots: Point-in-time captures of blueprint configuration for version control
- Publishing: Governed by approval workflows with feature-gate access control
- License Gating: Blueprint features are gated by organization license tier
Blueprints reduce project setup time by providing pre-configured module selections, catalog associations, and policy references that teams can apply to new projects.
Baselines
Baselines are immutable snapshots of campaign finding state used for regression tracking and security trend analysis.
Baseline Structure
- Source campaign run reference
- Finding snapshot (total count, severity breakdown, status breakdown, deduplication fingerprints)
- Status lifecycle: Active → Superseded → Archived
- Only one active baseline per campaign profile at a time
Baseline Comparison (Delta Reports)
When comparing a new campaign run against a baseline, the platform generates a delta report with:
| Delta Type | Meaning |
|---|---|
| New | Finding in current run but not in baseline |
| Fixed | Finding in baseline but not in current run |
| Unchanged | Finding exists in both |
| Regressed | Finding was fixed but has reappeared |
| Severity Changed | Same finding, different severity level |
Regression Alerts
| Alert Type | Trigger | Priority |
|---|---|---|
| New Critical | Any new critical-severity finding | P1 |
| New High | 3+ new high-severity findings | P2 |
| Regression | Any previously fixed finding reappears | P1 |
| Score Drop | Security score decreases by >25% | P2 |
Trend Reports
The platform generates time-series trend analysis across campaign runs for a given profile:
- Security score over time with trend classification (Improving / Stable / Worsening)
- New vs. fixed finding counts per run
- Average, minimum, and maximum scores
- Unique finding count across all runs
Governance Controls for Baselines
- Permission-based access:
baseline:view(Read),baseline:create(Write),baseline:promote(Full Access),baseline:archive(Full Access) - Approval workflows for baseline promotion
- Full audit trail for all baseline operations
Integration with Other Pillars
| Direction | Pillar | Data Flow |
|---|---|---|
| Outbound | TARA | Policies define risk calculation methods, boundaries, and acceptance criteria |
| Outbound | Testing | Catalogs provide protocol packs, attack vectors, test case templates |
| Outbound | SBOM | Policies define trusted vulnerability sources and license compliance rules |
| Outbound | Operations | Policies define incident response SLAs |
| Outbound | Compliance | Policies and catalogs feed compliance framework mappings |
| Outbound | Design | Blueprints template project module configurations |
| Inbound | Testing | Campaign runs provide finding data for baselines |
| Inbound | All pillars | Activity logs and audit trails feed governance reporting |