| name | SA-17_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: |
| category | configuration |
| version | 5.2.0 |
| author | cyberstrike-official |
| tags | ["nist","sp800-53","rev5","sa-17","sa"] |
| tech_stack | ["any"] |
| cwe_ids | ["CWE-16"] |
| chains_with | ["PL-2","PL-8","PM-7","SA-3","SA-4","SA-8","SC-7"] |
| prerequisites | [] |
| severity_boost | {"PL-2":"Chain with PL-2 for comprehensive security coverage","PL-8":"Chain with PL-8 for comprehensive security coverage","PM-7":"Chain with PM-7 for comprehensive security coverage"} |
SA-17 Developer Security and Privacy Architecture and Design
High-Level Description
Family: System and Services Acquisition (SA)
Framework: NIST SP 800-53 Rev 5
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.
What to Check
How to Test
Step 1: Review Documentation
Examine the System Security Plan (SSP) and related artifacts for SA-17 implementation details. Verify the organization has documented how this control is satisfied.
Step 2: Validate Implementation
# For cloud environments, use cloud-audit-mcp tools
# For on-premises, review system configurations directly
# Example: Check if account management policies exist
grep -r "account.management\|access.control" /etc/security/ 2>/dev/null
Step 3: Test Operating Effectiveness
Verify the control is actively functioning, not just documented. Check logs, configurations, and operational evidence.
Tools
| Tool | Purpose | Usage |
|---|
| Manual Review | Documentation and interview-based |
