{"data":{"id":"SA-17","name":"Developer Security and Privacy Architecture and Design","family":"SA","family_name":"System and Services Acquisition","withdrawn":false,"description":"Require the developer of the system, system component, or system service to produce a design specification and security and privacy architecture that:\na. Is consistent with the organization’s security and privacy architecture that is an integral part the organization’s enterprise architecture;\nb. Accurately and completely describes the required security and privacy functionality, and the allocation of controls among physical and logical components; and\nc. Expresses how individual security and privacy functions, mechanisms, and services work together to provide required security and privacy capabilities and a unified approach to protection.","supplemental_guidance":"Developer security and privacy architecture and design are directed at external developers, although they could also be applied to internal (in-house) development. In contrast, PL-8 is directed at internal developers to ensure that organizations develop a security and privacy architecture that is integrated with the enterprise architecture. The distinction between SA-17 and PL-8 is especially important when organizations outsource the development of systems, system components, or system services and when there is a requirement to demonstrate consistency with the enterprise architecture and security and privacy architecture of the organization. [ISO 15408-2], [ISO 15408-3], and [SP 800-160-1] provide information on security architecture and design, including formal policy models, security-relevant components, formal and informal correspondence, conceptually simple design, and structuring for least privilege and testing.","enhancements":[{"id":"SA-17(01)","name":"Formal Policy Model","statement":"Require the developer of the system, system component, or system service to:\na. Produce, as an integral part of the development process, a formal policy model describing the [Assignment: organization-defined elements of organizational security and privacy policy] to be enforced; and\nb. Prove that the formal policy model is internally consistent and sufficient to enforce the defined elements of the organizational security and privacy policy when implemented.","baselines":[]},{"id":"SA-17(02)","name":"Security-relevant Components","statement":"Require the developer of the system, system component, or system service to:\na. Define security-relevant hardware, software, and firmware; and\nb. Provide a rationale that the definition for security-relevant hardware, software, and firmware is complete.","baselines":[]},{"id":"SA-17(03)","name":"Formal Correspondence","statement":"Require the developer of the system, system component, or system service to:\na. Produce, as an integral part of the development process, a formal top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of exceptions, error messages, and effects;\nb. Show via proof to the extent feasible with additional informal demonstration as necessary, that the formal top-level specification is consistent with the formal policy model;\nc. Show via informal demonstration, that the formal top-level specification completely covers the interfaces to security-relevant hardware, software, and firmware;\nd. Show that the formal top-level specification is an accurate description of the implemented security-relevant hardware, software, and firmware; and\ne. Describe the security-relevant hardware, software, and firmware mechanisms not addressed in the formal top-level specification but strictly internal to the security-relevant hardware, software, and firmware.","baselines":[]},{"id":"SA-17(04)","name":"Informal Correspondence","statement":"Require the developer of the system, system component, or system service to:\na. Produce, as an integral part of the development process, an informal descriptive top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of exceptions, error messages, and effects;\nb. Show via [Selection (one): informal demonstration; convincing argument with formal methods as feasible] that the descriptive top-level specification is consistent with the formal policy model;\nc. Show via informal demonstration, that the descriptive top-level specification completely covers the interfaces to security-relevant hardware, software, and firmware;\nd. Show that the descriptive top-level specification is an accurate description of the interfaces to security-relevant hardware, software, and firmware; and\ne. Describe the security-relevant hardware, software, and firmware mechanisms not addressed in the descriptive top-level specification but strictly internal to the security-relevant hardware, software, and firmware.","baselines":[]},{"id":"SA-17(05)","name":"Conceptually Simple Design","statement":"Require the developer of the system, system component, or system service to:\na. Design and structure the security-relevant hardware, software, and firmware to use a complete, conceptually simple protection mechanism with precisely defined semantics; and\nb. Internally structure the security-relevant hardware, software, and firmware with specific regard for this mechanism.","baselines":[]},{"id":"SA-17(06)","name":"Structure for Testing","statement":"Require the developer of the system, system component, or system service to structure security-relevant hardware, software, and firmware to facilitate testing.","baselines":[]},{"id":"SA-17(07)","name":"Structure for Least Privilege","statement":"Require the developer of the system, system component, or system service to structure security-relevant hardware, software, and firmware to facilitate controlling access with least privilege.","baselines":[]},{"id":"SA-17(08)","name":"Orchestration","statement":"Design [Assignment: organization-defined critical systems or system components] with coordinated behavior to implement the following capabilities: [Assignment: organization-defined capabilities, by system or component].","baselines":[]},{"id":"SA-17(09)","name":"Design Diversity","statement":"Use different designs for [Assignment: organization-defined critical systems or system components] to satisfy a common set of requirements or to provide equivalent functionality.","baselines":[]}],"baseline_low":false,"baseline_moderate":false,"baseline_high":true,"nist_800_53":{"rev5":{"id":"SA-17","name":"Developer Security and Privacy Architecture and Design","description":"Require the developer of the system, system component, or system service to produce a design specification and security and privacy architecture that:\na. Is consistent with the organization’s security and privacy architecture that is an integral part the organization’s enterprise architecture;\nb. Accurately and completely describes the required security and privacy functionality, and the allocation of controls among physical and logical components; and\nc. Expresses how individual security and privacy functions, mechanisms, and services work together to provide required security and privacy capabilities and a unified approach to protection.","discussion":"Developer security and privacy architecture and design are directed at external developers, although they could also be applied to internal (in-house) development. In contrast, PL-8 is directed at internal developers to ensure that organizations develop a security and privacy architecture that is integrated with the enterprise architecture. The distinction between SA-17 and PL-8 is especially important when organizations outsource the development of systems, system components, or system services and when there is a requirement to demonstrate consistency with the enterprise architecture and security and privacy architecture of the organization. [ISO 15408-2], [ISO 15408-3], and [SP 800-160-1] provide information on security architecture and design, including formal policy models, security-relevant components, formal and informal correspondence, conceptually simple design, and structuring for least privilege and testing.","related_controls":["PL-02","PL-08","PM-07","SA-03","SA-04","SA-08","SC-07"],"baseline_low":false,"baseline_moderate":false,"baseline_high":true,"baseline_privacy":false,"new_in_rev5":false,"changes_from_rev4":"No significant changes from Rev 4."}},"compliance_mappings":{"iso_27001_2022":["A.8.25","A.8.27","A.8.28"],"iso_27002_2022":["8.25","8.27"],"cobit_2019":["APO03","BAI03"],"pci_dss_v4":["6.2"],"nist_csf_2":["ID.RA-09","PR.PS-06"],"cis_controls_v8":["CIS 16","CIS 16.10","CIS 16.14"],"soc2_tsc":[],"finos_ccc":[],"iso_42001_2023":[],"iec_62443":[],"asd_e8":[],"nis2":[],"apra_cps_234":[],"mas_trm":["5","6"],"pra_op_resilience":[],"bsi_grundschutz":[],"anssi":[],"osfi_b13":[],"finma_circular":[],"gdpr":[],"dora":[],"bio2":["8.25","8.27"],"rbi_csf":["Annex1.6"],"fisc":["FISC.O10","FISC.T1","FISC.T6"],"lgpd_bcb":[],"hkma_tme1":["TME1.3.2","TME1.7.3"],"mlps_2":["8.1.2.3","8.1.3.6","8.1.4.6"],"dnb_good_practice":["DNB.2.1"],"cra":["CRA.I.1"],"swift_cscf":[],"cbb_tm":["TM-7"],"cbuae":["CR-6"],"nca_ecc":["1-6"],"qatar_nia":["SD"],"sama_csf":["1.4","3.2"],"uae_ia":["T10"],"bog_cisd":["CISD-SDLC"],"bom_ctrm":["3.1","3.11"],"cbe_csf":["CTO-4"],"cbn_csf":["Part5.1"],"sa_js2":["JS2-SA"],"bcbs_239":["Principle 2","Principle 6"],"bot_cyber":["Ch2.5","Ch6.2"],"eba_ict":["3.6.2"],"ffiec_is":["II.C.2","II.C.17"],"iosco_cyber":["PROT-6"],"nydfs_500":["500.8"],"sebi_cscrf":["PR.AS"],"nerc_cip":[],"nrc_73_54":[],"tsa_psd":["SD-2 Sec F"],"ieee_1686":[],"ferc_cip":[],"doe_c2m2":["ARCHITECTURE"],"api_1164":[],"awia":[],"iaea_nss":[],"pci_pts":["F"],"fips_140":["FIPS 140-3 §7.2"],"cbest":[],"tiber_eu":[],"pci_hsm":[],"common_criteria":["CC Part 1 — ST","CC Part 3 — SAR"],"isae_3402":["Clause 9"],"fca_sysc_13":[],"fda_21_cfr_11":["§11.10(a)"],"fda_cyber":["SPDF-1","SPDF-3","TM-2"],"hitrust_csf":["10.b","10.d"],"iso_27799":["14.2"],"lloyds_ms":["BP2.1"],"naic_ds":[],"nhs_dspt":[],"pra_ss1_23":["P3.1","P3.5"],"solvency_ii":["EIOPA-ICT-4.11"],"owasp_masvs_v2":[],"csa_ccm_v4":[],"csa_aicm":[],"ccss_v9":[],"mica":[],"basel_sco60":["SCO60.51"],"bssc":[],"sec_custody_digital":[],"dpdpa":[]},"attack_techniques":[{"id":"T1078","name":"Valid Accounts","tactics":["defense-evasion","initial-access","persistence","privilege-escalation"],"mapping_type":"mitigates","mapping_rationale":"Requiring developers to design security architectures with proper authentication, least privilege, and account management controls reduces the attack surface for valid account exploitation by building credential protections into system design."},{"id":"T1482","name":"Domain Trust Discovery","tactics":["discovery"],"mapping_type":"mitigates","mapping_rationale":"Developer security architecture requirements that specify trust boundary isolation, domain trust minimization, and proper inter-domain authentication reduce adversary ability to discover and exploit domain trust relationships."},{"id":"T1078.001","name":"Default Accounts","tactics":["defense-evasion","initial-access","persistence","privilege-escalation"],"mapping_type":"mitigates","mapping_rationale":"Security architecture requirements mandating elimination of default accounts, unique credential provisioning, and secure-by-design authentication directly prevent adversary exploitation of unchanged default credentials."},{"id":"T1078.003","name":"Local Accounts","tactics":["defense-evasion","initial-access","persistence","privilege-escalation"],"mapping_type":"mitigates","mapping_rationale":"Developer security architecture requiring centralized identity management, elimination of local-only accounts where possible, and strong local authentication design reduces the attack surface for local account exploitation."},{"id":"T1078.004","name":"Cloud Accounts","tactics":["defense-evasion","initial-access","persistence","privilege-escalation"],"mapping_type":"mitigates","mapping_rationale":"Security architecture requirements for cloud deployments—including federated identity, conditional access, and least-privilege IAM design—reduce adversary ability to exploit cloud account vulnerabilities."},{"id":"T1134.005","name":"SID-History Injection","tactics":["defense-evasion","privilege-escalation"],"mapping_type":"mitigates","mapping_rationale":"Developer security architecture that designs proper SID filtering, eliminates unnecessary trust relationships, and implements domain isolation prevents SID-History injection by removing the architectural conditions that enable it."},{"id":"T1574.002","name":"DLL Side-Loading","tactics":["defense-evasion","persistence","privilege-escalation"],"mapping_type":"mitigates","mapping_rationale":"Security architecture requirements mandating proper DLL search order configuration, manifest-based loading, and elimination of side-loading opportunities prevent DLL side-loading by designing out the vulnerable loading patterns."}],"metadata":{"last_reviewed":"2026-10-03","review_notes":"Generated from NIST SP 800-53 Rev 5 with compliance mappings from framework-coverage data 2026-10-03: nist_csf_2 ID.RA-09 added from NIST's CSF 2.0 to SP 800-53 Rev 5.2.0 crosswalk (OLIR entry 186), which OSA's mapping now takes as its base.","mapping_status":"complete"},"function":"preventative","used_by_patterns":["SP-040","SP-053"]}}