icdev 0.0.3__py3-none-any.whl

context/compliance/ivv_checklist_template.md

@@ -0,0 +1,80 @@
+{{cui_banner_top}}
+
+# IV&V Verification Checklist
+
+**Project:** {{project_name}}
+**Project ID:** {{project_id}}
+**Classification:** {{classification}}
+**Assessment Date:** {{assessment_date}}
+**IV&V Authority:** {{ivv_authority}}
+**Framework:** IEEE 1012-2016, DoDI 5000.87, DoDI 8510.01
+
+---
+
+## Independence Declaration
+
+This verification and validation assessment is conducted independently from the development team per IEEE 1012 requirements. The IV&V engine operates with separate assessment criteria, tools, and authority to gate releases.
+
+---
+
+## Process Area Checklists
+
+### 1. Requirements Verification (REQ)
+- [ ] IVV-01: Requirements documented (requirements.md, user stories, .feature files)
+- [ ] IVV-02: Requirements consistent (no conflicts between features)
+- [ ] IVV-03: Requirements testable (each has corresponding test case)
+- [ ] IVV-04: Requirements traced (RTM links requirements to design, code, tests)
+
+### 2. Design Verification (DES)
+- [ ] IVV-05: Architecture documented (architecture.md, ADR, system design)
+- [ ] IVV-06: Threat model reviewed (STRIDE/PASTA analysis)
+- [ ] IVV-07: Security patterns followed (defense in depth, least privilege)
+
+### 3. Code Verification (CODE)
+- [ ] IVV-08: Independent SAST completed (scan results available)
+- [ ] IVV-09: Coding standards enforced (linter/formatter configured)
+- [ ] IVV-10: Code reviews completed and approved
+- [ ] IVV-11: Complexity metrics within thresholds
+
+### 4. Test Verification (TEST)
+- [ ] IVV-12: Test coverage >= 80% for critical systems
+- [ ] IVV-13: Test plan documented or structured tests/ directory
+- [ ] IVV-14: Security test cases present
+- [ ] IVV-15: BDD features have step implementations
+
+### 5. Integration Verification (INT)
+- [ ] IVV-16: Interface tests verify module interactions
+- [ ] IVV-17: End-to-end tests exist
+- [ ] IVV-18: API contract tests in place
+
+### 6. Traceability Analysis (RTM)
+- [ ] IVV-19: Requirements Traceability Matrix exists
+- [ ] IVV-20: Bidirectional traceability (forward + backward)
+- [ ] IVV-21: Gap analysis completed (untested reqs, orphan tests)
+
+### 7. Security Verification (SEC)
+- [ ] IVV-22: Independent security assessment conducted
+- [ ] IVV-23: Penetration test results available
+- [ ] IVV-24: Critical/high vulnerabilities remediated
+
+### 8. Build/Deploy Verification (BLD)
+- [ ] IVV-25: CI/CD pipeline includes security stages
+- [ ] IVV-26: Build artifacts have SBOM/checksums
+- [ ] IVV-27: Containers STIG-hardened
+- [ ] IVV-28: Rollback mechanism verified
+
+### 9. Process Compliance (PROC)
+- [ ] IVV-29: TDD adherence verified (tests before code)
+- [ ] IVV-30: All security/compliance gates passed
+
+---
+
+## Summary
+
+**Total Requirements:** 30
+**Verified:** {{verified_count}}
+**Failed:** {{failed_count}}
+**Deferred:** {{deferred_count}}
+**Not Assessed:** {{not_assessed_count}}
+
+{{cui_banner_bottom}}

context/compliance/ivv_report_template.md

@@ -0,0 +1,116 @@
+{{cui_banner_top}}
+
+# Independent Verification & Validation (IV&V) Certification Report
+
+**Project:** {{project_name}}
+**Project ID:** {{project_id}}
+**Classification:** {{classification}}
+**Assessment Date:** {{assessment_date}}
+**Report Version:** {{version}}
+**IV&V Authority:** {{ivv_authority}}
+**Framework:** IEEE 1012-2016, DoDI 5000.87
+
+---
+
+## 1. Executive Summary
+
+**Verification Score:** {{verification_score}}%
+**Validation Score:** {{validation_score}}%
+**Overall IV&V Score:** {{overall_score}}%
+**Gate Result:** {{gate_result}}
+**Certification Recommendation:** {{certification_recommendation}}
+
+{{executive_summary}}
+
+## 2. Independence Declaration
+
+This Independent Verification and Validation assessment was conducted separately from the development team per IEEE 1012 and DoD requirements. The IV&V engine operates with:
+- **Organizational Independence:** Separate assessment authority from development
+- **Technical Independence:** Independent analysis tools and criteria
+- **Financial Independence:** Assessment budget separate from development
+- **Authority:** Gate authority to block releases based on findings
+
+## 3. Verification Results
+
+Verification ("Are we building the product right?") evaluates process compliance across 8 process areas.
+
+### 3.1 Process Area Scores
+
+{{process_area_scores_table}}
+
+### 3.2 Process Area Details
+
+{{process_area_details}}
+
+## 4. Validation Results
+
+Validation ("Are we building the right product?") evaluates outcome correctness.
+
+### 4.1 Test Verification Results
+{{test_verification_results}}
+
+### 4.2 Integration Verification Results
+{{integration_verification_results}}
+
+## 5. Requirements Traceability Matrix Summary
+
+{{rtm_summary}}
+
+**RTM Coverage:** {{rtm_coverage}}%
+**Requirements with Full Trace:** {{rtm_full_trace_count}}
+**Requirements with Gaps:** {{rtm_gap_count}}
+**Orphan Tests:** {{rtm_orphan_tests}}
+
+## 6. IV&V Findings
+
+### 6.1 Critical Findings
+{{critical_findings}}
+
+### 6.2 High Findings
+{{high_findings}}
+
+### 6.3 Moderate Findings
+{{moderate_findings}}
+
+### 6.4 Low Findings
+{{low_findings}}
+
+### 6.5 Findings Summary
+| Severity | Open | Resolved | Accepted Risk | Deferred | Total |
+|----------|------|----------|---------------|----------|-------|
+{{findings_summary_table}}
+
+## 7. Certification Recommendation
+
+**Recommendation:** {{certification_recommendation}}
+
+### Criteria Applied:
+- **CERTIFY:** Overall score >= 80%, 0 critical findings, all process areas >= 60%
+- **CONDITIONAL:** Overall score >= 60%, 0 critical findings, conditions listed
+- **DENY:** Overall score < 60% OR critical findings unresolved
+
+### Conditions (if applicable):
+{{conditions}}
+
+## 8. Evidence Index
+
+{{evidence_index}}
+
+## 9. Assessment Methodology
+
+This assessment was conducted using the ICDEV IV&V Assessor tool against the IEEE 1012 requirements catalog (30 requirements across 9 process areas).
+
+**Scoring Formula:**
+- Verification Score = average of process area pass rates
+- Validation Score = average of Test + Integration area pass rates
+- Overall Score = 0.6 x Verification + 0.4 x Validation
+
+**Gate Logic:** PASS if 0 critical findings remain open
+
+---
+
+**Prepared by:** {{ivv_authority}}
+**Date:** {{assessment_date}}
+**Next Review:** {{next_review_date}}
+
+{{cui_banner_bottom}}

context/compliance/ivv_requirements.json

@@ -0,0 +1,372 @@
+{
+  "metadata": {
+    "title": "IV&V Requirements per IEEE 1012 and DoD Standards",
+    "source": "IEEE 1012-2016, DoDI 5000.87, DoDI 8510.01 (RMF), NIST 800-53 Rev 5",
+    "classification": "CUI // SP-CTI",
+    "version": "1.0",
+    "last_updated": "2026-02-15",
+    "description": "Requirements catalog for Independent Verification and Validation assessment across 9 process areas"
+  },
+  "requirements": [
+    {
+      "id": "IVV-01",
+      "process_area": "Requirements Verification",
+      "process_area_code": "REQ",
+      "title": "Requirements Completeness",
+      "description": "Verify that all functional and non-functional requirements are fully documented, including requirements.md, user stories, and .feature files. Every requirement must have a unique identifier, clear acceptance criteria, and an assigned priority. Incomplete or ambiguous requirements must be flagged for resolution before design and implementation proceed.",
+      "verification_type": "verification",
+      "evidence_required": "Requirements documentation (requirements.md), user story backlog, .feature files with scenarios, and a requirements completeness checklist showing all items addressed.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-3", "SA-15"],
+      "priority": "critical"
+    },
+    {
+      "id": "IVV-02",
+      "process_area": "Requirements Verification",
+      "process_area_code": "REQ",
+      "title": "Requirements Consistency",
+      "description": "Verify that no conflicting or contradictory requirements exist across the requirements corpus. Feature files must be consistent with test naming conventions and requirements identifiers. Cross-references between requirements documents must resolve correctly without circular dependencies or ambiguous references.",
+      "verification_type": "verification",
+      "evidence_required": "Consistency analysis report showing no conflicting requirements, feature file naming convention audit results, and cross-reference validation records.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-3"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-03",
+      "process_area": "Requirements Verification",
+      "process_area_code": "REQ",
+      "title": "Requirements Testability",
+      "description": "Verify that each documented requirement has at least one corresponding test case or BDD scenario. All .feature files must have corresponding step definition files that implement the scenarios. Requirements that cannot be tested must be documented with justification and alternative validation approaches.",
+      "verification_type": "verification",
+      "evidence_required": "Requirements-to-test mapping matrix, .feature files with corresponding step implementation files, and testability gap analysis for any untestable requirements.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-11", "SA-15"],
+      "priority": "critical"
+    },
+    {
+      "id": "IVV-04",
+      "process_area": "Requirements Verification",
+      "process_area_code": "REQ",
+      "title": "Requirements Traceability",
+      "description": "Verify that all requirements are traced bidirectionally through design artifacts, source code, and test cases in the Requirements Traceability Matrix (RTM). Each requirement must have a documented chain from origin through implementation to verification. Gaps in traceability must be identified and resolved.",
+      "verification_type": "verification",
+      "evidence_required": "Requirements Traceability Matrix (RTM) with bidirectional links, traceability gap report, and evidence of gap resolution actions.",
+      "automation_level": "semi",
+      "nist_controls": ["SA-11(1)"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-05",
+      "process_area": "Design Verification",
+      "process_area_code": "DES",
+      "title": "Architecture Documentation",
+      "description": "Verify that the system architecture is fully documented including architecture.md, system design documents, and Architecture Decision Records (ADR). Documentation must cover component interactions, data flows, deployment topology, and technology stack decisions. Architecture documentation must be current and reflect the implemented system.",
+      "verification_type": "verification",
+      "evidence_required": "Architecture documentation (architecture.md), system design documents, Architecture Decision Records (ADR), component interaction diagrams, and data flow diagrams.",
+      "automation_level": "auto",
+      "nist_controls": ["PL-8", "SA-8"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-06",
+      "process_area": "Design Verification",
+      "process_area_code": "DES",
+      "title": "Threat Model Review",
+      "description": "Verify that a threat model exists using an established methodology (STRIDE, PASTA, or equivalent) and covers all identified attack vectors with corresponding mitigations. The threat model must be reviewed for completeness against the system architecture and updated when significant design changes occur.",
+      "verification_type": "verification",
+      "evidence_required": "Threat model document with methodology identification, attack vector enumeration, mitigation mapping for each threat, and threat model review records with sign-off.",
+      "automation_level": "semi",
+      "nist_controls": ["RA-3", "SA-8"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-07",
+      "process_area": "Design Verification",
+      "process_area_code": "DES",
+      "title": "Security Pattern Compliance",
+      "description": "Verify that the system architecture follows approved security patterns including defense in depth, least privilege, separation of duties, and fail-secure defaults. Architecture decisions must demonstrate alignment with DoD and NIST security engineering principles. Deviations from approved patterns must be documented with risk acceptance.",
+      "verification_type": "verification",
+      "evidence_required": "Security pattern compliance checklist, architecture review findings mapped to security patterns, deviation documentation with risk acceptance, and security engineering principle alignment matrix.",
+      "automation_level": "semi",
+      "nist_controls": ["SA-8"],
+      "priority": "medium"
+    },
+    {
+      "id": "IVV-08",
+      "process_area": "Code Verification",
+      "process_area_code": "CODE",
+      "title": "Independent SAST",
+      "description": "Verify that static application security testing (SAST) has been performed independently from the development process using automated scanning tools. SAST results must be documented with findings categorized by severity. All critical and high findings must be remediated or have documented risk acceptance before release.",
+      "verification_type": "verification",
+      "evidence_required": "SAST scan reports from automated tools (Bandit, SonarQube, or equivalent), finding severity breakdown, remediation records for critical and high findings, and risk acceptance documentation for any open findings.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-11(1)"],
+      "priority": "critical"
+    },
+    {
+      "id": "IVV-09",
+      "process_area": "Code Verification",
+      "process_area_code": "CODE",
+      "title": "Coding Standards Compliance",
+      "description": "Verify that coding standards are enforced through linter and formatter configurations present in the project. Configuration files such as .flake8, .eslintrc, or pyproject.toml with ruff settings must be present and actively enforced in the CI/CD pipeline. Code must pass all configured linting rules without suppressed or ignored warnings on critical checks.",
+      "verification_type": "verification",
+      "evidence_required": "Linter and formatter configuration files (.flake8, .eslintrc, pyproject.toml, or equivalent), CI/CD pipeline stage showing lint enforcement, and clean lint report with no critical violations.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-15"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-10",
+      "process_area": "Code Verification",
+      "process_area_code": "CODE",
+      "title": "Code Review Completion",
+      "description": "Verify that all code changes have been reviewed and approved by at least one reviewer independent of the author, as recorded in the code_reviews table or version control system. Reviews must cover functionality, security implications, and compliance with coding standards. No code may be merged to the main branch without documented review approval.",
+      "verification_type": "verification",
+      "evidence_required": "Code review records from code_reviews table or version control system, reviewer approval timestamps, review comment resolution evidence, and merge gate compliance logs.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-11(4)"],
+      "priority": "critical"
+    },
+    {
+      "id": "IVV-11",
+      "process_area": "Code Verification",
+      "process_area_code": "CODE",
+      "title": "Complexity Metrics",
+      "description": "Verify that code complexity is measured and maintained within established thresholds using tools such as radon, McCabe complexity analyzers, or equivalent cyclomatic complexity measurement tools. Functions exceeding complexity thresholds must be refactored or documented with justification. Complexity metrics must be tracked over time to detect degradation.",
+      "verification_type": "verification",
+      "evidence_required": "Complexity analysis tool configuration (radon, McCabe, or equivalent), complexity measurement reports, threshold definitions, and exception documentation for functions exceeding thresholds.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-11"],
+      "priority": "medium"
+    },
+    {
+      "id": "IVV-12",
+      "process_area": "Test Verification",
+      "process_area_code": "TEST",
+      "title": "Test Coverage Adequacy",
+      "description": "Validate that code coverage meets or exceeds the 80% threshold for critical systems as demonstrated by coverage reports. Coverage must be measured for line, branch, and function metrics. Areas with coverage below threshold must be documented with justification or remediation plans. Coverage reports must be generated as part of the CI/CD pipeline.",
+      "verification_type": "validation",
+      "evidence_required": "Code coverage reports (pytest-cov, coverage.py, or equivalent) showing line, branch, and function coverage percentages, CI/CD pipeline stage generating coverage, and gap justification for areas below 80%.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-11(2)"],
+      "priority": "critical"
+    },
+    {
+      "id": "IVV-13",
+      "process_area": "Test Verification",
+      "process_area_code": "TEST",
+      "title": "Test Plan Completeness",
+      "description": "Validate that a documented test plan or a well-structured tests/ directory exists with clear organization covering unit, integration, and system test levels. Test plans must define test objectives, scope, approach, entry and exit criteria, and test environment requirements. Test organization must follow a consistent naming convention that maps to requirements.",
+      "verification_type": "validation",
+      "evidence_required": "Documented test plan or structured tests/ directory with clear organization, test level categorization (unit, integration, system), naming convention documentation, and test entry/exit criteria.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-11"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-14",
+      "process_area": "Test Verification",
+      "process_area_code": "TEST",
+      "title": "Security Test Cases",
+      "description": "Validate that test files include security-specific test patterns covering authentication, authorization, injection prevention, cross-site scripting (XSS) prevention, and access control enforcement. Security test cases must be explicitly identified and traceable to security requirements. Negative test cases must verify that the system correctly rejects unauthorized actions.",
+      "verification_type": "validation",
+      "evidence_required": "Security-specific test files or test functions covering auth, injection, XSS, and access control patterns, security test traceability to security requirements, and negative test case documentation.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-11(5)", "CA-8"],
+      "priority": "critical"
+    },
+    {
+      "id": "IVV-15",
+      "process_area": "Test Verification",
+      "process_area_code": "TEST",
+      "title": "BDD Feature Coverage",
+      "description": "Validate that all .feature files have corresponding step implementation files that fully implement every scenario and step defined in the feature. Unimplemented or pending steps must be tracked and resolved. Feature files must follow Gherkin syntax standards and be executable through the BDD test runner without errors.",
+      "verification_type": "validation",
+      "evidence_required": "Feature file inventory with corresponding step implementation files, BDD test runner execution results showing all scenarios pass, and unimplemented step tracking records.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-11"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-16",
+      "process_area": "Integration Verification",
+      "process_area_code": "INT",
+      "title": "Interface Testing",
+      "description": "Validate that integration tests verify module-to-module interfaces including data exchange formats, error handling across boundaries, and protocol compliance. Interface tests must cover both happy path and error scenarios for each integration point. Test results must demonstrate that all module interfaces function correctly under expected and boundary conditions.",
+      "verification_type": "validation",
+      "evidence_required": "Integration test files covering module interfaces, interface specification documents, test results for happy path and error scenarios, and boundary condition test evidence.",
+      "automation_level": "semi",
+      "nist_controls": ["SA-11(3)"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-17",
+      "process_area": "Integration Verification",
+      "process_area_code": "INT",
+      "title": "End-to-End Verification",
+      "description": "Validate that end-to-end tests exist and exercise complete user workflows from input to output across all system layers. E2E test infrastructure must be present (e2e/ or integration/ directories, Playwright or equivalent configuration). E2E tests must cover critical user journeys and demonstrate system behavior matches requirements.",
+      "verification_type": "validation",
+      "evidence_required": "End-to-end test files in e2e/ or integration/ directories, E2E test framework configuration (Playwright, Selenium, or equivalent), test execution results covering critical user journeys, and workflow coverage matrix.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-11(3)"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-18",
+      "process_area": "Integration Verification",
+      "process_area_code": "INT",
+      "title": "API Contract Testing",
+      "description": "Validate that API specifications are tested against the actual implementation to ensure contract compliance. OpenAPI specifications, contract test files, or consumer-driven contract tests must verify that API endpoints match their documented behavior including request/response schemas, status codes, and error handling.",
+      "verification_type": "validation",
+      "evidence_required": "OpenAPI specification files, contract test implementations, API contract validation results, and schema compliance reports showing endpoints match documented behavior.",
+      "automation_level": "semi",
+      "nist_controls": ["SA-11(3)"],
+      "priority": "medium"
+    },
+    {
+      "id": "IVV-19",
+      "process_area": "Traceability Analysis",
+      "process_area_code": "RTM",
+      "title": "RTM Completeness",
+      "description": "Verify that a Requirements Traceability Matrix exists and maps every requirement to its corresponding design element, implementation artifact, and test case. The RTM must be maintained as a living document and updated whenever requirements, code, or tests change. No requirement may exist without at least one traced test case.",
+      "verification_type": "verification",
+      "evidence_required": "Requirements Traceability Matrix document or database, RTM completeness audit showing all requirements mapped, and RTM update history demonstrating ongoing maintenance.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-11(1)", "SA-15"],
+      "priority": "critical"
+    },
+    {
+      "id": "IVV-20",
+      "process_area": "Traceability Analysis",
+      "process_area_code": "RTM",
+      "title": "Bidirectional Traceability",
+      "description": "Verify that traceability is maintained in both directions: forward from requirements to tests (ensuring all requirements are tested) and backward from tests to requirements (ensuring all tests have a purpose). Orphan tests with no requirement linkage and untested requirements must both be identified and resolved.",
+      "verification_type": "verification",
+      "evidence_required": "Forward traceability report (requirements to tests), backward traceability report (tests to requirements), orphan test identification, and untested requirement identification with resolution actions.",
+      "automation_level": "semi",
+      "nist_controls": ["SA-11(1)"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-21",
+      "process_area": "Traceability Analysis",
+      "process_area_code": "RTM",
+      "title": "Gap Analysis",
+      "description": "Verify that a gap analysis has been performed identifying all untested requirements and orphan tests that do not trace to any requirement. The gap analysis must quantify coverage gaps, prioritize resolution based on requirement criticality, and provide a remediation plan with timelines for closing identified gaps.",
+      "verification_type": "verification",
+      "evidence_required": "Gap analysis report identifying untested requirements and orphan tests, coverage gap quantification, prioritized remediation plan with timelines, and gap closure tracking records.",
+      "automation_level": "semi",
+      "nist_controls": ["SA-11(1)"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-22",
+      "process_area": "Security Verification",
+      "process_area_code": "SEC",
+      "title": "Independent Security Assessment",
+      "description": "Verify that a security assessment has been conducted by a team or individual independent from the development organization. The assessment must evaluate security controls, identify vulnerabilities, and provide findings with risk ratings. Independence must be demonstrated through organizational separation or third-party engagement documentation.",
+      "verification_type": "verification",
+      "evidence_required": "Independent security assessment report, assessor independence documentation (organizational chart or third-party contract), security findings with risk ratings, and remediation recommendations.",
+      "automation_level": "semi",
+      "nist_controls": ["CA-2", "CA-7"],
+      "priority": "critical"
+    },
+    {
+      "id": "IVV-23",
+      "process_area": "Security Verification",
+      "process_area_code": "SEC",
+      "title": "Penetration Test Results",
+      "description": "Validate that penetration testing has been performed against the system with findings documented including severity, exploitability, and remediation status. Pentest scope must cover all externally accessible interfaces and critical internal components. Findings must be tracked through remediation with retesting to confirm fixes are effective.",
+      "verification_type": "validation",
+      "evidence_required": "Penetration test report with scope definition, findings categorized by severity, remediation status for each finding, retest results confirming fixes, and risk acceptance for any open findings.",
+      "automation_level": "manual",
+      "nist_controls": ["CA-8"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-24",
+      "process_area": "Security Verification",
+      "process_area_code": "SEC",
+      "title": "Vulnerability Remediation Verification",
+      "description": "Verify that all critical and high vulnerabilities identified through scanning, assessment, or penetration testing have been remediated or have documented risk acceptance with compensating controls. Remediation must be verified through rescanning or retesting. Vulnerability remediation timelines must comply with organizational SLAs.",
+      "verification_type": "verification",
+      "evidence_required": "Vulnerability remediation tracking records, rescan or retest results confirming remediation, risk acceptance documentation for any open critical/high findings with compensating controls, and SLA compliance metrics.",
+      "automation_level": "auto",
+      "nist_controls": ["RA-5", "SI-2"],
+      "priority": "critical"
+    },
+    {
+      "id": "IVV-25",
+      "process_area": "Build/Deploy Verification",
+      "process_area_code": "BLD",
+      "title": "Pipeline Security",
+      "description": "Verify that the CI/CD pipeline includes security stages for static analysis (SAST), dependency auditing, secret detection, and container image scanning. Security stages must be configured to block pipeline progression on critical findings. Pipeline configuration must be version-controlled and access-restricted to prevent unauthorized modification.",
+      "verification_type": "verification",
+      "evidence_required": "CI/CD pipeline configuration files (.gitlab-ci.yml or equivalent) showing security stages, pipeline execution logs demonstrating security gate enforcement, and pipeline access control configuration.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-15", "CM-3"],
+      "priority": "critical"
+    },
+    {
+      "id": "IVV-26",
+      "process_area": "Build/Deploy Verification",
+      "process_area_code": "BLD",
+      "title": "Artifact Integrity",
+      "description": "Verify that build artifacts include a Software Bill of Materials (SBOM), cryptographic checksums, or digital signatures to ensure integrity and provenance. Artifact integrity must be verifiable at any point in the supply chain from build through deployment. SBOM must be regenerated on every build to reflect current dependencies.",
+      "verification_type": "verification",
+      "evidence_required": "SBOM files (CycloneDX or SPDX format) for each build, checksum or signature files for build artifacts, artifact verification procedures, and SBOM generation pipeline stage evidence.",
+      "automation_level": "auto",
+      "nist_controls": ["SI-7", "SR-4"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-27",
+      "process_area": "Build/Deploy Verification",
+      "process_area_code": "BLD",
+      "title": "Configuration Hardening",
+      "description": "Verify that containers are built from STIG-hardened base images, run as non-root users, use read-only root filesystems, and drop all unnecessary Linux capabilities. Dockerfile and container configurations must be auditable against hardening requirements. Configuration hardening must be verified through automated scanning before deployment.",
+      "verification_type": "verification",
+      "evidence_required": "Dockerfile contents showing STIG-hardened base, non-root USER directive, read-only rootfs configuration, capability drop settings, container security scan results, and hardening checklist compliance.",
+      "automation_level": "auto",
+      "nist_controls": ["CM-6", "SC-2"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-28",
+      "process_area": "Build/Deploy Verification",
+      "process_area_code": "BLD",
+      "title": "Rollback Capability",
+      "description": "Verify that a rollback mechanism exists and is tested for all deployments, including rollback scripts, Kubernetes rollout undo procedures, or deployment versioning that enables reverting to a known-good state. Rollback procedures must be documented, tested prior to production deployment, and executable within defined recovery time objectives.",
+      "verification_type": "verification",
+      "evidence_required": "Rollback procedure documentation, rollback scripts or K8s rollout undo configuration, rollback test results demonstrating successful reversion, and deployment versioning records.",
+      "automation_level": "auto",
+      "nist_controls": ["CM-3(4)", "CP-10"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-29",
+      "process_area": "Process Compliance",
+      "process_area_code": "PROC",
+      "title": "TDD Adherence",
+      "description": "Verify that the Test-Driven Development process is followed by confirming the audit trail shows test_written events occurring before corresponding code_generated events. The RED-GREEN-REFACTOR cycle must be evidenced in the development workflow. Deviations from TDD must be documented with justification.",
+      "verification_type": "verification",
+      "evidence_required": "Audit trail records showing test_written events preceding code_generated events, TDD cycle evidence (RED-GREEN-REFACTOR), and deviation documentation for any non-TDD code changes.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-15"],
+      "priority": "high"
+    },
+    {
+      "id": "IVV-30",
+      "process_area": "Process Compliance",
+      "process_area_code": "PROC",
+      "title": "Gate Compliance History",
+      "description": "Verify that all security and compliance gates (code review, merge, deploy) have been passed for the most recent release. Gate compliance must be evidenced through pipeline logs, approval records, and gate evaluation results. Any gate overrides must be documented with authorization and justification.",
+      "verification_type": "verification",
+      "evidence_required": "Gate evaluation results for code review, merge, and deploy gates, pipeline execution logs showing gate pass/fail status, gate override documentation with authorization, and release compliance summary.",
+      "automation_level": "auto",
+      "nist_controls": ["CM-3", "SA-11"],
+      "priority": "critical"
+    }
+  ]
+}