info-tech-canon/infospace/models/security/InfoTechCanonSecurityModel.md

---
owned_concepts:
  - AttackImpact
  - AttackPath
  - AttackPattern
  - AttackPrecondition
  - AttackStep
  - AttackTechnique
  - BlastRadius
  - ChokePoint
  - CompensatingMeasure
  - Containment
  - DataSecurityFinding
  - Detection
  - DetectionCoverage
  - DetectionRule
  - Eradication
  - Exploit
  - ExploitLikelihood
  - Exploitability
  - Exposure
  - ExposureFinding
  - HardeningMeasure
  - IdentityFinding
  - Investigation
  - LessonLearned
  - Misconfiguration
  - MisconfigurationFinding
  - Mitigation
  - PenTestFinding
  - ProtectedAssetReference
  - Recovery
  - SecurityAssessment
  - SecurityBoundary
  - SecurityDomain
  - SecurityEntity
  - SecurityEvidence
  - SecurityFinding
  - SecurityIncident
  - SecurityMeasure
  - SecurityPosture
  - SecurityPostureScore
  - SecurityReview
  - SecuritySignal
  - Severity
  - SupplyChainFinding
  - Tactic
  - Threat
  - ThreatActor
  - ThreatEvent
  - Vulnerability
  - VulnerabilityFinding
  - Weakness
---

# InfoTechCanon Security Model

**Short Name:** `ITC-SEC`
**Document Status:** Seed Standard Release Candidate 1
**Version:** RC1-seed
**Date:** 2026-05-22
**Repository Context:** `info-tech-canon`
**Document Type:** InfoTechCanon Domain Standard
**Intended Audience:** Security architects, platform engineers, DevSecOps teams, service owners, risk managers, governance designers, incident responders, vulnerability managers, detection engineers, software assurance teams, access-control designers, knowledge-system builders, and agentic tooling.

---

# 1. Purpose

The **InfoTechCanon Security Model** defines a canonical seed model for representing cybersecurity posture, threats, weaknesses, vulnerabilities, exposures, findings, attack paths, mitigations, detections, incidents, response, recovery, and security assurance across information-processing systems.

It exists to connect security knowledge to the rest of InfoTechCanon without duplicating governance, access control, landscape, organization, task, or tagging semantics.

This standard provides:

- a canonical vocabulary for security entities,
- a distinction between threat, weakness, vulnerability, exposure, finding, risk, incident, and control,
- security-specific mappings to external frameworks and taxonomies,
- support for vulnerability management and threat-informed defense,
- support for detection, response, and recovery,
- support for software and platform security posture,
- support for security findings and remediation tasks,
- support for attack-path and exposure modeling,
- support for security evidence and assurance,
- profile hooks for concrete implementation contexts,
- and retrieval-friendly structure for humans, agents, and markdown-based infospaces.

---

# 2. Position in InfoTechCanon

The Security Model is a **domain standard** within InfoTechCanon.

It depends on the existing seed standards as follows:

```text
Landscape      = systems, services, resources, data, endpoints, runtime, networks.
Organization   = actors, owners, responders, teams, responsibilities.
Governance     = policies, controls, control objectives, risk, exception, evidence.
Task           = remediation, investigation, response, review, and hardening work.
Tagging        = classification of findings, assets, vulnerabilities, and evidence.
Access Control = authorization, permissions, privileges, grants, decisions, and sessions.
Security       = threats, weaknesses, vulnerabilities, exposure, attack paths,
                 incidents, detection, response, recovery, and posture.
```

```text
InfoTechCanon
├── InfoTechCanonCore
├── InfoTechCanonLandscapeModel
├── InfoTechCanonOrganizationModel
├── InfoTechCanonGovernanceModel
├── InfoTechCanonTaskModel
├── InfoTechCanonTaggingStandard
├── InfoTechCanonAccessControlModel
├── InfoTechCanonSecurityModel          <-- this standard
├── InfoTechCanonDataModel
├── InfoTechCanonDevSecOpsModel
├── InfoTechCanonNetworkModel
├── InfoTechCanonObservabilityModel
├── InfoTechCanonPatternLanguage
└── Application Profiles
```

---

# 3. Boundary with Adjacent Standards

## 3.1 Boundary with Governance

The Governance Model owns:

```text
Policy
Rule
ControlObjective
Control
Risk
Exception
Audit
Assurance
ComplianceRequirement
Decision
Approval
Review
```

Evidence and Evidence Source are imported from ITC-EVID.

The Security Model owns:

```text
Threat
ThreatActor
AttackTechnique
Weakness
Vulnerability
Exposure
SecurityFinding
SecurityIncident
AttackPath
Mitigation
Detection
SecuritySignal
SecurityPosture
SecurityAssuranceSignal
```

Boundary rule:

```text
Governance defines the rule, control, risk, exception, evidence, and assurance structure.
Security defines the adversarial, defensive, vulnerability, incident, detection, and posture semantics.
```

## 3.2 Boundary with Access Control

The Access Control Model owns:

```text
Subject
Principal
Permission
Privilege
Entitlement
Grant
AuthorizationDecision
AccessSession
AccessReview
BreakGlassAccess
AgentAccess
```

The Security Model may analyze these as security-relevant.

Examples:

```text
ExcessAccess is an AccessFinding and may also be a SecurityFinding.
PrivilegeEscalationPath is a Security AttackPath involving AccessControl entities.
CredentialMisuse is a SecurityIncident involving AccessSession and CredentialReference.
```

## 3.3 Boundary with Landscape

The Landscape Model owns:

```text
Service
ApplicationService
SoftwareComponent
Repository
Artifact
RuntimeResource
NetworkEndpoint
Dataset
Environment
NetworkPath
ObservabilitySignal
```

Security applies to those entities.

Examples:

```text
Vulnerability affects Artifact
Exposure affects Endpoint
AttackPath traverses NetworkPath
SecurityIncident affects Service
Mitigation applies_to RuntimeResource
```

## 3.4 Boundary with Task

The Task Model owns work semantics.

Security creates or references tasks such as:

```text
RemediationTask
IncidentTask
InvestigationTask
HardeningTask
ReviewTask
ApprovalTask
SecurityExceptionTask
```

## 3.5 Boundary with DevSecOps

The DevSecOps Model should own delivery pipeline, build, release, artifact, SBOM, attestation, and deployment semantics.

The Security Model owns security interpretation of those entities.

Examples:

```text
SCAFinding affects Artifact
SBOMEvidence supports VulnerabilityAssessment
PolicyGate enforces SecurityControlImplementation
UnsignedArtifact is SecurityFinding
```

---

# 4. Research Basis and External Alignment

This seed standard draws on multiple security knowledge bodies.

## 4.1 NIST Cybersecurity Framework 2.0

NIST CSF 2.0 organizes cybersecurity outcomes into six high-level functions: Govern, Identify, Protect, Detect, Respond, and Recover. The Security Model uses these as a useful security lifecycle mapping target while leaving general governance semantics to the Governance Model.

## 4.2 MITRE ATT&CK

MITRE ATT&CK is a knowledge base of adversary tactics and techniques based on real-world observations. It is a strong mapping target for threat-informed defense, detection coverage, adversary behavior, attack techniques, and mitigations.

## 4.3 CVE, CWE, CVSS, and EPSS

CVE provides common identifiers for publicly known information-security vulnerabilities. CWE provides common software and hardware weakness types. CVSS communicates vulnerability characteristics and severity, while EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days.

The Security Model must distinguish:

```text
Weakness  -> class of flaw or error pattern.
Vulnerability -> specific exploitable flaw or exposure.
Severity -> technical impact characteristics.
Exploit likelihood -> probability or evidence of exploitation.
Risk -> context-specific uncertainty or exposure relative to objectives.
```

## 4.4 OWASP ASVS and SAMM

OWASP ASVS provides a basis for testing web application technical security controls and secure development requirements. OWASP SAMM provides an open framework for formulating and improving a software security strategy. These are important mapping and assimilation targets for application security and software assurance.

## 4.5 Security Operations and Incident Response

Security operations practice distinguishes signals, detections, alerts, incidents, investigations, containment, eradication, recovery, lessons learned, and evidence.

## 4.6 Attack Graphs and Exposure Management

Modern exposure management and attack-path analysis combine vulnerabilities, misconfigurations, identity permissions, network reachability, data sensitivity, and runtime context to prioritize security work.

---

# 5. Seed Standard Design Stance

This standard is a **seed standard**, not a full security program manual.

It shall:

1. define canonical security semantics,
2. distinguish security from governance and access control,
3. support vulnerability, weakness, exposure, finding, and risk separation,
4. support threat-informed defense and attack-path modeling,
5. support detection, incident, response, and recovery concepts,
6. support software, platform, cloud, network, identity, data, and operational security,
7. support human and agentic security contexts,
8. map to external taxonomies without becoming subordinate to them,
9. remain markdown-first and agent-retrievable,
10. and support future assimilation of security standards, frameworks, products, and research.

---

# 6. Scope

## 6.1 In Scope

This standard covers canonical representation of:

- security posture,
- security domains,
- assets as security-relevant landscape references,
- threat actors,
- threat events,
- attack techniques,
- attack patterns,
- attack paths,
- weaknesses,
- vulnerabilities,
- exposures,
- misconfigurations,
- security findings,
- security signals,
- detections,
- alerts,
- incidents,
- investigations,
- containment,
- eradication,
- recovery,
- mitigations,
- compensating security measures,
- exploitability,
- severity,
- exploit likelihood,
- asset criticality reference,
- security impact,
- blast radius,
- security evidence,
- security assurance signals,
- security exceptions as governance references,
- remediation references,
- and security mappings.

## 6.2 Out of Scope

This standard does not fully define:

- general governance policy and control theory,
- full legal and regulatory compliance,
- complete access-control implementation,
- complete incident-response playbooks,
- complete malware analysis,
- full cryptographic protocol design,
- detailed secure coding standards,
- complete cloud provider security models,
- complete SIEM query languages,
- or all security product schemas.

Those may be mapped, assimilated, profiled, or handled by adjacent standards.

---

# 7. Normative Language

The following terms are used normatively:

- **SHALL** indicates a mandatory rule for conformance.
- **SHOULD** indicates a recommended practice.
- **MAY** indicates an optional capability.
- **MUST NOT** indicates a prohibited practice.
- **SEED** marks a concept defined provisionally here but open to later refinement.
- **EXTRACT** marks a concept that may later move to a more specialized standard.

---

# 8. Core Principles

## 8.1 Security Is Contextual

A vulnerability, exposure, or finding becomes important through context:

```text
affected asset
reachable path
exploitability
data sensitivity
privilege
business criticality
active exploitation
compensating controls
```

## 8.2 Vulnerability Is Not Risk

A vulnerability is a flaw or exposure that may be exploitable.

Risk is uncertainty or exposure relative to objectives and context.

## 8.3 Weakness Is Not Vulnerability

A weakness is a class of design, implementation, configuration, or hardware flaw.

A vulnerability is a specific instance that may be exploited.

## 8.4 Finding Is Not Always Vulnerability

A finding may indicate:

```text
vulnerability
misconfiguration
policy violation
weak control
suspicious activity
excess access
exposed service
missing evidence
```

## 8.5 Exposure Is First-Class

A system may be at risk not only because it has a CVE, but because an asset is reachable, discoverable, misconfigured, overprivileged, or connected to sensitive data.

## 8.6 Detection and Response Are Part of Posture

Security posture includes not only prevention, but also detection, response, recovery, and assurance.

## 8.7 Security Claims Need Evidence

Important security claims SHOULD reference evidence, source, timestamp, confidence, and scope.

## 8.8 External Taxonomies Are Mapped, Not Obeyed

The Security Model MAY map to NIST CSF, MITRE ATT&CK, CVE, CWE, CVSS, EPSS, OWASP, ISO 27001, CIS, cloud provider controls, and product schemas.

It MUST NOT subordinate its internal semantics to any single external framework.

---

# 9. Canonical Seed Metadata

Every security artifact SHOULD support structured metadata.

Recommended front matter:

```yaml
---
id: itc-sec:Vulnerability
type: concept
standard: InfoTechCanonSecurityModel
standard_version: RC1-seed
status: candidate
canonical_owner: InfoTechCanonSecurityModel
preferred_label: Vulnerability
related:
  - itc-sec:Weakness
  - itc-sec:Exposure
  - itc-sec:SecurityFinding
  - itc-gov:Risk
mappings:
  - itc-map:vulnerability-to-cve
---
```

Recommended artifact statuses:

```text
idea
draft
candidate
release-candidate
adopted
stable
deprecated
retired
```

Recommended concept statuses:

```text
proposed
experimental
candidate
canonical
deprecated
retired
```

---

# 10. Root Security Taxonomy

```text
SecurityEntity
├── SecurityScopeEntity
│   ├── SecurityDomain
│   ├── SecurityBoundary
│   ├── SecurityZoneReference
│   ├── ProtectedAssetReference
│   └── SecurityPosture
├── ThreatEntity
│   ├── Threat
│   ├── ThreatActor
│   ├── ThreatEvent
│   ├── AttackTechnique
│   ├── AttackPattern
│   ├── Tactic
│   ├── CampaignReference
│   └── AdversaryCapability
├── WeaknessVulnerabilityEntity
│   ├── Weakness
│   ├── Vulnerability
│   ├── Exposure
│   ├── Misconfiguration
│   ├── Exploit
│   ├── Exploitability
│   ├── Severity
│   └── ExploitLikelihood
├── FindingEntity
│   ├── SecurityFinding
│   ├── VulnerabilityFinding
│   ├── MisconfigurationFinding
│   ├── ExposureFinding
│   ├── IdentityFinding
│   ├── DataSecurityFinding
│   ├── SupplyChainFinding
│   └── ControlWeaknessFinding
├── AttackPathEntity
│   ├── AttackPath
│   ├── AttackStep
│   ├── AttackPrecondition
│   ├── AttackImpact
│   ├── BlastRadius
│   └── ChokePoint
├── DefenseEntity
│   ├── Mitigation
│   ├── SecurityMeasure
│   ├── HardeningMeasure
│   ├── CompensatingMeasure
│   ├── DetectionRule
│   ├── DetectionCoverage
│   └── SecurityControlImplementationReference
├── DetectionResponseEntity
│   ├── SecuritySignal
│   ├── Detection
│   ├── Alert
│   ├── SecurityIncident
│   ├── Investigation
│   ├── Containment
│   ├── Eradication
│   ├── Recovery
│   └── LessonLearned
└── AssuranceEntity
    ├── SecurityEvidence
    ├── SecurityAssessment
    ├── PenTestFinding
    ├── SecurityReview
    ├── SecurityExceptionReference
    ├── SecurityAttestation
    └── SecurityPostureScore
```

---

# 11. Core Concepts

## 11.1 SecurityEntity

A **SecurityEntity** is any identifiable concept used to represent security posture, adversarial behavior, defensive measures, vulnerabilities, incidents, findings, exposure, detection, response, or assurance.

Recommended attributes:

```yaml
id:
entity_type:
canonical_name:
display_name:
lifecycle_state:
source_system:
created_at:
updated_at:
```

Optional attributes:

```yaml
owner:
steward:
security_domain:
affected_scope:
source_confidence:
valid_from:
valid_to:
tags:
external_references:
```

---

## 11.2 SecurityDomain

A **SecurityDomain** is a scoped area of security concern.

Examples:

```text
application security
cloud security
identity security
data security
network security
endpoint security
supply-chain security
platform security
operational security
physical security
AI/agent security
```

---

## 11.3 SecurityBoundary

A **SecurityBoundary** is a boundary across which trust, control, responsibility, policy, or exposure changes.

Examples:

```text
tenant boundary
network zone boundary
trust boundary
identity domain boundary
runtime namespace boundary
data classification boundary
external integration boundary
```

---

## 11.4 ProtectedAssetReference

A **ProtectedAssetReference** points to a Landscape entity that requires security consideration.

Examples:

```text
service
repository
artifact
workload
endpoint
dataset
secret
identity
network segment
pipeline
environment
```

---

## 11.5 SecurityPosture

**SecurityPosture** is the assessed security condition of an asset, service, domain, environment, or organization.

Posture may derive from:

```text
open findings
control effectiveness
exposure
vulnerability state
attack-path analysis
incident history
security reviews
patch state
detection coverage
access posture
configuration state
```

---

## 11.6 Threat

A **Threat** is a potential cause of unwanted security impact.

Threat may arise from:

```text
adversary
accident
misuse
system failure
supply-chain dependency
insider
automation error
environmental condition
```

---

## 11.7 ThreatActor

A **ThreatActor** is an actor or group that may intentionally cause security harm.

Examples:

```text
criminal group
state-sponsored actor
malicious insider
opportunistic attacker
hacktivist
automated botnet
```

---

## 11.8 ThreatEvent

A **ThreatEvent** is an occurrence or attempted occurrence of adversarial or harmful activity.

---

## 11.9 Tactic

A **Tactic** is an adversary goal or phase of attack behavior.

This concept maps naturally to MITRE ATT&CK tactics.

---

## 11.10 AttackTechnique

An **AttackTechnique** is a method used to achieve an adversary tactic or security objective.

This concept maps naturally to MITRE ATT&CK techniques.

---

## 11.11 AttackPattern

An **AttackPattern** is a reusable pattern describing how an attack may be carried out.

This may map to CAPEC, ATT&CK, or internal threat models.

---

## 11.12 Weakness

A **Weakness** is a class of flaw or error pattern in design, implementation, configuration, process, hardware, or architecture.

Examples:

```text
improper input validation
missing authentication
hardcoded credentials
insecure default configuration
insufficient logging
excess privilege
```

This concept maps to CWE where appropriate.

---

## 11.13 Vulnerability

A **Vulnerability** is a specific weakness, flaw, or exposure that may be exploited to violate security expectations.

Vulnerability records may reference:

```text
CVE
affected artifact
affected version
affected configuration
severity
exploitability
exploit evidence
fix version
workaround
```

---

## 11.14 Exposure

An **Exposure** is a condition that increases the possibility of discovery, access, exploitation, data compromise, or impact.

Examples:

```text
publicly reachable endpoint
open management port
exposed secret
overly broad network path
internet-facing vulnerable service
excessive identity privilege
public storage bucket
```

Exposure may exist without a CVE.

---

## 11.15 Misconfiguration

A **Misconfiguration** is a configuration state that violates security expectation, policy, baseline, or safe design.

---

## 11.16 Exploit

An **Exploit** is code, technique, procedure, or method that uses a vulnerability, weakness, or exposure to cause security impact.

---

## 11.17 Exploitability

**Exploitability** is the practical ability to exploit a vulnerability or weakness in context.

Exploitability may depend on:

```text
network reachability
authentication requirement
privileges required
user interaction
known exploit availability
configuration
runtime condition
environment
```

---

## 11.18 Severity

**Severity** is a measure of technical or potential impact characteristics.

Severity is not the same as risk.

---

## 11.19 ExploitLikelihood

**ExploitLikelihood** is the estimated probability or plausibility that a vulnerability or exposure will be exploited.

This concept may map to EPSS or internal threat intelligence.

---

## 11.20 SecurityFinding

A **SecurityFinding** is an observed security-relevant issue, weakness, vulnerability, misconfiguration, exposure, violation, detection result, or assessment result.

Recommended attributes:

```yaml
finding_type:
affected_entity:
severity:
confidence:
source:
first_seen:
last_seen:
status:
evidence:
recommended_action:
```

---

## 11.21 VulnerabilityFinding

A **VulnerabilityFinding** is a finding that reports a vulnerability affecting an asset, artifact, dependency, configuration, or service.

---

## 11.22 MisconfigurationFinding

A **MisconfigurationFinding** is a finding that reports a security-relevant configuration problem.

---

## 11.23 ExposureFinding

An **ExposureFinding** is a finding that reports a reachable, discoverable, overexposed, or inappropriately public asset or path.

---

## 11.24 IdentityFinding

An **IdentityFinding** is a finding involving accounts, permissions, privileges, credentials, service accounts, sessions, or identity relationships.

Examples:

```text
stale access
orphaned account
excess privilege
unused admin role
credential exposed
weak MFA coverage
privilege escalation path
```

---

## 11.25 DataSecurityFinding

A **DataSecurityFinding** is a finding involving sensitive data, classification, residency, retention, leakage, access, or processing exposure.

---

## 11.26 SupplyChainFinding

A **SupplyChainFinding** is a finding involving dependencies, packages, artifacts, repositories, pipelines, SBOMs, provenance, signatures, build systems, or external suppliers.

---

## 11.27 AttackPath

An **AttackPath** is a sequence of conditions, relationships, weaknesses, privileges, exposures, and actions that could allow an attacker to reach a target or cause impact.

---

## 11.28 AttackStep

An **AttackStep** is one step in an attack path.

Examples:

```text
phish user
obtain token
access repository
modify workflow
build malicious artifact
deploy to production
exfiltrate data
```

---

## 11.29 AttackPrecondition

An **AttackPrecondition** is a condition required for an attack step or path.

Examples:

```text
network reachability
valid credentials
missing MFA
vulnerable package version
public endpoint
write access to repository
```

---

## 11.30 AttackImpact

**AttackImpact** is the security consequence of a successful attack.

Examples:

```text
data exfiltration
service disruption
privilege escalation
code execution
persistence
lateral movement
integrity loss
supply-chain compromise
```

---

## 11.31 BlastRadius

**BlastRadius** is the scope of assets, services, users, tenants, data, or obligations potentially affected by a security event or attack path.

---

## 11.32 ChokePoint

A **ChokePoint** is a point in an attack path where mitigation, monitoring, segmentation, control, or detection can significantly reduce attack feasibility or impact.

---

## 11.33 Mitigation

A **Mitigation** is an action, control, configuration, patch, design change, detection, process, or compensating measure that reduces security risk, exposure, exploitability, likelihood, or impact.

---

## 11.34 SecurityMeasure

A **SecurityMeasure** is a defensive measure used to protect, detect, respond, or recover.

Security measures may implement Governance controls.

---

## 11.35 HardeningMeasure

A **HardeningMeasure** is a security measure that reduces attack surface or strengthens configuration.

---

## 11.36 CompensatingMeasure

A **CompensatingMeasure** is a security measure used when a preferred control or mitigation is unavailable, delayed, or waived.

---

## 11.37 DetectionRule

A **DetectionRule** is logic intended to detect suspicious, malicious, noncompliant, or security-relevant behavior.

---

## 11.38 DetectionCoverage

**DetectionCoverage** describes which threats, techniques, assets, or attack paths are covered by detection rules, telemetry, or monitoring.

---

## 11.39 SecuritySignal

A **SecuritySignal** is a telemetry-derived or assessment-derived signal relevant to security.

Examples:

```text
suspicious login
unexpected network connection
new vulnerable dependency
privilege change
malware detection
policy violation
secret exposure
```

---

## 11.40 Detection

A **Detection** is a recognized security signal or correlation that may indicate a threat, weakness, violation, or incident.

---

## 11.41 Alert

An **Alert** is a notification generated by detection or monitoring logic that may require triage.

---

## 11.42 SecurityIncident

A **SecurityIncident** is an event or set of events that has compromised, or may compromise, confidentiality, integrity, availability, safety, privacy, trust, or compliance.

---

## 11.43 Investigation

An **Investigation** is work performed to determine the nature, scope, cause, impact, and response needs of a security signal, alert, finding, or incident.

---

## 11.44 Containment

**Containment** is action taken to limit the spread, persistence, or impact of an active or suspected security incident.

---

## 11.45 Eradication

**Eradication** is action taken to remove the cause, mechanism, malware, persistence, account compromise, or vulnerability enabling an incident.

---

## 11.46 Recovery

**Recovery** is action taken to restore safe, trusted, and acceptable operation after a security incident.

---

## 11.47 LessonLearned

A **LessonLearned** is knowledge extracted from a security incident, finding, test, audit, or failure.

Lessons may create governance changes, tasks, controls, detections, or standards updates.

---

## 11.48 SecurityEvidence

**SecurityEvidence** is evidence supporting a security finding, assessment, incident, detection, mitigation, review, or assurance claim.

Examples:

```text
scan result
log event
trace
packet capture
screenshot
SBOM
attestation
configuration snapshot
forensic image reference
signed review
```

---

## 11.49 SecurityAssessment

A **SecurityAssessment** is an evaluation of security posture, controls, architecture, code, configuration, exposure, or operation.

---

## 11.50 PenTestFinding

A **PenTestFinding** is a security finding produced by penetration testing or adversarial simulation.

---

## 11.51 SecurityReview

A **SecurityReview** is a review of design, code, configuration, architecture, policy, release, access, data, or operational practice from a security perspective.

---

## 11.52 SecurityPostureScore

A **SecurityPostureScore** is a derived metric summarizing security posture for a scope.

Canonical rule:

```text
SecurityPostureScore SHOULD be traceable to underlying findings, controls,
evidence, risk assumptions, and weighting model.
```

---

# 12. Core Relationship Vocabulary

Recommended root relationship types:

```text
affects
exposes
weakens
exploits
targets
threatens
uses_technique
maps_to_tactic
causes
enables
requires_precondition
traverses
leads_to
mitigates
detects
protects
contains
eradicates
recovers
evidenced_by
generated_by
reported_by
triaged_by
assigned_to
remediated_by
accepted_by
waived_by
compensated_by
maps_to
```

Relationship records SHOULD support:

```yaml
id:
relationship_type:
source_entity:
target_entity:
scope:
valid_from:
valid_to:
source_system:
confidence:
evidence:
rationale:
```

---

# 13. Security State Models

## 13.1 Finding States

```text
new
triaged
confirmed
false_positive
accepted
remediation_planned
remediation_in_progress
mitigated
remediated
verified
closed
reopened
```

## 13.2 Vulnerability States

```text
identified
affected
not_affected
under_investigation
fix_available
workaround_available
patched
mitigated
accepted
closed
```

## 13.3 Incident States

```text
detected
triaged
investigating
contained
eradication_in_progress
recovery_in_progress
recovered
post_incident_review
closed
```

## 13.4 Detection States

```text
candidate
active
tuning
suppressed
deprecated
retired
```

## 13.5 Mitigation States

```text
proposed
approved
implemented
partially_implemented
validated
ineffective
superseded
retired
```

---

# 14. Security Patterns

## 14.1 Pattern: Finding-to-Remediation Trace

**Context:** Security tools produce findings.

**Problem:** Findings do not automatically become resolved security improvements.

**Solution:**

```text
SecurityFinding
  -> Risk / Severity / Exploitability Assessment
  -> RemediationTask
  -> Mitigation
  -> Evidence
  -> Verification
  -> Closure
```

---

## 14.2 Pattern: Vulnerability Context Enrichment

**Context:** A scanner reports a CVE.

**Problem:** CVE severity alone is not enough to prioritize remediation.

**Solution:** Enrich vulnerability findings with:

```text
affected asset
runtime use
internet exposure
known exploit
EPSS or exploit likelihood
business criticality
data sensitivity
reachable path
compensating controls
fix availability
```

---

## 14.3 Pattern: Exposure Without CVE

**Context:** A system is exposed or misconfigured but has no known CVE.

**Problem:** Vulnerability-only programs miss security-relevant exposure.

**Solution:** Model ExposureFinding and MisconfigurationFinding separately from VulnerabilityFinding.

---

## 14.4 Pattern: Attack Path to Choke Point

**Context:** Many findings exist, and not all can be fixed immediately.

**Problem:** Remediation priority is unclear.

**Solution:** Model attack paths and identify choke points where mitigation reduces multiple paths or large blast radius.

---

## 14.5 Pattern: Detection Coverage Map

**Context:** A team wants threat-informed defense.

**Problem:** Detections are not linked to adversary techniques or protected assets.

**Solution:** Map DetectionRules to AttackTechniques, SecuritySignals, and ProtectedAssetReferences.

---

## 14.6 Pattern: Security Exception with Compensating Measure

**Context:** A finding or control gap cannot be fixed immediately.

**Problem:** Informal acceptance hides risk.

**Solution:** Use Governance Exception with explicit security context, compensating measure, expiry, review, and evidence.

---

## 14.7 Pattern: Incident-to-Lesson Loop

**Context:** An incident is resolved.

**Problem:** The same failure pattern recurs.

**Solution:**

```text
SecurityIncident
  -> Investigation
  -> Root Cause / Contributing Conditions
  -> LessonLearned
  -> Governance Change / Security Measure / Task / Detection
```

---

## 14.8 Pattern: Supply Chain Finding Trace

**Context:** A dependency, build, artifact, or provenance issue is discovered.

**Problem:** Security teams cannot connect the issue to runtime impact.

**Solution:**

```text
SupplyChainFinding
  -> Dependency / Artifact / SBOM
  -> DeploymentRecord
  -> RuntimeWorkload
  -> Service
  -> RemediationTask
```

---

## 14.9 Pattern: Identity Exposure Path

**Context:** Permissions, credentials, and relationships create security exposure.

**Problem:** Identity risk is invisible when access data is isolated.

**Solution:** Combine Access Control entities with Security attack path and finding concepts.

---

# 15. Security Profiles

## 15.1 Profile Format

A Security Profile SHALL declare:

```yaml
id:
profile_name:
status:
implements:
  - InfoTechCanonSecurityModel
target_context:
included_concepts:
required_relationships:
required_metadata:
state_model:
source_of_truth_rules:
mapping_files:
validation_rules:
examples:
known_deviations:
```

---

## 15.2 Seed Profile: Small SaaS Security Profile

Purpose:

```text
Provide a minimal security model for a small SaaS platform moving toward production readiness.
```

Included concepts:

```text
SecurityDomain
ProtectedAssetReference
SecurityFinding
VulnerabilityFinding
MisconfigurationFinding
ExposureFinding
Mitigation
SecurityIncident
SecurityEvidence
SecurityReview
SecurityPosture
```

Required relationships:

```text
SecurityFinding affects ProtectedAssetReference
VulnerabilityFinding maps_to CVE where available
MisconfigurationFinding violates SecurityExpectation
ExposureFinding exposes Endpoint
Mitigation mitigates SecurityFinding
SecurityIncident affects Service
SecurityEvidence evidences SecurityFinding
RemediationTask remediates SecurityFinding
```

---

## 15.3 Seed Profile: Vulnerability Management Profile

Purpose:

```text
Represent vulnerability findings from scanners, advisories, SBOM analysis, and runtime context.
```

Included concepts:

```text
Vulnerability
Weakness
VulnerabilityFinding
AffectedComponent
Severity
ExploitLikelihood
Exploitability
FixVersion
Workaround
Mitigation
RemediationTask
VerificationEvidence
```

Required relationships:

```text
VulnerabilityFinding affects Artifact
Vulnerability maps_to CVE
Weakness maps_to CWE
Severity maps_to CVSS
ExploitLikelihood maps_to EPSS
RemediationTask fixes VulnerabilityFinding
Evidence verifies Remediation
```

---

## 15.4 Seed Profile: Threat-Informed Defense Profile

Purpose:

```text
Map adversary tactics, techniques, detections, and mitigations.
```

Included concepts:

```text
ThreatActor
Tactic
AttackTechnique
DetectionRule
DetectionCoverage
Mitigation
SecuritySignal
Alert
Investigation
```

Required relationships:

```text
ThreatActor uses_technique AttackTechnique
AttackTechnique maps_to Tactic
DetectionRule detects AttackTechnique
Mitigation mitigates AttackTechnique
Alert generated_by DetectionRule
Investigation investigates Alert
```

---

## 15.5 Seed Profile: Application Security Profile

Purpose:

```text
Represent application security requirements, findings, reviews, and assurance.
```

Included concepts:

```text
ApplicationSecurityRequirementReference
SecurityReview
CodeSecurityFinding
DependencyFinding
AuthenticationFinding
AuthorizationFinding
InputValidationFinding
DataProtectionFinding
SecurityTestEvidence
```

Mapping targets:

```text
OWASP ASVS
OWASP Top 10
OWASP SAMM
CWE
SAST / DAST / SCA tool schemas
```

---

## 15.6 Seed Profile: Supply Chain Security Profile

Purpose:

```text
Represent security posture across dependencies, builds, artifacts, SBOMs, provenance, signatures, and deployments.
```

Included concepts:

```text
SupplyChainFinding
DependencyFinding
ArtifactFinding
ProvenanceFinding
SignatureFinding
SBOMEvidence
AttestationEvidence
BuildSystemExposure
RepositoryExposure
```

Required relationships:

```text
SupplyChainFinding affects Artifact
SupplyChainFinding evidenced_by SBOM
Artifact deployed_to RuntimeWorkload
RuntimeWorkload part_of Service
Mitigation applies_to Pipeline
```

---

## 15.7 Seed Profile: Identity Security Profile

Purpose:

```text
Represent identity and access related security findings and attack paths.
```

Included concepts:

```text
IdentityFinding
CredentialExposure
ExcessPrivilegeFinding
OrphanedAccountFinding
StaleAccessFinding
PrivilegeEscalationPath
AgentAccessFinding
```

Required relationships:

```text
IdentityFinding affects Principal
CredentialExposure exposes CredentialReference
PrivilegeEscalationPath traverses AccessGrant
ExcessPrivilegeFinding remediated_by AccessRemediationTask
```

---

## 15.8 Seed Profile: Security Incident Response Profile

Purpose:

```text
Represent security incident lifecycle and response work.
```

Included concepts:

```text
SecuritySignal
Detection
Alert
SecurityIncident
Investigation
Containment
Eradication
Recovery
LessonLearned
IncidentEvidence
PostIncidentReview
```

Required relationships:

```text
Alert triggers Investigation
Investigation confirms SecurityIncident
Containment contains SecurityIncident
Eradication eradicates Cause
Recovery restores Service
LessonLearned creates Task
PostIncidentReview reviews SecurityIncident
```

---

# 16. Mapping Model for the Security Standard

Mappings relate InfoTechCanon security concepts to external standards, frameworks, taxonomies, and products.

## 16.1 Mapping Types

Recommended mapping types:

```text
exactMatch
closeMatch
broadMatch
narrowMatch
relatedMatch
conflictMatch
gapMatch
derivedFrom
regulatoryReference
toolEquivalent
```

## 16.2 Mapping Record

Example:

```yaml
id: itc-map:vulnerability-to-cve
source_concept: itc-sec:Vulnerability
target_body: CVE
target_version: "current"
target_concept: CVE Record / CVE Identifier
mapping_type: closeMatch
scope:
  - publicly known vulnerabilities and exposures
not_valid_for:
  - internal-only misconfigurations
  - generic weakness classes
  - findings without public vulnerability identifier
rationale: >
  CVE identifies publicly known vulnerabilities and exposures, while InfoTechCanon
  Vulnerability also covers internally identified vulnerabilities that may not have a CVE.
confidence: high
status: candidate
owner: InfoTechCanonSecurityModel
```

## 16.3 Seed Mapping Targets

The Security Model SHOULD maintain mappings to:

```text
NIST CSF 2.0
MITRE ATT&CK
MITRE CAPEC
CVE
CWE
CVSS v4.0
EPSS
CISA KEV
OWASP ASVS
OWASP SAMM
OWASP Top 10
ISO/IEC 27001 / 27002
CIS Controls
CSA Cloud Controls Matrix
SLSA
SPDX / CycloneDX security and vulnerability data
OpenSSF Scorecard
OSV
GitHub Security Advisories
SIEM / detection rule formats
Cloud security posture management schemas
Container and Kubernetes security benchmarks
```

---

# 17. Assimilation Hooks

The Security Model SHALL be able to receive new security standards, frameworks, tools, products, and research through the InfoTechCanon assimilation process.

## 17.1 Assimilation Triggers

Assimilation may be triggered by:

```text
new security framework
new vulnerability taxonomy
new threat intelligence source
new scanner schema
new incident-response model
new application-security standard
new supply-chain security standard
new cloud security benchmark
new security product integration
new recurring security classification conflict
```

## 17.2 Security Assimilation Output

A security assimilation SHOULD produce:

```text
source summary
extracted security concepts
concept comparison matrix
gap list
conflict list
mapping file
candidate new concepts
candidate relationship changes
candidate pattern changes
candidate profile changes
open questions
```

## 17.3 Recommended First Assimilation Candidates

```text
NIST CSF 2.0
MITRE ATT&CK
CVE / CWE / CVSS / EPSS
OWASP ASVS
OWASP SAMM
CIS Controls
ISO/IEC 27001 Annex A
SLSA
OpenSSF Scorecard
Kubernetes CIS Benchmark
```

---

# 18. Integration with Other InfoTechCanon Standards

## 18.1 Governance Model

Security imports governance concepts for:

```text
policy
control objective
control
risk
exception
evidence
assurance
review
audit
compliance requirement
```

## 18.2 Access Control Model

Security imports access concepts for:

```text
principal
permission
privilege
grant
access session
access review
authorization decision
break-glass access
agent access
```

## 18.3 Landscape Model

Security applies to landscape concepts such as:

```text
service
repository
artifact
pipeline
runtime resource
endpoint
network path
dataset
environment
platform
tenant
```

## 18.4 Task Model

Security creates or references tasks such as:

```text
remediation task
incident task
investigation task
security review task
hardening task
verification task
```

## 18.5 Tagging Standard

Security uses tags for:

```text
severity
security domain
finding type
threat technique
exposure type
remediation priority
assurance status
```

Tags must not replace findings, risks, controls, or evidence.

## 18.6 DevSecOps Model

Security imports DevSecOps concepts for:

```text
repository
commit
pipeline run
artifact
SBOM
attestation
release
deployment
policy gate
```

---

# 19. Canon Interface Card Usage

Subsystems that implement or produce security knowledge SHOULD publish a Canon Interface Card.

Example:

```yaml
subsystem: vulnerability-scanner-importer
implements:
  - InfoTechCanonSecurityModel
  - VulnerabilityManagementProfile
produces:
  - VulnerabilityFinding
  - Severity
  - Exploitability
  - SecurityEvidence
consumes:
  - Artifact
  - RuntimeWorkload
  - Repository
  - SBOM
relations:
  - VulnerabilityFinding affects Artifact
  - VulnerabilityFinding maps_to CVE
  - RemediationTask fixes VulnerabilityFinding
source_of_truth:
  scanner_results: scanner
known_deviations:
  - exploit likelihood is not provided by scanner
  - runtime reachability must be enriched from landscape model
```

---

# 20. Retrieval Requirements

The Security Model is designed for markdown-based infospaces.

## 20.1 Required Retrieval Properties

Every major concept SHOULD provide:

- stable heading,
- stable identifier,
- short definition,
- longer explanation,
- examples,
- distinction notes,
- relationship examples,
- mapping hooks,
- profile references,
- and common mistakes.

## 20.2 Agent Brief

A mature Security Model SHOULD include an `agent-brief.md` file with:

```text
purpose
scope
owned concepts
imported concepts
core distinctions
do / do not rules
relationship patterns
minimal examples
common mistakes
profile list
mapping list
```

## 20.3 Indexes

The security information space SHOULD provide indexes by:

```text
concept
relationship
security domain
finding type
threat technique
vulnerability identifier
weakness identifier
affected asset
mitigation
incident state
profile
pattern
mapping target
status
source system
```

---

# 21. Conformance Levels

## 21.1 Reference-Conformant

A document or system is reference-conformant if it uses Security Model terminology consistently but does not implement structured metadata or validation rules.

## 21.2 Metadata-Conformant

A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types.

## 21.3 Relationship-Conformant

A system is relationship-conformant if it represents findings, vulnerabilities, exposures, mitigations, attack paths, incidents, detections, and evidence as explicit relationships.

## 21.4 Evidence-Conformant

A system is evidence-conformant if security claims, findings, incident states, and mitigations can be linked to evidence.

## 21.5 Context-Conformant

A system is context-conformant if security prioritization can reference affected assets, exposure, exploitability, criticality, compensating controls, and remediation state.

## 21.6 Profile-Conformant

A system is profile-conformant if it implements a declared Security Profile and passes its validation rules.

## 21.7 Assimilation-Conformant

A system or repository is assimilation-conformant if it can accept external security concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes.

---

# 22. Validation Rules

Initial validation rules:

```text
VAL-SEC-001: Weakness, Vulnerability, Exposure, Finding, and Risk SHOULD be modeled as distinct concepts.

VAL-SEC-002: VulnerabilityFinding SHOULD identify affected asset, source, severity or equivalent rating, confidence, and status when available.

VAL-SEC-003: CVE identifiers SHOULD be modeled as external mappings or references, not as the internal definition of Vulnerability.

VAL-SEC-004: CWE identifiers SHOULD map to Weakness, not Vulnerability.

VAL-SEC-005: CVSS or equivalent severity SHOULD NOT be treated as contextual risk without enrichment.

VAL-SEC-006: ExploitLikelihood SHOULD be modeled separately from Severity.

VAL-SEC-007: ExposureFinding SHOULD be allowed even when no CVE exists.

VAL-SEC-008: SecurityFinding SHOULD reference evidence or source system.

VAL-SEC-009: SecurityFinding SHOULD reference affected Landscape entity where possible.

VAL-SEC-010: RemediationTask SHOULD reference the finding or condition it remediates.

VAL-SEC-011: Security exceptions SHOULD reference Governance Exception or Waiver concepts.

VAL-SEC-012: AttackPath SHOULD include at least one affected asset, precondition, or attack step.

VAL-SEC-013: DetectionRule SHOULD reference the signal, technique, asset, or condition it is intended to detect.

VAL-SEC-014: SecurityIncident SHOULD reference affected service, asset, or scope when known.

VAL-SEC-015: SecurityPostureScore SHOULD be traceable to underlying evidence, findings, controls, or assumptions.

VAL-SEC-016: Imported external security concepts SHOULD be represented through mapping records rather than silently reused.

VAL-SEC-017: Profiles MUST NOT redefine canonical concepts. They may constrain them.

VAL-SEC-018: Tags MUST NOT replace security findings, risks, controls, or evidence.
```

---

# 23. Anti-Patterns

## 23.1 CVE Equals Risk

Treating a CVE score as complete risk without considering context.

## 23.2 Scanner Output as Truth

Assuming tool findings are complete, correct, and context-aware without evidence, confidence, or validation.

## 23.3 Finding Without Asset

Recording findings that cannot be connected to affected systems, artifacts, services, or data.

## 23.4 Severity as Priority

Using severity alone for remediation priority.

## 23.5 Vulnerability-Only Security

Ignoring exposure, misconfiguration, identity risk, detection gaps, and attack paths.

## 23.6 Permanent Risk Acceptance

Accepting security risk without scope, rationale, authority, compensating measure, expiry, or review.

## 23.7 Detection Without Coverage

Creating detection rules without mapping them to assets, techniques, signals, or threats.

## 23.8 Incident Without Lessons

Closing incidents without lessons learned, remediation, governance updates, or detection improvements.

## 23.9 Security Tags as Findings

Using labels such as `security` or `critical` without actual finding, risk, or evidence records.

## 23.10 Framework Subordination

Bending the internal model around one framework, scanner, or vendor schema.

---

# 24. Initial Repository Placement

Recommended repository layout:

```text
info-tech-canon/
  standards/
    security/
      InfoTechCanonSecurityModel.md
      agent-brief.md
      concepts/
      relationships/
      patterns/
      profiles/
      mappings/
      assimilation/
      examples/
      validation/
```

Seed files:

```text
standards/security/InfoTechCanonSecurityModel.md
standards/security/agent-brief.md
standards/security/concepts/threat.md
standards/security/concepts/weakness.md
standards/security/concepts/vulnerability.md
standards/security/concepts/exposure.md
standards/security/concepts/security-finding.md
standards/security/concepts/attack-path.md
standards/security/concepts/mitigation.md
standards/security/concepts/security-incident.md
standards/security/patterns/finding-to-remediation-trace.md
standards/security/patterns/vulnerability-context-enrichment.md
standards/security/patterns/attack-path-to-choke-point.md
standards/security/profiles/small-saas-security-profile.md
standards/security/profiles/vulnerability-management-profile.md
standards/security/profiles/threat-informed-defense-profile.md
standards/security/profiles/supply-chain-security-profile.md
standards/security/mappings/nist-csf.yaml
standards/security/mappings/mitre-attack.yaml
standards/security/mappings/cve-cwe-cvss-epss.yaml
standards/security/mappings/owasp.yaml
```

---

# 25. Roadmap

## Phase 1: Seed Stabilization

- Establish this standard as `InfoTechCanonSecurityModel`.
- Add seed concepts, relationship vocabulary, patterns, and profiles.
- Define validation rules.
- Align with Governance, Access Control, Landscape, Task, and Tagging.

## Phase 2: First Assimilations

Recommended first assimilations:

```text
NIST CSF 2.0
MITRE ATT&CK
CVE / CWE / CVSS / EPSS
OWASP ASVS
OWASP SAMM
CIS Controls
ISO/IEC 27001 Annex A
SLSA
OpenSSF Scorecard
Kubernetes CIS Benchmark
```

## Phase 3: Profile Maturation

- Mature Small SaaS Security Profile.
- Mature Vulnerability Management Profile.
- Mature Threat-Informed Defense Profile.
- Mature Application Security Profile.
- Mature Supply Chain Security Profile.
- Mature Identity Security Profile.
- Mature Incident Response Profile.

## Phase 4: Tooling Integration

- Generate concept indexes.
- Generate agent brief.
- Create machine-readable YAML/JSON exports.
- Add validation scripts.
- Integrate scanner results, SBOMs, runtime context, access reviews, observability, and task systems.

## Phase 5: Security Intelligence Loop

- Connect findings to remediation tasks.
- Connect incidents to lessons learned.
- Connect attack paths to landscape graph.
- Connect security posture to governance risk and assurance.
- Connect detection coverage to threat techniques and observability signals.

---

# 26. Summary

The InfoTechCanon Security Model is the seed standard for representing cybersecurity posture, threat, vulnerability, exposure, finding, attack path, detection, incident, response, recovery, mitigation, and assurance semantics.

Its most important commitments are:

```text
Separate weakness, vulnerability, exposure, finding, risk, and incident.

Treat security context as essential for prioritization.

Model attack paths and exposure, not only CVEs.

Link findings to affected assets, evidence, remediation, mitigation, and verification.

Map to NIST CSF, MITRE ATT&CK, CVE, CWE, CVSS, EPSS, OWASP, and other frameworks
without surrendering internal semantic autonomy.

Import governance, access-control, task, tagging, and landscape concepts
instead of redefining them.

Use profiles to make the model practical for vulnerability management,
threat-informed defense, application security, supply-chain security,
identity security, and incident response.
```

This makes the Security Model a core seed for production readiness, security posture management, DevSecOps assurance, incident response, risk-informed prioritization, and agent-supported security operations.