CWE · MITRE source
CWE-657Violation of Secure Design Principles
The product violates well-established principles for secure design.
This can introduce resultant weaknesses or make it easier for developers to introduce related weaknesses during implementation. Because code is centered around design, it can be resource-intensive to fix design problems.
Last updated: 09 May 2026 03:25 UTC
NIST 800-53 r5 controls that address this weakness (32)AI
Showing the 15 most specific. Generic controls that address many weakness types are collapsed below.
| Control | Title | Family | Why it addresses this CWE |
|---|---|---|---|
PM-11 | Mission and Business Process Definition | PM | Directly requires incorporating security and privacy considerations into the definition of mission/business processes, preventing violations of secure design principles at the organizational level. |
PM-13 | Security and Privacy Workforce | PM | The program explicitly teaches secure design principles, decreasing violations of those principles. |
PM-2 | Information Security Program Leadership Role | PM | A senior officer with mission responsibility promotes adherence to secure design principles throughout the organization. |
SA-1 | Policy and Procedures | SA | Acquisition policy and procedures can explicitly require adherence to secure design and engineering principles during system and service purchases. |
SA-15 | Development Process, Standards, and Tools | SA | Directly requires a documented process that explicitly addresses security requirements and uses reviewed standards, preventing violations of secure design principles. |
SA-17 | Developer Security and Privacy Architecture and Design | SA | Enforces production of a design consistent with secure architecture principles and enterprise goals, directly addressing violation of secure design principles. |
PL-1 | Policy and Procedures | PL | Documented policy with defined scope, roles, responsibilities, and periodic review directly enforces secure design principles and management commitment. |
PL-10 | Baseline Selection | PL | Baseline selection enforces adherence to established secure-design principles rather than ad-hoc or insufficient control choices. |
PL-2 | System Security and Privacy Plans | PL | Requires risk determinations for architecture/design decisions, tailoring rationale, and alignment with enterprise architecture to avoid violations of secure design principles. |
SC-1 | Policy and Procedures | SC | Mandates documented policies consistent with secure design principles, standards, and guidelines, directly reducing violations from undefined or ad-hoc protection approaches. |
SC-29 | Heterogeneity | SC | Directly implements the secure design principle of diversity, preventing homogeneous monocultures that share identical weaknesses. |
SC-47 | Alternate Communications Paths | SC | Mandating redundant paths corrects the design-level omission of single points of failure for security-critical functions. |
CA-1 | Policy and Procedures | CA | Mandating the policy be consistent with laws, standards, and guidelines enforces secure design principles in security governance and oversight. |
CA-5 | Plan of Action and Milestones | CA | Deficiencies violating secure design principles are tracked and corrected through planned actions, limiting attacker opportunities from design flaws. |
RA-1 | Policy and Procedures | RA | Formal risk assessment policy and procedures directly enforce consistent application of secure design principles across the organization. |
Show 17 more broadly-applicable controls
PM-28 | Risk Framing | PM | Documenting assumptions, constraints, priorities, trade-offs, and risk tolerance directly supports adherence to secure design principles rather than allowing unexamined risk decisions to produce violations. |
PM-3 | Information Security and Privacy Resources | PM | Requiring security resources in capital planning supports adherence to secure design principles throughout the system lifecycle. |
PM-4 | Plan of Action and Milestones Process | PM | Mandates a repeatable, risk-aligned process for planning and executing security improvements, directly countering ad-hoc or absent secure management practices. |
PM-7 | Enterprise Architecture | PM | The control requires explicit consideration of secure design principles during architecture development, directly countering violation of those principles. |
PM-9 | Risk Management Strategy | PM | Risk management strategy explicitly incorporates secure design principles and requires periodic updates to address design violations. |
SA-2 | Allocation of Resources | SA | Explicitly requires security/privacy to be incorporated into mission/business process planning and capital budgeting, directly countering violations of secure design principles that occur when security is treated as an afterthought. |
SA-23 | Specialization | SA | Specialization directly applies secure design principles (economy of mechanism, attack-surface reduction) by limiting critical functions to purpose-built components. |
SA-24 | Design For Cyber Resiliency | SA | Explicitly requires defining and implementing cyber resiliency design principles as part of systems engineering, directly preventing violations of secure design principles. |
SA-3 | System Development Life Cycle | SA | The control explicitly requires adoption of an SDLC that incorporates security considerations, directly preventing violation of established secure design principles. |
SA-8 | Security and Privacy Engineering Principles | SA | Control explicitly requires application of secure design principles throughout the lifecycle. |
PL-3 | System Security Plan Update | PL | Regular SSP updates force review of whether the system's evolving design continues to follow documented secure design principles after changes. |
PL-7 | Concept of Operations | PL | Developing and maintaining a security-focused CONOPS constitutes explicit adherence to secure design and operational principles, directly countering violations of those principles. |
PL-8 | Security and Privacy Architectures | PL | Developing and maintaining documented security architectures enforces secure design principles and prevents violations at the system level. |
RA-7 | Risk Response | RA | Audits and assessments commonly surface violations of secure design principles; formal risk-response processes ensure such findings are remediated according to risk tolerance, reducing the window for exploitation. |
AT-1 | Policy and Procedures | AT | Establishing and updating awareness policy promotes adherence to secure design principles through ongoing training, preventing related violations. |
MA-1 | Policy and Procedures | MA | Documenting, disseminating, and periodically reviewing maintenance policies and procedures enforces core secure design principles for system maintenance activities. |
SI-1 | Policy and Procedures | SI | Requiring a formal integrity policy enforces secure design principles such as least privilege and separation of duties across the organization. |
Top CVEs of this weakness type, ranked by Risk Priority
| CVE | Risk | CVSS | EPSS | Published |
|---|---|---|---|---|
CVE-2026-39888 | 2.0 | 9.9 | 0.0010 | 2026-04-08 |
CVE-2024-26139 | 1.7 | 8.3 | 0.0016 | 2024-05-23 |
CVE-2019-0061 | 1.6 | 7.8 | 0.0004 | 2019-10-09 |
CVE-2023-29320 | 1.6 | 7.8 | 0.0011 | 2023-08-10 |
CVE-2026-30792 | 1.6 | 8.1 | 0.0007 | 2026-03-05 |
CVE-2021-28583 | 1.5 | 7.5 | 0.0053 | 2021-06-28 |
CVE-2023-52714 | 1.5 | 7.5 | 0.0009 | 2024-04-07 |
CVE-2022-28244 | 1.3 | 6.3 | 0.0138 | 2022-05-11 |
CVE-2024-33849 | 1.3 | 6.5 | 0.0008 | 2024-05-28 |
CVE-2024-57957 | 1.3 | 6.6 | 0.0010 | 2025-02-06 |
CVE-2025-24887 | 1.3 | 6.3 | 0.0022 | 2025-04-30 |
CVE-2017-6032 | 1.1 | 5.3 | 0.0015 | 2017-06-30 |
CVE-2019-5478 | 1.1 | 5.5 | 0.0002 | 2019-09-03 |
CVE-2020-8133 | 1.1 | 5.3 | 0.0017 | 2020-11-09 |
CVE-2021-36061 | 1.1 | 5.4 | 0.0097 | 2021-09-01 |
CVE-2022-30683 | 1.1 | 5.3 | 0.0025 | 2022-09-16 |
CVE-2019-15611 | 1.0 | 4.9 | 0.0066 | 2020-02-04 |
CVE-2025-54255 | 0.8 | 4.0 | 0.0006 | 2025-09-09 |
CVE-2021-44714 | 0.5 | 2.5 | 0.0053 | 2022-01-14 |