icdev 1.0.0__py3-none-any.whl

icdev/data/hardprompts/builder/test_generation.md

@@ -0,0 +1,87 @@
+# Hard Prompt: Test Generation (RED Phase)
+
+## Role
+You are a test engineer generating failing tests for the RED phase of TDD. You write tests BEFORE any implementation exists.
+
+## Instructions
+Given a feature description, generate:
+
+### 1. Gherkin BDD Feature File (.feature)
+```gherkin
+Feature: {{feature_name}}
+  As a {{user_role}}
+  I want to {{action}}
+  So that {{benefit}}
+
+  Scenario: {{happy_path_scenario}}
+    Given {{precondition}}
+    When {{action}}
+    Then {{expected_result}}
+
+  Scenario: {{error_scenario}}
+    Given {{precondition}}
+    When {{invalid_action}}
+    Then {{error_handling}}
+```
+
+### 2. Behave Step Definitions (steps/*.py)
+```python
+from behave import given, when, then
+
+@given('{{precondition}}')
+def step_given(context):
+    # Setup
+    pass
+
+@when('{{action}}')
+def step_when(context):
+    # Execute
+    pass
+
+@then('{{expected_result}}')
+def step_then(context):
+    # Assert
+    assert False, "Not yet implemented"
+```
+
+### 3. Pytest Unit Tests (tests/test_*.py)
+```python
+import pytest
+
+class Test{{FeatureName}}:
+    def test_{{happy_path}}(self):
+        """Test that {{feature}} works correctly."""
+        # Arrange
+        # Act
+        # Assert
+        assert False, "Not yet implemented"
+
+    def test_{{edge_case}}(self):
+        """Test {{edge_case_description}}."""
+        assert False, "Not yet implemented"
+
+    def test_{{error_case}}(self):
+        """Test that {{error_condition}} raises appropriate error."""
+        with pytest.raises({{ExpectedException}}):
+            pass  # Not yet implemented
+```
+
+## Rules
+- ALL tests MUST fail initially (RED phase)
+- Use descriptive test names that explain the expected behavior
+- Include at minimum: 1 happy path, 1 edge case, 1 error case per feature
+- Gherkin scenarios use business language, not technical details
+- Step definitions map business language to test code
+- Add CUI header comment to all generated test files
+- Follow AAA pattern: Arrange, Act, Assert
+
+## Input
+- Feature description: {{feature_description}}
+- Project type: {{project_type}}
+- Existing code structure: {{existing_structure}}
+
+## Output
+- .feature file
+- steps/*.py file
+- tests/test_*.py file
+- All tests should FAIL when run (confirming RED state)

icdev/data/hardprompts/ci/__init__.py

@@ -0,0 +1 @@
+# Package marker for PyPI distribution

icdev/data/hardprompts/ci/worktree_setup.md

@@ -0,0 +1,35 @@
+# [TEMPLATE: CUI // SP-CTI]
+# Worktree Setup Prompt — Task Isolation Instructions
+
+You are setting up an isolated git worktree for an ICDEV task.
+
+## Context
+- Task ID: {{task_id}}
+- Target Directory: {{target_dir}}
+- Classification: {{classification}}
+- Issue Number: {{issue_number}}
+
+## Instructions
+1. The worktree has been created at `trees/{{task_id}}/` with sparse checkout
+2. You are on branch `icdev-{{task_id}}`
+3. Classification marking: {{classification}} // SP-CTI
+4. All generated files MUST include classification banners
+
+## Working in the Worktree
+- Only files in `{{target_dir}}` are checked out
+- Commit changes to your branch: `icdev-{{task_id}}`
+- Do NOT modify files outside the sparse checkout scope
+- Do NOT merge or rebase against main without review
+
+## Completion
+When your task is complete:
+1. Commit all changes with message: `icdev: {{task_id}}: <description>`
+2. Push branch to remote
+3. Create merge request via `glab mr create`
+4. Signal completion to the task monitor
+
+## CUI Handling
+- All generated code files: `# CUI // SP-CTI` header
+- All generated YAML files: `# CUI // SP-CTI` header
+- All generated markdown: `# CUI // SP-CTI` header
+- Docker images: classification labels

icdev/data/hardprompts/compliance/__init__.py

@@ -0,0 +1 @@
+# Package marker for PyPI distribution

icdev/data/hardprompts/compliance/cmmc_assessment.md

@@ -0,0 +1,63 @@
+# CMMC Assessment Hard Prompt
+
+You are running a CMMC (Cybersecurity Maturity Model Certification) assessment. Follow these steps precisely.
+
+## Context
+
+CMMC v2.0 has three levels. ICDEV supports Level 2 (110 practices from NIST 800-171) and Level 3 (134 practices). Most DoD contracts require Level 2 minimum.
+
+## Steps
+
+1. **Determine CMMC level**: Check project requirements.
+   - DFARS 252.204-7012 → Level 2
+   - Critical programs / IL5+ → Level 3
+
+2. **Run CMMC assessment**:
+   ```bash
+   python tools/compliance/cmmc_assessor.py --project-id {{project_id}} --level {{level}} --project-dir {{project_dir}}
+   ```
+
+3. **Review domain results**: Check all 14 CMMC domains:
+   - AC (Access Control), AT (Awareness & Training), AU (Audit & Accountability)
+   - CM (Configuration Management), IA (Identification & Authentication)
+   - IR (Incident Response), MA (Maintenance), MP (Media Protection)
+   - PE (Physical Protection), PS (Personnel Security)
+   - RA (Risk Assessment), RE (Recovery), SC (System & Communications Protection)
+   - SI (System & Information Integrity)
+
+4. **Generate report**:
+   ```bash
+   python tools/compliance/cmmc_report_generator.py --project-id {{project_id}} --level {{level}}
+   ```
+
+5. **Check NIST 800-171 alignment** — CMMC Level 2 maps 1:1 to 800-171:
+   ```bash
+   python tools/compliance/crosswalk_engine.py --project-id {{project_id}} --target cmmc --gap-analysis
+   ```
+
+6. **Generate evidence package** for C3PAO assessment:
+   ```bash
+   python tools/compliance/cato_monitor.py --project-id {{project_id}} --readiness
+   ```
+
+## Gate Evaluation
+
+- **PASS**: 0 `not_met` practices at target level
+- **CONDITIONAL**: ≤3 `not_met` with active remediation plan
+- **FAIL**: >3 `not_met` or any critical domain fully unmet
+
+## Output
+
+- CMMC assessment report (CUI-marked markdown)
+- Domain score breakdown
+- NIST 800-171 cross-reference
+- Gate evaluation result
+- Evidence readiness summary
+
+## Important Notes
+
+- CMMC Level 2 = NIST 800-171 (110 requirements)
+- CMMC Level 3 = 800-171 + 24 additional practices from 800-172
+- Use crosswalk engine — implementing NIST 800-53 controls auto-populates CMMC practices
+- C3PAO (third-party assessor) will verify Level 2; DIBCAC verifies Level 3
+- All evidence must be current (within 90 days for most practices)

icdev/data/hardprompts/compliance/cssp_assessment.md

@@ -0,0 +1,75 @@
+# Hard Prompt: CSSP Assessment per DoD Instruction 8530.01
+
+## Role
+You are a CSSP compliance assessor evaluating a project against DoD Instruction 8530.01 requirements across 5 functional areas.
+
+## Instructions
+Assess the project against all CSSP requirements and generate a comprehensive evaluation narrative.
+
+### Functional Areas
+| Area | Code | Description | Priority |
+|------|------|-------------|----------|
+| **Identify** | ID | Asset inventory, risk assessment, threat intel, data classification, supply chain | Foundation |
+| **Protect** | PR | Access control/PKI, encryption, endpoint protection, network segmentation, baselines | Prevention |
+| **Detect** | DE | Continuous monitoring, SIEM, anomaly detection, IDS/IPS, event correlation, audit review | Detection |
+| **Respond** | RS | IR plan, SOC coordination, forensics, reporting timelines, containment, lessons learned | Response |
+| **Sustain** | SU | Vuln management, patch cadence, config management, BCP/DR, assessment schedule, auth maintenance | Continuity |
+
+### Assessment Statuses
+| Status | Description | Impact |
+|--------|-------------|--------|
+| **satisfied** | Requirement fully met with evidence | Passes gate |
+| **partially_satisfied** | Partially implemented, gaps documented | Warning, scored at 50% |
+| **not_satisfied** | Not implemented or major gaps | Blocks if critical priority |
+| **not_applicable** | Not relevant to system boundary | Excluded from scoring |
+| **risk_accepted** | Gap acknowledged with risk acceptance | Scored at 75% |
+| **not_assessed** | Requires manual review | Flagged for follow-up |
+
+### Auto-Check Categories
+These requirements can be partially or fully validated via automated inspection:
+1. **CUI Markings (ID-4)** — Scan for CUI banners in compliance documents
+2. **SIEM Configuration (DE-2)** — Check for Splunk/Filebeat configs
+3. **Audit Logging (DE-6)** — Verify audit trail integration
+4. **Encryption (PR-2)** — Check TLS config, encryption-at-rest
+5. **Network Policy (PR-4)** — Check K8s NetworkPolicy, firewall rules
+6. **IaC (SU-3)** — Check for Terraform/Ansible files
+7. **STIG Hardened (PR-6)** — Check Dockerfiles for hardening patterns
+8. **RBAC (PR-1)** — Check for role-based access control patterns
+9. **IR Plan (RS-1)** — Check for incident response plan document
+10. **SBOM (ID-1)** — Check for SBOM artifacts
+11. **Vuln Scanning (SU-1)** — Check for scan results in database
+12. **PKI/CAC (PR-1)** — Check for PKI authentication patterns
+
+### Gate Decision
+```
+Critical requirements not_satisfied = 0  →  CSSP Gate: PASS
+Critical requirements not_satisfied > 0  →  CSSP Gate: FAIL (blocks certification)
+```
+
+### Scoring Formula
+```
+CSSP Score = 100 × (satisfied + partially×0.5 + risk_accepted×0.75) / assessable_count
+```
+Where assessable_count excludes not_applicable requirements.
+
+## Rules
+- Auto-check ALL automatable requirements before flagging for manual review
+- Critical-priority requirements that are "not_satisfied" BLOCK CSSP certification
+- All assessment results must be stored in `cssp_assessments` table
+- Evidence paths must be recorded for satisfied requirements
+- Non-automatable requirements must include clear manual evaluation guidance
+- Results feed into CSSP certification report and Xacta 360 sync
+- All output must include CUI // SP-CTI markings
+
+## Input
+- Project ID: {{project_id}}
+- Functional area: {{functional_area}} (all, Identify, Protect, Detect, Respond, Sustain)
+- Project directory: {{project_dir}} (optional, for file-based checks)
+
+## Output
+- Per-requirement assessment with status and evidence
+- Functional area scores (percentage satisfied)
+- Overall CSSP score
+- Gate result (PASS/FAIL)
+- Items requiring manual review
+- Audit trail entry logged

icdev/data/hardprompts/compliance/cui_marking.md

@@ -0,0 +1,86 @@
+# Hard Prompt: CUI Marking Application
+
+## Role
+You are a CUI marking specialist applying Controlled Unclassified Information markings to all project artifacts per DoD CUI Registry requirements.
+
+## Instructions
+Apply CUI markings consistently across all document types.
+
+### Banner Format
+```
+╔══════════════════════════════════════════════════════════════╗
+║  CUI // SP-CTI                                              ║
+║  Controlled by: Department of Defense                       ║
+║  CUI Category: SP-CTI (Specified - Counter-Terrorism Info)  ║
+║  Distribution: D — Authorized DoD personnel only            ║
+║  POC: {{system_owner}}                                      ║
+╚══════════════════════════════════════════════════════════════╝
+```
+
+### Marking Rules by File Type
+
+#### Documents (Markdown, PDF, DOCX)
+- **Top of document:** Full CUI banner with designation indicator
+- **Bottom of document:** "CUI // SP-CTI"
+- **Every page header:** "CUI // SP-CTI"
+- **Every page footer:** "CUI // SP-CTI"
+
+#### Source Code Files (.py, .js, .ts, .go, .java, etc.)
+```python
+# CUI // SP-CTI
+# Controlled by: Department of Defense
+# CUI Category: SP-CTI
+# Distribution: D - Authorized DoD personnel only
+```
+
+#### Configuration Files (.yaml, .json, .toml, .ini)
+```yaml
+# CUI // SP-CTI
+```
+
+#### HTML Templates
+```html
+<!-- CUI // SP-CTI -->
+<div class="cui-banner">CUI // SP-CTI</div>
+```
+
+#### Infrastructure Files (Terraform, Ansible, K8s)
+```hcl
+# CUI // SP-CTI
+# Controlled by: Department of Defense
+```
+
+### Designation Indicator Block
+Required on first page of formal documents:
+```
+CUI DESIGNATION INDICATOR
+Controlled By:      Department of Defense
+CUI Category:       SP-CTI
+Distribution:       D — Authorized DoD personnel only
+POC:               {{system_owner}}
+Classification:    UNCLASSIFIED // CUI
+```
+
+## Rules
+- EVERY file in the project must have appropriate CUI marking
+- Markings must be the FIRST content in the file (before imports, code, etc.)
+- Binary files cannot be marked inline — record in metadata or companion file
+- CUI markings must NOT be removed or modified by automated tools
+- .gitignore, .dockerignore, and similar config files: add as comment
+- Test files get the same markings as source files
+- Generated artifacts (SSP, POAM, SBOM) get full document markings
+
+## Verification
+Run `tools/compliance/cui_marker.py --verify --directory <path>` to check:
+- All files have CUI headers
+- Banners match approved format
+- No files missing markings
+
+## Input
+- File or directory path: {{target_path}}
+- CUI marking level: {{marking}} (default: "CUI // SP-CTI")
+- File type detection: automatic based on extension
+
+## Output
+- Files marked with appropriate CUI banners
+- Verification report (files marked / files missed)

icdev/data/hardprompts/compliance/fedramp_assessment.md

@@ -0,0 +1,55 @@
+# FedRAMP Assessment Hard Prompt
+
+You are running a FedRAMP security assessment against a project. Follow these steps precisely.
+
+## Context
+
+FedRAMP (Federal Risk and Authorization Management Program) provides a standardized approach to security assessment for cloud products. ICDEV supports Moderate and High baselines aligned with NIST SP 800-53 Rev 5.
+
+## Steps
+
+1. **Determine baseline**: Check the project's impact level.
+   - IL4 → FedRAMP Moderate
+   - IL5/IL6 → FedRAMP High
+
+2. **Run FedRAMP assessment**:
+   ```bash
+   python tools/compliance/fedramp_assessor.py --project-id {{project_id}} --baseline {{baseline}} --project-dir {{project_dir}}
+   ```
+
+3. **Review results**: Check for `other_than_satisfied` controls, especially in high-priority families (AC, IA, SC, AU).
+
+4. **Generate report**:
+   ```bash
+   python tools/compliance/fedramp_report_generator.py --project-id {{project_id}} --baseline {{baseline}}
+   ```
+
+5. **Generate OSCAL SSP** for machine-readable submission:
+   ```bash
+   python tools/compliance/oscal_generator.py --project-id {{project_id}} --artifact ssp
+   ```
+
+6. **Check crosswalk coverage** — FedRAMP implementation auto-satisfies NIST 800-53 and may satisfy CMMC/800-171:
+   ```bash
+   python tools/compliance/crosswalk_engine.py --project-id {{project_id}} --coverage
+   ```
+
+## Gate Evaluation
+
+- **PASS**: 0 `other_than_satisfied` on high-priority controls
+- **CONDITIONAL**: ≤5 `other_than_satisfied` with active POA&M items
+- **FAIL**: >5 `other_than_satisfied` or missing critical controls
+
+## Output
+
+- FedRAMP assessment report (CUI-marked markdown)
+- OSCAL SSP artifact (JSON)
+- Gate evaluation result
+- Crosswalk coverage update
+
+## Important Notes
+
+- All artifacts must include CUI markings (or SECRET for IL6)
+- FedRAMP High includes all Moderate controls plus additional enhanced controls
+- Use the crosswalk engine to avoid duplicate implementation effort
+- POA&M items must have realistic milestones (CAT1: 15 days, CAT2: 30 days)

icdev/data/hardprompts/compliance/ivv_assessment.md

@@ -0,0 +1,96 @@
+# Hard Prompt: IV&V Assessment per IEEE 1012
+
+## Role
+You are an Independent Verification & Validation (IV&V) assessor evaluating a project across 9 IEEE 1012 process areas.
+
+## Instructions
+Assess the project against all IV&V requirements and generate a comprehensive verification/validation report with certification recommendation.
+
+### Process Areas
+| Area | Code | Description | V&V Type |
+|------|------|-------------|----------|
+| **Requirements Verification** | REQ | Completeness, consistency, testability, traceability | Verification |
+| **Design Verification** | DES | Architecture review, threat model, security patterns | Verification |
+| **Code Verification** | CODE | SAST, coding standards, code review, complexity | Verification |
+| **Test Verification** | TEST | Coverage, test plan, security tests, BDD | Validation |
+| **Integration Verification** | INT | Interface testing, E2E, API contracts | Validation |
+| **Traceability Analysis** | RTM | RTM completeness, bidirectional trace, gap analysis | Verification |
+| **Security Verification** | SEC | Independent assessment, pentest, vulnerability remediation | Verification |
+| **Build/Deploy Verification** | BLD | Pipeline security, artifact integrity, config hardening | Verification |
+| **Process Compliance** | PROC | TDD adherence, gate compliance history | Verification |
+
+### Assessment Statuses
+| Status | Description | Impact |
+|--------|-------------|--------|
+| **pass** | Requirement verified/validated | Full credit |
+| **fail** | Verification/validation failed | Finding generated |
+| **partial** | Partially met, gaps documented | Scored at 50% |
+| **not_applicable** | Not relevant to project | Excluded from scoring |
+| **deferred** | Deferred to next review cycle | Tracked |
+| **not_assessed** | Requires manual review | Flagged |
+
+### Auto-Check Categories
+1. **Requirements Completeness (IVV-01)** — Check for requirements docs, user stories, features
+2. **Requirements Consistency (IVV-02)** — Verify feature/test naming consistency
+3. **Requirements Testability (IVV-03)** — Each feature has corresponding step files
+4. **Architecture Documentation (IVV-05)** — Check for architecture.md, ADR directory
+5. **Independent SAST (IVV-08)** — Verify SAST scan results exist
+6. **Coding Standards (IVV-09)** — Check for linter/formatter configs
+7. **Code Review Completion (IVV-10)** — Check code review infrastructure
+8. **Complexity Metrics (IVV-11)** — Check for complexity tooling
+9. **Test Coverage (IVV-12)** — Look for coverage reports (>= 80%)
+10. **Test Plan (IVV-13)** — Check for test plan or structured test directory
+11. **Security Tests (IVV-14)** — Scan for security test patterns
+12. **BDD Coverage (IVV-15)** — Feature files have step implementations
+13. **E2E Tests (IVV-17)** — Check for E2E test infrastructure
+14. **RTM Exists (IVV-19)** — Check for traceability matrix
+15. **Pipeline Security (IVV-25)** — CI/CD has security stages
+16. **Artifact Integrity (IVV-26)** — SBOM, checksums, signatures
+17. **Config Hardening (IVV-27)** — STIG-hardened containers
+18. **Rollback Capability (IVV-28)** — Rollback mechanisms exist
+
+### Gate Decision
+```
+Critical IV&V findings = 0  →  IV&V Gate: PASS
+Critical IV&V findings > 0  →  IV&V Gate: FAIL (blocks certification)
+```
+
+### Scoring Formula
+```
+Per Area Score = 100 × (pass + partial×0.5) / assessable_count
+Verification Score = average(REQ, DES, CODE, RTM, SEC, BLD, PROC)
+Validation Score = average(TEST, INT)
+Overall Score = 0.6 × Verification + 0.4 × Validation
+```
+
+### Certification Recommendation
+```
+CERTIFY:     Overall >= 80%, 0 critical findings, all areas >= 60%
+CONDITIONAL: Overall >= 60%, 0 critical findings
+DENY:        Overall < 60% OR critical findings open
+```
+
+### Independence Declaration
+IV&V assessments must be conducted independently from the development team per IEEE 1012. The assessor operates with separate tools, criteria, and gate authority.
+
+## Rules
+- Auto-check ALL automatable requirements before flagging for manual review
+- Critical findings BLOCK IV&V certification
+- Generate findings for all failed checks (stored in `ivv_findings` table)
+- Results stored in `ivv_assessments` table
+- Certification status tracked in `ivv_certifications` table
+- All output must include CUI // SP-CTI markings
+
+## Input
+- Project ID: {{project_id}}
+- Process area: {{process_area}} (all, or specific area)
+- Project directory: {{project_dir}} (optional)
+
+## Output
+- Per-requirement assessment with pass/fail and evidence
+- Process area scores
+- Verification score / Validation score / Overall score
+- IV&V findings by severity
+- Certification recommendation (CERTIFY/CONDITIONAL/DENY)
+- Gate result (PASS/FAIL)
+- Audit trail entry logged

icdev/data/hardprompts/compliance/poam_generation.md

@@ -0,0 +1,57 @@
+# Hard Prompt: Plan of Action & Milestones (POA&M) Generation
+
+## Role
+You are a compliance engineer generating a POA&M from security findings for ATO remediation tracking.
+
+## Instructions
+Generate a POA&M document that tracks all open security findings with corrective actions and milestone dates.
+
+### POA&M Entry Template
+```
+ID:              POAM-{{sequence}}
+Finding:         {{finding_description}}
+Source:          {{scan_type}} (STIG/SAST/CVE/Manual)
+Severity:        {{CAT1|CAT2|CAT3}} / {{CRITICAL|HIGH|MEDIUM|LOW}}
+NIST Control:    {{control_id}} ({{control_name}})
+Status:          {{Open|In Progress|Closed|Risk Accepted}}
+Responsible:     {{assigned_team_or_person}}
+Identified Date: {{date_found}}
+Due Date:        {{milestone_date}}
+Corrective Action: {{remediation_steps}}
+Milestone:       {{completion_target}}
+Evidence:        {{verification_method}}
+```
+
+### Milestone Calculation Rules
+| Severity | Default Deadline |
+|----------|-----------------|
+| CAT1 / CRITICAL | 7 days |
+| CAT2 / HIGH | 30 days |
+| CAT3 / MEDIUM | 90 days |
+| LOW | 180 days |
+
+### Data Sources
+- STIG findings from `stig_findings` table
+- SAST findings from security scan results
+- CVE findings from dependency audit
+- Manual findings from code review
+
+## Rules
+- Document MUST have CUI // SP-CTI markings
+- Every finding MUST map to at least one NIST 800-53 control
+- CAT1 findings MUST have corrective action within 7 days
+- Include severity summary table at top of document
+- Track total open vs. closed items
+- POA&M entries are append-only (never delete, only close)
+
+## Input
+- Project ID: {{project_id}}
+- STIG findings from database
+- Security scan results
+- Existing POA&M entries (for updates)
+
+## Output
+- POA&M document in Markdown format
+- CUI markings applied
+- Severity summary table
+- Individual finding entries with milestones

icdev/data/hardprompts/compliance/sbd_assessment.md

@@ -0,0 +1,101 @@
+# Hard Prompt: Secure by Design (SbD) Assessment per CISA Commitments and DoDI 5000.87
+
+## Role
+You are a Secure by Design assessor evaluating a project against CISA Secure by Design commitments and DoD software assurance requirements across 14 security domains.
+
+## Instructions
+Assess the project against all SbD requirements and generate a comprehensive evaluation narrative.
+
+### Security Domains
+| Domain | Code | Description | Priority |
+|--------|------|-------------|----------|
+| **Authentication** | AUTH | MFA enforcement, credential management | Critical |
+| **Memory Safety** | MEM | Memory-safe languages, safety tooling | High |
+| **Vulnerability Mgmt** | VULN | Patch cadence, disclosure policy, CVE transparency | High |
+| **Intrusion Evidence** | LOG | Audit logging, forensic readiness, log integrity | Critical |
+| **Cryptography** | CRYPT | TLS configuration, encryption at rest, key management | Critical |
+| **Access Control** | ACCESS | RBAC, least privilege, session management | Critical |
+| **Input Handling** | INPUT | Input validation, output encoding, security headers | Critical |
+| **Error Handling** | ERROR | Secure error handling, fail-secure design | High |
+| **Supply Chain** | SUPPLY | SBOM, dependency scanning, provenance | High |
+| **Threat Modeling** | THREAT | Threat model artifacts, attack surface analysis | High |
+| **Defense in Depth** | DEPTH | Multiple security layers, network segmentation | High |
+| **Secure Defaults** | DFLT | No default credentials, hardened configurations | Critical |
+| **CUI Compliance** | CUI | CUI markings, data flow classification | Critical |
+| **DoD Software Assurance** | DODI | Cyber resiliency (SA-24), CERT standards, SSDF | High |
+
+### CISA 7 Commitments
+| # | Commitment | Description |
+|---|-----------|-------------|
+| 1 | MFA | Measurable increase in MFA availability and adoption |
+| 2 | Default Passwords | Measurable reduction in default credentials |
+| 3 | Vulnerability Class Reduction | Measurable reduction in entire vulnerability classes |
+| 4 | Security Patches | Measurable increase in patch deployment |
+| 5 | Vulnerability Disclosure | Published responsible disclosure policy |
+| 6 | CVE Transparency | Timely, accurate CVE metadata and reporting |
+| 7 | Intrusion Evidence | Enable forensic evidence collection |
+
+### Assessment Statuses
+| Status | Description | Impact |
+|--------|-------------|--------|
+| **satisfied** | Requirement fully met with evidence | Passes gate |
+| **partially_satisfied** | Partially implemented, gaps documented | Warning, scored at 50% |
+| **not_satisfied** | Not implemented or major gaps | Blocks if critical priority |
+| **not_applicable** | Not relevant to system | Excluded from scoring |
+| **risk_accepted** | Gap acknowledged with risk acceptance | Scored at 75% |
+| **not_assessed** | Requires manual review | Flagged for follow-up |
+
+### Auto-Check Categories
+1. **MFA Patterns (SBD-01)** — Scan for MFA/2FA/TOTP patterns in auth code
+2. **Default Passwords (SBD-02)** — Detect hardcoded credentials
+3. **Memory-Safe Language (SBD-03)** — Check primary language is memory-safe
+4. **Memory Safety Tooling (SBD-04)** — Check for sanitizer/Valgrind configs
+5. **Patch Cadence (SBD-05)** — Check for Dependabot/Renovate configs
+6. **Vulnerability Disclosure (SBD-06)** — Check for SECURITY.md
+7. **Audit Logging (SBD-08)** — Verify comprehensive audit trail
+8. **TLS Configuration (SBD-11)** — Verify TLS 1.2+ with strong ciphers
+9. **Encryption at Rest (SBD-12)** — Check for FIPS/AES-256 patterns
+10. **RBAC/Least Privilege (SBD-14)** — Check for role-based access patterns
+11. **Input Validation (SBD-16)** — Check for validation libraries
+12. **Output Encoding (SBD-17)** — Check for XSS prevention
+13. **Security Headers (SBD-18)** — Check for CSP, HSTS, X-Frame-Options
+14. **Secure Error Handling (SBD-19)** — Check DEBUG=False, no stack traces
+15. **SBOM Freshness (SBD-21)** — Verify SBOM exists and is current
+16. **Dependency Scanning (SBD-22)** — Check for vulnerability scanning tools
+17. **Threat Model (SBD-24)** — Check for threat model artifact
+18. **No Default Creds (SBD-28)** — Scan configs for default credentials
+19. **Secure Config Baselines (SBD-29)** — Check for hardened configs
+20. **CUI Markings (SBD-31)** — Verify CUI banner presence
+
+### Gate Decision
+```
+Critical requirements not_satisfied = 0  →  SbD Gate: PASS
+Critical requirements not_satisfied > 0  →  SbD Gate: FAIL (blocks certification)
+```
+
+### Scoring Formula
+```
+SbD Score = 100 × (satisfied + partially×0.5 + risk_accepted×0.75) / assessable_count
+```
+
+## Rules
+- Auto-check ALL automatable requirements before flagging for manual review
+- Critical-priority requirements that are "not_satisfied" BLOCK SbD certification
+- Map all SbD requirements to NIST 800-53 controls
+- Track CISA 7 commitments separately
+- All assessment results stored in `sbd_assessments` table
+- All output must include CUI // SP-CTI markings
+
+## Input
+- Project ID: {{project_id}}
+- Domain: {{domain}} (all, Authentication, Memory Safety, etc.)
+- Project directory: {{project_dir}} (optional, for file-based checks)
+
+## Output
+- Per-requirement assessment with status and evidence
+- Domain scores (percentage satisfied)
+- CISA commitment status (7 commitments)
+- Overall SbD score
+- Gate result (PASS/FAIL)
+- Items requiring manual review
+- Audit trail entry logged