icdev 1.0.0__py3-none-any.whl

icdev/data/context/compliance/cisa_sbd_requirements.json

@@ -0,0 +1,432 @@
+{
+  "metadata": {
+    "title": "CISA Secure by Design + DoD Software Assurance Requirements",
+    "source": "CISA SbD Pledge (2024), DoDI 5000.87, NIST SP 800-218 SSDF, NIST 800-53 Rev 5.2 SA-24",
+    "classification": "CUI // SP-CTI",
+    "version": "1.0",
+    "last_updated": "2026-02-15",
+    "description": "Requirements catalog for Secure by Design assessment per CISA commitments and DoD software assurance standards"
+  },
+  "requirements": [
+    {
+      "id": "SBD-01",
+      "domain": "Authentication",
+      "domain_code": "AUTH",
+      "title": "Multi-Factor Authentication",
+      "description": "Enforce multi-factor authentication (MFA/2FA) in all authentication flows for both privileged and non-privileged users. Authentication mechanisms must support hardware tokens, software TOTP, or PKI/CAC-based second factors. MFA bypass or fallback to single-factor authentication must not be permitted without documented risk acceptance.",
+      "evidence_required": "MFA enforcement configuration in authentication module, test results demonstrating MFA challenge on login, and documentation of supported second-factor methods.",
+      "automation_level": "auto",
+      "nist_controls": ["IA-2(1)", "IA-2(2)"],
+      "cisa_commitment": 1,
+      "priority": "critical"
+    },
+    {
+      "id": "SBD-02",
+      "domain": "Authentication",
+      "domain_code": "AUTH",
+      "title": "Default Password Elimination",
+      "description": "Eliminate all default, hardcoded, or well-known passwords from the codebase, configuration files, container images, and deployment artifacts. Static analysis must scan for common default credential patterns including admin/admin, root/root, and password123. Any discovered default credentials must be flagged as critical findings and remediated before deployment.",
+      "evidence_required": "Secret detection scan results showing zero default credential findings, static analysis report for hardcoded password patterns, and configuration review confirming no default credentials in deployment artifacts.",
+      "automation_level": "auto",
+      "nist_controls": ["IA-5"],
+      "cisa_commitment": 2,
+      "priority": "critical"
+    },
+    {
+      "id": "SBD-03",
+      "domain": "Memory Safety",
+      "domain_code": "MEM",
+      "title": "Memory-Safe Language Use",
+      "description": "The primary development language must be memory-safe, such as Rust, Go, Java, Python, or C#, to eliminate entire classes of vulnerabilities including buffer overflows, use-after-free, and null pointer dereferences. Any use of non-memory-safe languages (C, C++) must be documented with justification and subject to additional security review and tooling requirements.",
+      "evidence_required": "Project language manifest identifying primary and secondary languages, justification documentation for any non-memory-safe language usage, and language-specific security tooling configuration.",
+      "automation_level": "auto",
+      "nist_controls": ["SI-16"],
+      "cisa_commitment": 3,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-04",
+      "domain": "Memory Safety",
+      "domain_code": "MEM",
+      "title": "Memory Safety Tooling",
+      "description": "All code written in non-memory-safe languages must be compiled and tested with memory safety tooling such as AddressSanitizer (ASan), MemorySanitizer (MSan), Valgrind, or equivalent instrumentation. Memory safety tool findings must be triaged and resolved before code is promoted to production. CI/CD pipelines must include memory safety checks as a mandatory gate.",
+      "evidence_required": "Memory safety tool configuration in CI/CD pipeline, scan results demonstrating zero unresolved memory safety findings, and documentation of tooling coverage for non-memory-safe code modules.",
+      "automation_level": "auto",
+      "nist_controls": ["SA-11"],
+      "cisa_commitment": 3,
+      "priority": "medium"
+    },
+    {
+      "id": "SBD-05",
+      "domain": "Vulnerability Management",
+      "domain_code": "VULN",
+      "title": "Security Patch Cadence",
+      "description": "Automated dependency update tooling such as Dependabot, Renovate, or equivalent must be configured and actively monitoring all project dependencies for available security patches. Critical vulnerability patches must be applied within 72 hours, high within 30 days, and moderate within 90 days. Patch compliance metrics must be tracked and reported.",
+      "evidence_required": "Dependabot or Renovate configuration file, automated pull request history for dependency updates, patch SLA compliance metrics, and evidence of timely merge of security patches.",
+      "automation_level": "auto",
+      "nist_controls": ["SI-2"],
+      "cisa_commitment": 4,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-06",
+      "domain": "Vulnerability Management",
+      "domain_code": "VULN",
+      "title": "Vulnerability Disclosure Policy",
+      "description": "A published vulnerability disclosure policy must be available via SECURITY.md in the repository root or .well-known/security.txt at the application endpoint. The policy must include reporting instructions, expected response timelines, safe harbor language, and scope of the disclosure program. Contact information must be current and monitored.",
+      "evidence_required": "SECURITY.md file in repository root or .well-known/security.txt at application endpoint, policy content review confirming required elements, and evidence that reporting channels are monitored.",
+      "automation_level": "auto",
+      "nist_controls": ["PM-15"],
+      "cisa_commitment": 5,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-07",
+      "domain": "Vulnerability Management",
+      "domain_code": "VULN",
+      "title": "CVE Transparency",
+      "description": "A documented process must exist for tracking, reporting, and communicating Common Vulnerabilities and Exposures (CVEs) affecting the system and its dependencies. Known CVEs must be cataloged with severity, affected component, remediation status, and timeline. Stakeholders must be notified of critical CVEs affecting production systems within 24 hours of discovery.",
+      "evidence_required": "CVE tracking register or database, CVE notification process documentation, evidence of timely CVE communications to stakeholders, and CVE remediation status reports.",
+      "automation_level": "semi",
+      "nist_controls": ["SI-5"],
+      "cisa_commitment": 6,
+      "priority": "medium"
+    },
+    {
+      "id": "SBD-08",
+      "domain": "Intrusion Evidence",
+      "domain_code": "LOG",
+      "title": "Audit Logging Completeness",
+      "description": "All security-relevant events must be logged including authentication attempts (success and failure), authorization decisions, data access and modifications, configuration changes, administrative actions, and application errors. Log entries must include timestamp, actor, action, target resource, source address, and outcome. No security event category may be excluded without documented risk acceptance.",
+      "evidence_required": "Logging configuration showing all required event types enabled, sample log entries demonstrating required fields for each event category, and log coverage matrix mapping event types to log sources.",
+      "automation_level": "auto",
+      "nist_controls": ["AU-2", "AU-3"],
+      "cisa_commitment": 7,
+      "priority": "critical"
+    },
+    {
+      "id": "SBD-09",
+      "domain": "Intrusion Evidence",
+      "domain_code": "LOG",
+      "title": "Forensic Readiness",
+      "description": "The system must maintain the capability to extract and provide forensic evidence to authorized parties within 1 hour of request. Forensic data sources must include application logs, system logs, network flow data, authentication records, and database access logs. Evidence extraction procedures must preserve chain of custody and data integrity.",
+      "evidence_required": "Forensic readiness plan documenting evidence sources and extraction procedures, evidence of test extraction completing within 1-hour SLA, and chain of custody documentation templates.",
+      "automation_level": "semi",
+      "nist_controls": ["AU-7"],
+      "cisa_commitment": 7,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-10",
+      "domain": "Intrusion Evidence",
+      "domain_code": "LOG",
+      "title": "Log Integrity",
+      "description": "Audit logs must be append-only and protected against tampering, modification, or unauthorized deletion. Log integrity mechanisms must include write-once storage, cryptographic hashing, or centralized log forwarding to immutable storage. Log retention must meet minimum retention periods defined by organizational policy and regulatory requirements.",
+      "evidence_required": "Append-only log storage configuration, log integrity verification mechanism documentation, evidence of tamper detection or prevention controls, and log retention policy compliance records.",
+      "automation_level": "semi",
+      "nist_controls": ["AU-9"],
+      "cisa_commitment": 7,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-11",
+      "domain": "Cryptography",
+      "domain_code": "CRYPT",
+      "title": "TLS Configuration",
+      "description": "All network communications must enforce TLS 1.2 or higher with FIPS-approved cipher suites. SSLv3, TLS 1.0, and TLS 1.1 must be explicitly disabled. Inter-service communication within the Kubernetes cluster must use mutual TLS (mTLS). TLS configuration must be validated via automated scanning to detect weak ciphers, expired certificates, or protocol downgrades.",
+      "evidence_required": "TLS configuration files showing minimum version and cipher suite settings, mTLS configuration for inter-service communication, TLS scan results confirming no weak protocols or ciphers, and certificate management documentation.",
+      "automation_level": "auto",
+      "nist_controls": ["SC-8", "SC-13"],
+      "cisa_commitment": null,
+      "priority": "critical"
+    },
+    {
+      "id": "SBD-12",
+      "domain": "Cryptography",
+      "domain_code": "CRYPT",
+      "title": "Encryption at Rest",
+      "description": "All sensitive data at rest must be encrypted using FIPS-approved algorithms, specifically AES-256 or equivalent. Encryption must cover databases, file systems, backups, container volumes, and any persistent storage containing CUI or PII. Encryption configuration must be validated and documented for each storage layer.",
+      "evidence_required": "Encryption configuration for all data stores, FIPS 140-2/3 validation certificate references, storage-layer encryption audit results, and documentation confirming AES-256 or equivalent algorithm usage.",
+      "automation_level": "auto",
+      "nist_controls": ["SC-28"],
+      "cisa_commitment": null,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-13",
+      "domain": "Cryptography",
+      "domain_code": "CRYPT",
+      "title": "Key Management",
+      "description": "All cryptographic keys and secrets must be stored in an approved vault such as AWS Secrets Manager, HashiCorp Vault, or Kubernetes Secrets with encryption at rest. Key rotation policies must be defined and enforced with automated rotation where possible. No secrets may be stored in source code, configuration files, or environment variables committed to version control.",
+      "evidence_required": "Secrets vault configuration and access policies, key rotation policy and execution logs, secret detection scan results confirming no secrets in source code, and key inventory with rotation schedules.",
+      "automation_level": "manual",
+      "nist_controls": ["SC-12"],
+      "cisa_commitment": null,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-14",
+      "domain": "Access Control",
+      "domain_code": "ACCESS",
+      "title": "Least Privilege RBAC",
+      "description": "Role-based access control (RBAC) must be implemented enforcing the principle of least privilege across all system components. Users and service accounts must receive only the minimum permissions required for their assigned functions. Privileged access must require additional authentication and be time-limited where feasible. Access reviews must be conducted quarterly to identify and remove excessive permissions.",
+      "evidence_required": "RBAC configuration files and access control matrix, Kubernetes RBAC manifests, service account permission documentation, quarterly access review records, and privileged access audit logs.",
+      "automation_level": "auto",
+      "nist_controls": ["AC-6"],
+      "cisa_commitment": null,
+      "priority": "critical"
+    },
+    {
+      "id": "SBD-15",
+      "domain": "Access Control",
+      "domain_code": "ACCESS",
+      "title": "Secure Session Management",
+      "description": "Session management must enforce secure cookies (HttpOnly, Secure, SameSite attributes), configurable session timeouts aligned to data sensitivity, and protection against session fixation and replay attacks. Sessions must be invalidated on logout, password change, and privilege escalation. Concurrent session limits must be enforced for privileged accounts.",
+      "evidence_required": "Session management configuration showing cookie attributes and timeout values, session fixation test results, session invalidation test evidence, and concurrent session limit configuration.",
+      "automation_level": "semi",
+      "nist_controls": ["AC-12", "SC-23"],
+      "cisa_commitment": null,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-16",
+      "domain": "Input Handling",
+      "domain_code": "INPUT",
+      "title": "Input Validation",
+      "description": "All external inputs must be validated using established validation libraries such as pydantic, marshmallow, Joi, or equivalent before processing. Validation must enforce type checking, length constraints, format validation, and allowlist-based filtering. Inputs that fail validation must be rejected with appropriate error responses that do not leak internal implementation details.",
+      "evidence_required": "Input validation library configuration and usage across all API endpoints, validation schema definitions, test results demonstrating rejection of malformed inputs, and code review evidence confirming no unvalidated external inputs.",
+      "automation_level": "auto",
+      "nist_controls": ["SI-10"],
+      "cisa_commitment": null,
+      "priority": "critical"
+    },
+    {
+      "id": "SBD-17",
+      "domain": "Input Handling",
+      "domain_code": "INPUT",
+      "title": "Output Encoding",
+      "description": "All dynamic output rendered in HTML, JSON, or other interpreted contexts must be properly encoded or escaped to prevent cross-site scripting (XSS) attacks. Template engines must use auto-escaping by default (e.g., Jinja2 autoescape, markupsafe). Content-Security-Policy headers must be configured to restrict inline script execution and unauthorized resource loading.",
+      "evidence_required": "Template engine configuration showing auto-escaping enabled, Content-Security-Policy header configuration, XSS test results from DAST scanning, and code review evidence confirming proper output encoding.",
+      "automation_level": "auto",
+      "nist_controls": ["SI-10(5)"],
+      "cisa_commitment": null,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-18",
+      "domain": "Input Handling",
+      "domain_code": "INPUT",
+      "title": "Security Headers",
+      "description": "All HTTP responses must include security headers: Content-Security-Policy, Strict-Transport-Security (HSTS), X-Frame-Options, X-Content-Type-Options, and appropriate CORS configuration. CORS must be restrictive, allowing only explicitly authorized origins. HSTS must include a minimum max-age of one year and the includeSubDomains directive.",
+      "evidence_required": "HTTP response header configuration, security header scan results confirming all required headers present, CORS configuration review, and HSTS preload eligibility verification.",
+      "automation_level": "auto",
+      "nist_controls": ["SC-8"],
+      "cisa_commitment": null,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-19",
+      "domain": "Error Handling",
+      "domain_code": "ERROR",
+      "title": "Secure Error Handling",
+      "description": "Production environments must not expose stack traces, debug information, or internal implementation details in error responses. DEBUG mode must be disabled (DEBUG=False) in all production configurations. Custom error handlers must return generic error messages to clients while logging detailed error information server-side for troubleshooting.",
+      "evidence_required": "Production configuration confirming DEBUG=False, custom error handler implementation, test results showing no stack traces in production error responses, and error response samples demonstrating generic client-facing messages.",
+      "automation_level": "auto",
+      "nist_controls": ["SI-11"],
+      "cisa_commitment": null,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-20",
+      "domain": "Error Handling",
+      "domain_code": "ERROR",
+      "title": "Fail Secure Design",
+      "description": "The system must fail to a secure state when encountering unexpected errors, resource exhaustion, or component failures. Failure conditions must not bypass authentication, authorization, or other security controls. Error conditions must not leak sensitive information through timing differences, error message variations, or side channels.",
+      "evidence_required": "Fail-secure design documentation, test results demonstrating secure failure behavior under error conditions, evidence that security controls remain enforced during failures, and side-channel analysis results.",
+      "automation_level": "semi",
+      "nist_controls": ["SC-24"],
+      "cisa_commitment": null,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-21",
+      "domain": "Supply Chain",
+      "domain_code": "SUPPLY",
+      "title": "SBOM Presence and Freshness",
+      "description": "A Software Bill of Materials (SBOM) must be generated for every build and must be no older than 30 days in any deployed environment. The SBOM must enumerate all direct and transitive dependencies including name, version, supplier, and license. SBOM format must conform to CycloneDX or SPDX standards.",
+      "evidence_required": "Current SBOM file in CycloneDX or SPDX format, SBOM generation timestamp within 30 days, CI/CD pipeline configuration showing SBOM generation on every build, and SBOM content validation results.",
+      "automation_level": "auto",
+      "nist_controls": ["SR-4", "SR-5"],
+      "cisa_commitment": null,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-22",
+      "domain": "Supply Chain",
+      "domain_code": "SUPPLY",
+      "title": "Dependency Vulnerability Scanning",
+      "description": "Automated dependency vulnerability scanning using pip-audit, npm audit, Snyk, or equivalent must be configured and run regularly. Scan results must be current within 7 days. Critical and high vulnerability findings in dependencies must block deployment until remediated or documented with risk acceptance and compensating controls.",
+      "evidence_required": "Dependency scanning tool configuration, most recent scan results within 7 days, CI/CD pipeline gate configuration blocking on critical/high findings, and remediation tracking for identified vulnerabilities.",
+      "automation_level": "auto",
+      "nist_controls": ["RA-5"],
+      "cisa_commitment": null,
+      "priority": "critical"
+    },
+    {
+      "id": "SBD-23",
+      "domain": "Supply Chain",
+      "domain_code": "SUPPLY",
+      "title": "Provenance Verification",
+      "description": "All dependency sources must be verified and pinned to specific versions with integrity hashes. Package installation must verify checksums against known-good values. Dependencies must be sourced from approved registries only. Lock files (requirements.txt with hashes, package-lock.json, Cargo.lock) must be committed and enforced in CI/CD.",
+      "evidence_required": "Lock files with pinned versions and integrity hashes committed to repository, package registry configuration restricting to approved sources, and CI/CD configuration enforcing lock file integrity.",
+      "automation_level": "semi",
+      "nist_controls": ["SR-3"],
+      "cisa_commitment": null,
+      "priority": "medium"
+    },
+    {
+      "id": "SBD-24",
+      "domain": "Threat Modeling",
+      "domain_code": "THREAT",
+      "title": "Threat Model Artifact",
+      "description": "A documented threat model must exist for the system using an established methodology such as STRIDE, PASTA, or LINDDUN. The threat model must identify assets, threat actors, attack vectors, and mitigations for each identified threat. The threat model must be reviewed and updated when significant architectural changes occur or at least annually.",
+      "evidence_required": "Threat model document or file in repository (e.g., threat_model.md, threat_model.json), methodology identification, asset inventory within model, and evidence of review/update within the past 12 months.",
+      "automation_level": "auto",
+      "nist_controls": ["RA-3"],
+      "cisa_commitment": null,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-25",
+      "domain": "Threat Modeling",
+      "domain_code": "THREAT",
+      "title": "Attack Surface Analysis",
+      "description": "A documented attack surface analysis must enumerate all entry points, external interfaces, network endpoints, and data flows exposed by the system. Each attack surface element must have identified mitigations and residual risk ratings. The analysis must be updated when new interfaces or endpoints are added to the system.",
+      "evidence_required": "Attack surface analysis document listing all entry points and interfaces, mitigation mapping for each attack surface element, residual risk ratings, and evidence of updates when new interfaces are added.",
+      "automation_level": "manual",
+      "nist_controls": ["RA-3(3)"],
+      "cisa_commitment": null,
+      "priority": "medium"
+    },
+    {
+      "id": "SBD-26",
+      "domain": "Defense in Depth",
+      "domain_code": "DEPTH",
+      "title": "Multiple Security Layers",
+      "description": "Critical data paths and operations must be protected by at least three independent security layers such as network segmentation, authentication, authorization, input validation, encryption, and monitoring. No single control failure should result in complete compromise of a critical asset. Defense-in-depth architecture must be documented and validated through security testing.",
+      "evidence_required": "Defense-in-depth architecture diagram mapping security layers to critical paths, documentation showing at least 3 independent controls per critical path, and penetration test results validating layered defense effectiveness.",
+      "automation_level": "semi",
+      "nist_controls": ["SC-7", "PL-8"],
+      "cisa_commitment": null,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-27",
+      "domain": "Defense in Depth",
+      "domain_code": "DEPTH",
+      "title": "Network Segmentation",
+      "description": "Network policies must enforce segmentation between services following zero-trust principles. Default-deny network policies must be applied at the Kubernetes namespace and pod level. Inter-service communication must be explicitly permitted on a per-service basis. Network segmentation must prevent lateral movement in the event of a single service compromise.",
+      "evidence_required": "Kubernetes NetworkPolicy manifests with default-deny rules, per-service allow rules documentation, network segmentation test results, and lateral movement prevention validation.",
+      "automation_level": "semi",
+      "nist_controls": ["SC-7(5)", "AC-4"],
+      "cisa_commitment": null,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-28",
+      "domain": "Secure Defaults",
+      "domain_code": "DFLT",
+      "title": "No Default Credentials in Config",
+      "description": "No default credentials such as admin/admin, root/root, password123, or other well-known credential patterns may exist in any configuration file, environment variable definition, or deployment manifest. Automated scanning must detect and flag default credential patterns in all configuration artifacts before deployment.",
+      "evidence_required": "Secret detection scan results showing zero default credential patterns in configuration files, automated CI/CD gate configuration for credential pattern detection, and configuration review confirming credential-free deployment manifests.",
+      "automation_level": "auto",
+      "nist_controls": ["IA-5(1)"],
+      "cisa_commitment": null,
+      "priority": "critical"
+    },
+    {
+      "id": "SBD-29",
+      "domain": "Secure Defaults",
+      "domain_code": "DFLT",
+      "title": "Secure Configuration Baselines",
+      "description": "All system components must be deployed with secure configuration baselines. Container images must be STIG-hardened with non-root execution, read-only root filesystems, dropped capabilities, and minimal installed packages. Application configurations must enforce DEBUG=False, restrictive CORS policies, and secure default settings for all frameworks and libraries.",
+      "evidence_required": "STIG-hardened Dockerfile configurations, container security scan results, application configuration review confirming secure defaults, and baseline compliance verification reports.",
+      "automation_level": "auto",
+      "nist_controls": ["CM-6", "CM-7"],
+      "cisa_commitment": null,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-30",
+      "domain": "Secure Defaults",
+      "domain_code": "DFLT",
+      "title": "Principle of Least Functionality",
+      "description": "Systems must be configured with only the minimum services, ports, protocols, and features required for operational functionality. Unnecessary services must be disabled or removed. Container images must use minimal base images and exclude development tools, compilers, and debugging utilities from production images.",
+      "evidence_required": "Minimal base image documentation, port and service inventory confirming only required services enabled, container image layer analysis showing no unnecessary packages, and configuration review confirming disabled non-essential features.",
+      "automation_level": "semi",
+      "nist_controls": ["CM-7"],
+      "cisa_commitment": null,
+      "priority": "medium"
+    },
+    {
+      "id": "SBD-31",
+      "domain": "CUI Compliance",
+      "domain_code": "CUI",
+      "title": "CUI Markings on All Artifacts",
+      "description": "All compliance artifacts, generated documents, code files, and configuration outputs must include CUI // SP-CTI banner markings at the top and bottom of each file. Portion markings must be applied to individual sections containing CUI as required by DoDI 5200.48 and 32 CFR Part 2002. Automated tooling must verify CUI marking presence before artifact publication.",
+      "evidence_required": "CUI marking verification scan results across all generated artifacts, sample artifacts demonstrating correct banner and portion markings, CI/CD gate configuration enforcing CUI marking presence, and marking compliance metrics.",
+      "automation_level": "auto",
+      "nist_controls": ["MP-3", "AC-16"],
+      "cisa_commitment": null,
+      "priority": "critical"
+    },
+    {
+      "id": "SBD-32",
+      "domain": "CUI Compliance",
+      "domain_code": "CUI",
+      "title": "Data Flow Classification",
+      "description": "All data flows within and across system boundaries must be classified according to data sensitivity and CUI category. A data flow diagram must map the classification level of data at each processing, storage, and transmission point. Controls must be validated as appropriate for the classification level at each point in the data flow.",
+      "evidence_required": "Data flow diagram with classification annotations at each node, data classification matrix mapping data types to sensitivity levels, and control validation records confirming appropriate protections at each classification level.",
+      "automation_level": "semi",
+      "nist_controls": ["RA-2"],
+      "cisa_commitment": null,
+      "priority": "medium"
+    },
+    {
+      "id": "SBD-33",
+      "domain": "DoD Software Assurance",
+      "domain_code": "DODI",
+      "title": "SA-24 Cyber Resiliency",
+      "description": "System architecture must incorporate cyber resiliency techniques including redundancy, failover mechanisms, graceful degradation, and automated recovery capabilities. The system must continue to provide essential functions during and after adverse cyber events. Recovery time objectives must be defined and validated through testing for each critical component.",
+      "evidence_required": "Cyber resiliency architecture documentation, redundancy and failover configuration, automated recovery mechanism implementation, recovery time objective test results, and graceful degradation test evidence.",
+      "automation_level": "semi",
+      "nist_controls": ["SA-24", "CP-2"],
+      "cisa_commitment": null,
+      "priority": "high"
+    },
+    {
+      "id": "SBD-34",
+      "domain": "DoD Software Assurance",
+      "domain_code": "DODI",
+      "title": "CERT Coding Standards",
+      "description": "All application code must comply with CERT secure coding rules and recommendations for the primary development language. Compliance must be verified through static analysis tooling configured with CERT rule sets. Violations must be triaged and resolved or documented with risk acceptance before code is promoted to production.",
+      "evidence_required": "Static analysis tool configuration with CERT rule sets enabled, CERT compliance scan results, violation triage and remediation records, and risk acceptance documentation for any unresolved findings.",
+      "automation_level": "manual",
+      "nist_controls": ["SA-15"],
+      "cisa_commitment": null,
+      "priority": "medium"
+    },
+    {
+      "id": "SBD-35",
+      "domain": "DoD Software Assurance",
+      "domain_code": "DODI",
+      "title": "SSDF Lifecycle Practices",
+      "description": "NIST SP 800-218 Secure Software Development Framework (SSDF) practices must be integrated into the software development lifecycle. This includes Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV) practice groups. Evidence of SSDF practice adoption must be maintained and mapped to specific SDLC phases.",
+      "evidence_required": "SSDF practice mapping document linking PO, PS, PW, and RV practices to SDLC phases, evidence of practice implementation for each SSDF task, and periodic SSDF compliance assessment results.",
+      "automation_level": "manual",
+      "nist_controls": ["SA-3", "SA-11"],
+      "cisa_commitment": null,
+      "priority": "medium"
+    }
+  ]
+}