icdev 1.0.0__py3-none-any.whl

icdev/data/docs/features/phase-23-universal-compliance-platform.md

@@ -0,0 +1,238 @@
+# Phase 23 — Universal Compliance Platform
+
+**CUI // SP-CTI**
+
+| Field | Value |
+|-------|-------|
+| Phase | 23 |
+| Title | Universal Compliance Platform |
+| Status | Implemented |
+| Priority | P1 |
+| Dependencies | Phase 17 (ATO Acceleration), Phase 20 (Security Categorization) |
+| Author | ICDEV Architect Agent |
+| Date | 2026-02-23 |
+
+---
+
+## 1. Problem Statement
+
+Government and regulated-industry software systems rarely operate under a single compliance framework. A DoD healthcare application must simultaneously satisfy NIST 800-53, FedRAMP, CMMC, HIPAA, and HITRUST. A law enforcement system requires CJIS on top of NIST 800-53 and FIPS 199/200. A financial services government contractor needs PCI DSS, SOC 2, ISO 27001, and FedRAMP. Assessing each framework independently produces redundant work: AC-2 (Account Management) in NIST 800-53 maps to nearly identical requirements in FedRAMP, CMMC, HIPAA, SOC 2, and ISO 27001. Without crosswalk deduplication, organizations implement the same control multiple times under different names.
+
+Prior phases built individual framework assessors (NIST 800-53, FedRAMP, CMMC), but each operated in isolation. There was no mechanism to detect which frameworks apply based on the data a system processes, no composable data markings (a file containing both CUI and PHI needed two separate marking systems), and no multi-regime assessment that deduplicates effort through a crosswalk engine. The result was manual compliance mapping, missed framework applicability, and inconsistent assessment results across frameworks.
+
+The Universal Compliance Platform introduces a dual-hub crosswalk model (NIST 800-53 as the US hub, ISO 27001 as the international hub, connected by a bidirectional bridge), composable data classification markings supporting 10 data categories, automatic framework detection based on data types, and a BaseAssessor abstract pattern that reduces new framework implementation to approximately 60 lines of code. Six Wave 1 frameworks (CJIS, HIPAA, HITRUST, SOC 2, PCI DSS, ISO 27001) join the existing NIST 800-53, FedRAMP, and CMMC assessors to deliver unified multi-regime compliance from a single assessment run.
+
+---
+
+## 2. Goals
+
+1. Implement **composable data classification markings** supporting 10 data categories (CUI, PHI, PCI, CJIS, FTI, FERPA, Export Controlled, PII, Proprietary, Open Source) that can be combined on a single artifact
+2. Build a **dual-hub crosswalk engine** with NIST 800-53 as the US hub and ISO 27001 as the international hub, connected by a bidirectional bridge, so implementing a control at either hub cascades to all mapped frameworks
+3. Deliver **automatic framework detection** that recommends applicable compliance frameworks based on data types processed by the system, with advisory-only mode requiring ISSO confirmation (D110)
+4. Implement 6 Wave 1 framework assessors via the **BaseAssessor ABC pattern** (D116): CJIS, HIPAA, HITRUST, SOC 2, PCI DSS, ISO 27001
+5. Provide **multi-regime assessment with deduplication** that assesses N frameworks through a single unified NIST control set rather than N separate assessments
+6. Maintain **independently versioned framework catalogs** so updating one framework does not require changes to others
+7. Support a **multi-regime gate** that passes only when all applicable frameworks pass their individual gates
+8. Enable framework catalogs as a **marketplace asset type** for community contribution via Phase 22
+
+---
+
+## 3. Architecture
+
+### 3.1 Dual-Hub Crosswalk Model (D111)
+
+```
+                    US Hub                          International Hub
+              +----------------+                +-------------------+
+              | NIST 800-53    |<-- bridge -->  | ISO/IEC 27001     |
+              | Rev 5          |   (D111)       | :2022             |
+              +-------+--------+                +--------+----------+
+                      |                                  |
+        +-------------+-------------+          +---------+---------+
+        |             |             |          |         |         |
+   +---------+  +---------+  +---------+  +--------+ +--------+ +--------+
+   |FedRAMP  |  | CMMC    |  | CJIS    |  |HITRUST | |SOC 2   | |PCI DSS |
+   |Moderate |  | L2/L3   |  |Security |  |CSF v11 | |Type II | |v4.0    |
+   +---------+  +---------+  |Policy   |  +--------+ +--------+ +--------+
+                              +---------+
+                              |HIPAA    |
+                              |Security |
+                              +---------+
+```
+
+### 3.2 Composable Data Classification
+
+A single artifact can carry multiple data classification markings:
+```
+CUI // SP-CTI // HIPAA-PHI // PCI-CARDHOLDER
+```
+The highest-sensitivity category determines handling requirements. Classification manager generates composite banners and code headers automatically.
+
+### 3.3 BaseAssessor Pattern (D116)
+
+All assessors inherit from a common abstract base class providing:
+- Crosswalk integration (automatic cascade to mapped frameworks)
+- Gate evaluation (pass/fail with blocking conditions)
+- CLI interface (--json, --human, --gate flags)
+- Audit trail logging
+
+New framework implementation requires approximately 60 lines of code versus 400+ lines without the pattern.
+
+---
+
+## 4. Requirements
+
+### 4.1 Data Classification
+
+#### REQ-23-001: Composable Markings
+The system SHALL support composable data classification markings where a single artifact can carry CUI + PHI + PCI markings simultaneously, with the highest-sensitivity category determining handling.
+
+#### REQ-23-002: 10 Data Categories
+The system SHALL support 10 data categories: CUI, PHI, PCI, CJIS, FTI, FERPA, Export Controlled, PII, Proprietary, and Open Source.
+
+#### REQ-23-003: Composite Banners
+The system SHALL generate composite banners and code headers combining all applicable data categories for a given artifact.
+
+### 4.2 Framework Detection
+
+#### REQ-23-004: Auto-Detection
+The system SHALL automatically detect applicable compliance frameworks based on data types assigned to the project (e.g., PHI triggers HIPAA, PCI triggers PCI DSS).
+
+#### REQ-23-005: Advisory-Only Detection (D110)
+Compliance auto-detection SHALL be advisory only. The system recommends frameworks; the customer ISSO must confirm before gates enforce.
+
+#### REQ-23-006: Data Type to Framework Mapping
+The system SHALL use a declarative JSON mapping (`data_type_framework_map.json`) to drive all auto-detection rules, enabling new rules without code changes.
+
+### 4.3 Crosswalk Engine
+
+#### REQ-23-007: Dual-Hub Model
+The crosswalk engine SHALL use NIST 800-53 as the US hub and ISO 27001 as the international hub, with a bidirectional bridge connecting both.
+
+#### REQ-23-008: Cascade Implementation
+Implementing a control at either hub SHALL automatically cascade compliance status to all mapped frameworks via the crosswalk engine.
+
+#### REQ-23-009: Multi-Regime Deduplication
+Assessing N frameworks SHALL produce 1 unified NIST control set, not N separate assessments, eliminating redundant assessment work.
+
+### 4.4 Assessment
+
+#### REQ-23-010: Wave 1 Assessors
+The system SHALL implement assessors for 6 Wave 1 frameworks: CJIS Security Policy, HIPAA Security Rule, HITRUST CSF v11, SOC 2 Type II, PCI DSS v4.0, and ISO/IEC 27001:2022.
+
+#### REQ-23-011: BaseAssessor Pattern
+All assessors SHALL inherit from the BaseAssessor ABC (D116) providing crosswalk integration, gate evaluation, and CLI interface.
+
+#### REQ-23-012: Independent Catalog Versioning
+Each framework catalog SHALL be versioned independently, enabling updates to one framework without affecting others.
+
+---
+
+## 5. Database Schema
+
+### Tables
+
+| Table | Purpose |
+|-------|---------|
+| `data_classifications` | Per-project data category assignments |
+| `framework_applicability` | Which frameworks apply to which projects (detected + confirmed) |
+| `compliance_detection_log` | Auto-detection audit trail |
+| `crosswalk_bridges` | Inter-framework control mappings |
+| `framework_catalog_versions` | Independent version tracking per framework |
+| `cjis_assessments` | CJIS Security Policy assessment results |
+| `hipaa_assessments` | HIPAA Security Rule assessment results |
+| `hitrust_assessments` | HITRUST CSF v11 assessment results |
+| `soc2_assessments` | SOC 2 Type II assessment results |
+| `pci_dss_assessments` | PCI DSS v4.0 assessment results |
+| `iso27001_assessments` | ISO/IEC 27001:2022 assessment results |
+
+---
+
+## 6. Tools
+
+| Tool | Purpose |
+|------|---------|
+| `tools/compliance/universal_classification_manager.py` | Composable data markings, banners, code headers, auto-detect |
+| `tools/compliance/compliance_detector.py` | Auto-detect applicable frameworks from data types |
+| `tools/compliance/multi_regime_assessor.py` | Multi-framework assessment with crosswalk deduplication |
+| `tools/compliance/crosswalk_engine.py` | Dual-hub crosswalk queries and coverage analysis |
+| `tools/compliance/cjis_assessor.py` | CJIS Security Policy assessor |
+| `tools/compliance/hipaa_assessor.py` | HIPAA Security Rule assessor |
+| `tools/compliance/hitrust_assessor.py` | HITRUST CSF v11 assessor |
+| `tools/compliance/soc2_assessor.py` | SOC 2 Type II assessor |
+| `tools/compliance/pci_dss_assessor.py` | PCI DSS v4.0 assessor |
+| `tools/compliance/iso27001_assessor.py` | ISO/IEC 27001:2022 assessor |
+
+---
+
+## 7. Architecture Decisions
+
+| ID | Decision | Rationale |
+|----|----------|-----------|
+| D109 | Composable data markings: single artifact can carry CUI + PHI + PCI simultaneously | Real-world data often has overlapping classification requirements |
+| D110 | Compliance auto-detection is advisory only; ISSO must confirm before gates enforce | Prevents incorrect framework enforcement from automated heuristics |
+| D111 | Dual-hub crosswalk: NIST 800-53 (US) + ISO 27001 (international) with bidirectional bridge | Implement once at either hub, cascade everywhere; covers both domestic and international frameworks |
+| D112 | Framework catalogs versioned independently | Update one framework without touching others |
+| D113 | Multi-regime deduplication via crosswalk: N frameworks produce 1 unified NIST control set | Eliminates redundant assessment of identical controls under different names |
+| D114 | Compliance framework as marketplace asset type | Community-contributed framework catalogs can be shared via Phase 22 |
+| D115 | Data type to framework mapping is declarative JSON | Add new detection rules without code changes |
+| D116 | BaseAssessor ABC pattern: all assessors inherit from base class with crosswalk, gate, CLI | ~60 LOC per new framework versus ~400+ LOC without the pattern |
+
+---
+
+## 8. Security Gate
+
+**Multi-Regime Gate:**
+- All applicable frameworks must pass their individual gates
+- Overall pass requires 0 framework failures across all detected regimes
+
+**HIPAA Gate:**
+- 0 not_satisfied on Administrative/Technical Safeguards
+- Encryption FIPS 140-2 required for PHI
+
+**PCI DSS Gate:**
+- 0 not_satisfied on Requirements 3-4 (data protection), 6 (secure development), 10 (logging)
+
+**CJIS Gate:**
+- 0 not_satisfied on Policy Areas 4 (audit), 5 (access control), 6 (identification), 10 (encryption)
+
+---
+
+## 9. Commands
+
+```bash
+# Data classification management
+python tools/compliance/universal_classification_manager.py --list-categories
+python tools/compliance/universal_classification_manager.py --banner CUI PHI --json
+python tools/compliance/universal_classification_manager.py --code-header CUI PCI --language python
+python tools/compliance/universal_classification_manager.py --detect --project-id "proj-123" --json
+python tools/compliance/universal_classification_manager.py --add-category \
+  --project-id "proj-123" --category PHI
+python tools/compliance/universal_classification_manager.py --validate \
+  --project-id "proj-123" --json
+
+# Framework detection
+python tools/compliance/compliance_detector.py --project-id "proj-123" --json
+python tools/compliance/compliance_detector.py --project-id "proj-123" --apply --json
+python tools/compliance/compliance_detector.py --project-id "proj-123" --confirm --json
+
+# Multi-regime assessment
+python tools/compliance/multi_regime_assessor.py --project-id "proj-123" --json
+python tools/compliance/multi_regime_assessor.py --project-id "proj-123" --gate
+python tools/compliance/multi_regime_assessor.py --project-id "proj-123" \
+  --minimal-controls --json
+
+# Individual framework assessments
+python tools/compliance/cjis_assessor.py --project-id "proj-123" --json
+python tools/compliance/hipaa_assessor.py --project-id "proj-123" --json
+python tools/compliance/hitrust_assessor.py --project-id "proj-123" --json
+python tools/compliance/soc2_assessor.py --project-id "proj-123" --json
+python tools/compliance/pci_dss_assessor.py --project-id "proj-123" --json
+python tools/compliance/iso27001_assessor.py --project-id "proj-123" --json
+
+# Crosswalk queries
+python tools/compliance/crosswalk_engine.py --control AC-2
+python tools/compliance/crosswalk_engine.py --project-id "proj-123" --coverage
+python tools/compliance/crosswalk_engine.py --project-id "proj-123" \
+  --target fedramp-moderate --gap-analysis
+```

icdev/data/docs/features/phase-24-devsecops-pipeline-security.md

@@ -0,0 +1,198 @@
+# Phase 24 — DevSecOps Pipeline Security
+
+**CUI // SP-CTI**
+
+| Field | Value |
+|-------|-------|
+| Phase | 24 |
+| Title | DevSecOps Pipeline Security |
+| Status | Implemented |
+| Priority | P1 |
+| Dependencies | Phase 14 (Requirements Intake), Phase 17 (ATO Acceleration) |
+| Author | ICDEV Architect Agent |
+| Date | 2026-02-23 |
+
+---
+
+## 1. Problem Statement
+
+Most DevSecOps failures stem from mismatched tooling: immature teams get overwhelmed by enterprise-grade security pipelines, while mature teams are held back by starter configurations. A one-size-fits-all pipeline approach forces every project through the same scanning stages regardless of organizational readiness, leading to alert fatigue at the low end and inadequate coverage at the high end. Without profile-driven generation, teams either disable security stages they cannot operate or accept a default configuration that does not match their actual maturity.
+
+Prior to this phase, ICDEV generated the same security pipeline for every project. There was no maturity model, no auto-detection of existing CI/CD tooling during requirements intake, no policy-as-code generation, and no attestation/signing workflow. Projects at DevSecOps Level 1 received the same gate configuration as projects at Level 5, creating friction and false confidence. IL6/SECRET projects lacked enforced minimum maturity floors, and air-gapped environments had no mechanism to restrict pipeline tooling to locally available scanners.
+
+Phase 24 introduces per-project DevSecOps profiles that control all downstream pipeline and infrastructure generation. Profiles are auto-detected during RICOAS intake from CI/CD tooling mentions, security scanner references, container orchestration signals, and compliance framework indicators. A 5-level maturity model (Basic through Optimizing) calibrates scanning stages, gate enforcement, policy-as-code generation (Kyverno/OPA), and image signing/attestation to what the organization can actually operate, with maturity evolving over time as capabilities grow.
+
+---
+
+## 2. Goals
+
+1. **Auto-detect DevSecOps signals** during conversational intake (RICOAS) including CI/CD platforms, existing security scanners, container orchestration, policy engines, and attestation tools
+2. Create **per-project DevSecOps profiles** that capture maturity level, pipeline stages, policy engine, attestation configuration, and gate thresholds
+3. Implement a **5-level maturity model** (Basic, Managed, Defined, Measured, Optimizing) with dimension scoring across CI/CD automation, security scanning, policy enforcement, supply chain, and monitoring
+4. Generate **profile-driven CI/CD pipeline security stages** as platform-specific YAML (GitLab CI, GitHub Actions, Jenkins) calibrated to the project's maturity level
+5. Generate **policy-as-code** (Kyverno or OPA/Gatekeeper) admission policies with NIST 800-53 control mappings
+6. Configure **image signing and SBOM attestation** (cosign) for Level 3+ projects with KMS or local key management
+7. Integrate DevSecOps-specific **security gates** with the existing ICDEV gate framework, additive to existing project gates
+8. Require **ISSO review and confirmation** before any profile becomes active
+
+---
+
+## 3. Architecture
+
+### 3.1 Profile-Driven Pipeline Generation
+
+```
+Intake Session (RICOAS)
+  |
+  v
+Signal Detection (CI/CD, scanners, orchestration, policy, attestation)
+  |
+  v
+DevSecOps Profile Creation (maturity level, stages, gates)
+  |
+  +---> Pipeline Security YAML (platform-specific: GitLab/GitHub/Jenkins)
+  |
+  +---> Policy-as-Code (Kyverno or OPA manifests)
+  |
+  +---> Attestation Config (cosign + KMS or local keys)
+  |
+  +---> Gate Configuration (merged with project security gates)
+  |
+  v
+ISSO Review & Confirmation
+  |
+  v
+Active Profile (drives all downstream generation)
+```
+
+### 3.2 Maturity Level to Stage Mapping
+
+| Stage | Level 1 | Level 2 | Level 3 | Level 4 | Level 5 |
+|-------|---------|---------|---------|---------|---------|
+| SAST | bandit | bandit + ruff | + semgrep | + Fortify | + custom rules |
+| SCA | pip-audit | pip-audit + SBOM | + license check | + transitive | + auto-remediate |
+| Secrets | detect-secrets | detect-secrets | + git history | + rotation alerts | + auto-rotate |
+| Container | -- | trivy (warn) | trivy (block) | + distroless | + runtime scan |
+| DAST | -- | -- | -- | OWASP ZAP | + auth scanning |
+| Image Signing | -- | -- | cosign (warn) | cosign (enforce) | + SLSA Level 3 |
+| SBOM Attestation | -- | -- | CycloneDX gen | + in-toto | + VEX generation |
+| Policy-as-Code | -- | -- | Kyverno basic | + custom policies | + mutation |
+| License Compliance | -- | -- | -- | SPDX check | + legal approval |
+
+---
+
+## 4. Requirements
+
+### 4.1 Signal Detection
+
+#### REQ-24-001: Intake Signal Detection
+The system SHALL detect DevSecOps signals during RICOAS conversational intake including CI/CD platform mentions, security scanner references, container orchestration indicators, policy-as-code keywords, and attestation tool references.
+
+#### REQ-24-002: Maturity Estimation
+The system SHALL estimate DevSecOps maturity level from detected signals with confidence scores, defaulting to Level 1 (Basic) when no CI/CD signals are detected.
+
+### 4.2 Profile Management
+
+#### REQ-24-003: Profile Schema
+The system SHALL maintain per-project DevSecOps profiles containing maturity level, CI/CD platform, pipeline stages, policy engine, attestation configuration, gate thresholds, and detected signals.
+
+#### REQ-24-004: 5-Level Maturity Assessment
+The system SHALL assess maturity across 5 dimensions (CI/CD automation, security scanning, policy enforcement, supply chain, monitoring/response) scored 0-100 with gap analysis and remediation roadmap.
+
+#### REQ-24-005: ISSO Confirmation
+The system SHALL require ISSO review and confirmation before a DevSecOps profile becomes active. Profile changes also require re-confirmation.
+
+### 4.3 Pipeline Generation
+
+#### REQ-24-006: Platform-Specific Output
+The system SHALL generate CI/CD pipeline security stages as valid platform-specific YAML for GitLab CI, GitHub Actions, or Jenkins based on the profile's CI/CD platform.
+
+#### REQ-24-007: Maturity-Calibrated Stages
+Pipeline stages SHALL be calibrated to the project's maturity level: Level 1-2 gets basic scanning, Level 3 adds policy and attestation, Level 4-5 adds DAST, runtime protection, and license compliance.
+
+### 4.4 Policy and Attestation
+
+#### REQ-24-008: Policy-as-Code Generation
+The system SHALL generate Kyverno or OPA/Gatekeeper admission policies for Level 3+ projects including deny-privileged, require-resource-limits, deny-latest-tag, require-readonly-rootfs, and CUI namespace isolation (IL4+).
+
+#### REQ-24-009: NIST Control Mapping
+Each generated policy SHALL map to at least one NIST 800-53 control (AC-6, CM-7, SC-7, SI-7).
+
+#### REQ-24-010: Attestation Configuration
+The system SHALL configure cosign image signing and CycloneDX SBOM attestation for Level 3+ projects with KMS key management (or local key pairs for air-gapped environments).
+
+### 4.5 Enforcement
+
+#### REQ-24-011: IL6 Minimum Floor
+IL6/SECRET projects SHALL enforce minimum Level 3 maturity regardless of detected level, with all critical gates enabled and attestation required.
+
+#### REQ-24-012: Air-Gapped Restrictions
+Air-gapped environments SHALL restrict tool selections to locally available scanners, disable Sigstore keyless mode, and set `air_gapped: true` in the profile.
+
+---
+
+## 5. Database Schema
+
+### Tables
+
+| Table | Purpose |
+|-------|---------|
+| `devsecops_profiles` | Per-project DevSecOps profile (maturity, stages, gates, signals) |
+| `devsecops_pipeline_audit` | Append-only pipeline execution and gate evaluation log |
+
+---
+
+## 6. Tools
+
+| Tool | Purpose |
+|------|---------|
+| `tools/devsecops/profile_manager.py` | Profile CRUD, maturity assessment, gate configuration, ISSO review |
+| `tools/devsecops/pipeline_security_generator.py` | Generate maturity-calibrated pipeline security YAML |
+| `tools/devsecops/policy_generator.py` | Generate Kyverno or OPA admission policies with control mappings |
+| `tools/devsecops/attestation_manager.py` | Configure cosign signing, SBOM attestation, key management |
+| `tools/mcp/devsecops_server.py` | MCP server for DevSecOps tools |
+
+---
+
+## 7. Architecture Decisions
+
+| ID | Decision | Rationale |
+|----|----------|-----------|
+| D117 | New DevSecOps/ZTA Agent (port 8457) with hard veto on pipeline, ZTA, deployment gate | Distributes security responsibility; hard veto prevents bypassing security pipeline |
+| D119 | DevSecOps profile is per-project YAML config in DB, detected during intake | Profile drives all downstream generation; detectable from conversation signals |
+| D120 | 5-level maturity model based on DoD DevSecOps reference design | Maturity grows over time; pipeline evolves with the organization |
+| D121 | Service mesh and policy engine are profile-selectable (Istio/Linkerd, Kyverno/OPA) | Both engines generated; customer picks based on existing infrastructure |
+| D122 | DevSecOps profile inherited by child apps from Phase 19 agentic generation | Children inherit parent's security posture, not a blank slate |
+
+---
+
+## 8. Security Gate
+
+**DevSecOps Gate:**
+- 0 critical policy-as-code violations
+- 0 missing image attestations (when attestation is active in profile)
+- 0 unresolved critical SAST findings
+- 0 detected secrets in pipeline artifacts
+
+---
+
+## 9. Commands
+
+```bash
+# Profile management
+python tools/devsecops/profile_manager.py --project-id "proj-123" --create \
+  --maturity level_3_defined --json
+python tools/devsecops/profile_manager.py --project-id "proj-123" --detect --json
+python tools/devsecops/profile_manager.py --project-id "proj-123" --assess --json
+python tools/devsecops/profile_manager.py --project-id "proj-123" --json
+
+# Pipeline generation
+python tools/devsecops/pipeline_security_generator.py --project-id "proj-123" --json
+
+# Policy-as-code
+python tools/devsecops/policy_generator.py --project-id "proj-123" --engine kyverno --json
+python tools/devsecops/policy_generator.py --project-id "proj-123" --engine opa --json
+
+# Attestation
+python tools/devsecops/attestation_manager.py --project-id "proj-123" --generate --json
+```

icdev/data/docs/features/phase-25-zero-trust-architecture.md

@@ -0,0 +1,220 @@
+# Phase 25 — Zero Trust Architecture
+
+**CUI // SP-CTI**
+
+| Field | Value |
+|-------|-------|
+| Phase | 25 |
+| Title | Zero Trust Architecture (NIST SP 800-207) |
+| Status | Implemented |
+| Priority | P1 |
+| Dependencies | Phase 20 (Security Categorization), Phase 24 (DevSecOps Pipeline Security) |
+| Author | ICDEV Architect Agent |
+| Date | 2026-02-23 |
+
+---
+
+## 1. Problem Statement
+
+Executive Order 14028 and the DoD Zero Trust Strategy mandate ZTA adoption for all federal information systems. Traditional perimeter-based security models assume that everything inside the network boundary is trusted, but modern threat actors routinely achieve initial access and then move laterally across trusted segments. The primary threat vector in government breaches is not the initial compromise but the unchecked lateral movement that follows. Without demonstrated ZTA maturity, IL4+ systems face ATO delays and risk acquisition milestone disapproval.
+
+Prior to this phase, ICDEV had no mechanism to assess a project's Zero Trust posture, score maturity across the seven DoD ZTA pillars, generate service mesh configurations for mTLS enforcement, produce network micro-segmentation policies, or integrate with external Policy Decision Points. Security assessments focused on traditional perimeter controls without addressing the assume-breach, verify-explicitly, least-privilege-access principles that ZTA requires. There was no way to feed ZTA posture evidence into the cATO monitoring pipeline for continuous authorization.
+
+Phase 25 implements NIST SP 800-207 compliance assessment across 28 requirements organized by the 7 DoD ZTA pillars, a 4-level maturity scoring model (Traditional through Optimal), service mesh generation (Istio/Linkerd) for workload-level mTLS, Kubernetes NetworkPolicy micro-segmentation, PDP/PEP integration configurations for 5 supported providers (DISA ICAM, Zscaler, Palo Alto, CrowdStrike, Microsoft Entra), ZTA-aligned Terraform security modules for AWS GovCloud, and continuous ZTA posture monitoring that feeds directly into the cATO evidence pipeline.
+
+---
+
+## 2. Goals
+
+1. Implement **NIST SP 800-207 compliance assessment** across 28 requirements organized by the 7 DoD Zero Trust pillars with automated requirement checking
+2. Score **ZTA maturity** across 7 pillars (User Identity, Device, Network, Application/Workload, Data, Visibility/Analytics, Automation/Orchestration) on a 4-level model (Traditional, Initial, Advanced, Optimal)
+3. Generate **service mesh configurations** (Istio or Linkerd) with STRICT mTLS, per-service AuthorizationPolicy, and egress restrictions
+4. Produce **network micro-segmentation** via Kubernetes NetworkPolicy with default-deny posture and per-service allow-list policies
+5. Generate **PDP/PEP integration configurations** for 5 supported external Policy Decision Point providers with fail-closed behavior on timeout
+6. Generate **ZTA-aligned Terraform security modules** for AWS GovCloud (GuardDuty, Security Hub, WAF, Config Rules, VPC Flow Logs, Secrets Rotation, KMS, CloudTrail)
+7. Integrate ZTA posture score as a **cATO evidence dimension** for continuous authorization readiness
+8. Provide **continuous ZTA posture monitoring** with freshness checks, pillar minimums, drift detection, and remediation roadmaps
+
+---
+
+## 3. Architecture
+
+### 3.1 7 DoD ZTA Pillars
+
+```
++-------------------------------------------------------------------+
+|                    Zero Trust Architecture                         |
+|                                                                   |
+|  +----------+  +--------+  +---------+  +------------+            |
+|  |  User    |  | Device |  | Network |  | App/       |            |
+|  | Identity |  |        |  |         |  | Workload   |            |
+|  | (0.20)   |  | (0.15) |  | (0.15)  |  | (0.15)     |            |
+|  +----------+  +--------+  +---------+  +------------+            |
+|                                                                   |
+|  +--------+  +-------------+  +----------------------+            |
+|  | Data   |  | Visibility  |  | Automation /         |            |
+|  |        |  | & Analytics |  | Orchestration        |            |
+|  | (0.15) |  | (0.10)      |  | (0.10)               |            |
+|  +--------+  +-------------+  +----------------------+            |
+|                                                                   |
+|  Maturity: Traditional (1) -> Initial (2) -> Advanced (3)         |
+|            -> Optimal (4)                                         |
++-------------------------------------------------------------------+
+        |               |               |
+        v               v               v
+  Service Mesh    Network Policy    PDP/PEP Config
+  (Istio/Linkerd) (K8s default-    (ext_authz +
+                   deny)            fail-closed)
+```
+
+### 3.2 Assessment and Scoring Flow
+
+```
+Project Metadata (type, IL, services)
+  |
+  v
+ZTA Requirement Detection (auto-detect applicability)
+  |
+  v
+NIST 800-207 Assessment (28 requirements / 7 pillars)
+  |
+  v
+ZTA Maturity Scoring (weighted aggregate + per-pillar)
+  |
+  +---> Service Mesh Generation (if multi-service)
+  +---> Network Segmentation (if K8s)
+  +---> PDP/PEP Configuration (if provider selected)
+  +---> Terraform ZTA Modules (if cloud)
+  |
+  v
+cATO Evidence Integration + Continuous Posture Monitoring
+```
+
+---
+
+## 4. Requirements
+
+### 4.1 Assessment
+
+#### REQ-25-001: NIST 800-207 Assessment
+The system SHALL assess all 28 ZTA requirements across the 7 DoD pillars plus core architecture principles (SDP, micro-segmentation, enhanced identity governance).
+
+#### REQ-25-002: ZTA Requirement Detection
+The system SHALL auto-detect ZTA applicability based on project type (microservice/API), impact level (IL4+ requires ZTA), data category, and architecture (>3 services or cross-boundary flows).
+
+#### REQ-25-003: 4-Level Maturity Scoring
+The system SHALL score each pillar on a 4-level model (Traditional=1, Initial=2, Advanced=3, Optimal=4) with configurable weights and compute a weighted aggregate maturity score.
+
+### 4.2 Infrastructure Generation
+
+#### REQ-25-004: Service Mesh Generation
+The system SHALL generate Istio or Linkerd service mesh configurations with namespace-wide STRICT mTLS PeerAuthentication, per-service AuthorizationPolicy, and sidecar egress restrictions.
+
+#### REQ-25-005: Network Micro-Segmentation
+The system SHALL generate Kubernetes NetworkPolicy manifests with default-deny for every namespace, per-service allow-list policies, and DNS exception policies.
+
+#### REQ-25-006: PDP/PEP Configuration
+The system SHALL generate Policy Enforcement Point configurations for Envoy ext_authz integration with supported PDP providers (DISA ICAM, Zscaler, Palo Alto, CrowdStrike, Microsoft Entra), with fail-closed behavior on PDP timeout.
+
+#### REQ-25-007: ZTA Terraform Modules
+The system SHALL generate AWS GovCloud Terraform modules for GuardDuty, Security Hub, WAF v2, Config Rules, VPC Flow Logs, Secrets Rotation, KMS, and CloudTrail.
+
+### 4.3 Continuous Monitoring
+
+#### REQ-25-008: cATO Evidence Integration
+The system SHALL feed ZTA maturity scores into the cATO monitoring system as an additional evidence dimension with freshness tracking.
+
+#### REQ-25-009: Posture Monitoring
+The system SHALL provide continuous ZTA posture monitoring with aggregate maturity checks, pillar minimum validation, evidence freshness enforcement (30-day maximum), and drift detection from last assessment.
+
+#### REQ-25-010: Remediation Roadmap
+The system SHALL generate prioritized remediation actions for any pillar scoring below Advanced, with target PI milestones.
+
+---
+
+## 5. Database Schema
+
+### Tables
+
+| Table | Purpose |
+|-------|---------|
+| `zta_maturity_scores` | Per-project, per-pillar maturity scores with weighted aggregate |
+| `zta_posture_evidence` | ZTA posture snapshots for cATO evidence (timestamped) |
+| `nist_800_207_assessments` | Full 800-207 requirement assessment results |
+
+---
+
+## 6. Tools
+
+| Tool | Purpose |
+|------|---------|
+| `tools/compliance/nist_800_207_assessor.py` | NIST 800-207 assessment, detection, and posture monitoring |
+| `tools/devsecops/zta_maturity_scorer.py` | 7-pillar maturity scoring with weighted aggregate |
+| `tools/devsecops/service_mesh_generator.py` | Istio/Linkerd service mesh config generation |
+| `tools/devsecops/network_segmentation_generator.py` | K8s NetworkPolicy micro-segmentation |
+| `tools/devsecops/pdp_config_generator.py` | PDP/PEP configuration for 5 providers |
+| `tools/devsecops/zta_terraform_generator.py` | AWS GovCloud ZTA Terraform modules |
+| `tools/compliance/cato_monitor.py` | cATO evidence integration (extended for ZTA) |
+
+---
+
+## 7. Architecture Decisions
+
+| ID | Decision | Rationale |
+|----|----------|-----------|
+| D118 | NIST 800-207 maps into existing NIST 800-53 US hub (not a third hub) | ZTA is an architecture guide; requirements crosswalk to AC-2, AC-3, SA-3, SC-7, SI-4, AU-2 |
+| D120 | ZTA maturity model uses DoD 7-pillar scoring (Traditional to Optimal) | Aligns with DoD Zero Trust Strategy official maturity framework |
+| D121 | Service mesh and policy engine are profile-selectable (Istio/Linkerd) | Both generated; customer picks based on existing infrastructure |
+| D123 | ZTA posture score feeds into cATO monitor as additional evidence dimension | Continuous authorization requires continuous posture evidence |
+| D124 | PDP modeled as external reference (Zscaler, Palo Alto, DISA ICAM) | ICDEV generates PEP configs but does not implement PDP itself |
+
+---
+
+## 8. Security Gate
+
+**ZTA Gate:**
+- ZTA maturity >= Advanced (0.34) for IL4+ projects
+- mTLS enforced when service mesh is active (STRICT PeerAuthentication)
+- Default-deny NetworkPolicy required for every namespace
+- No pillar at 0.0 (Traditional without any evidence)
+- PEP fails closed on PDP timeout (no allow-by-default fallback)
+- ZTA posture evidence less than 30 days old for cATO
+- 0 critical requirements "not_satisfied" without documented risk acceptance
+
+---
+
+## 9. Commands
+
+```bash
+# ZTA maturity scoring
+python tools/devsecops/zta_maturity_scorer.py --project-id "proj-123" --all --json
+python tools/devsecops/zta_maturity_scorer.py --project-id "proj-123" \
+  --pillar user_identity --json
+python tools/devsecops/zta_maturity_scorer.py --project-id "proj-123" --trend --json
+
+# NIST 800-207 assessment
+python tools/compliance/nist_800_207_assessor.py --project-id "proj-123" --json
+python tools/compliance/nist_800_207_assessor.py --project-id "proj-123" --gate
+
+# Service mesh generation
+python tools/devsecops/service_mesh_generator.py --project-id "proj-123" \
+  --mesh istio --json
+python tools/devsecops/service_mesh_generator.py --project-id "proj-123" \
+  --mesh linkerd --json
+
+# Network segmentation
+python tools/devsecops/network_segmentation_generator.py --project-path /path \
+  --namespaces "app,data" --json
+python tools/devsecops/network_segmentation_generator.py --project-path /path \
+  --services "api,db" --json
+
+# PDP/PEP configuration
+python tools/devsecops/pdp_config_generator.py --project-id "proj-123" \
+  --pdp-type disa_icam --json
+python tools/devsecops/pdp_config_generator.py --project-id "proj-123" \
+  --pdp-type zscaler --mesh istio --json
+
+# ZTA Terraform modules
+python tools/devsecops/zta_terraform_generator.py --project-path /path \
+  --modules all --json
+```