Common Weakness Enumeration (CWE)

The product or code uses machine-dependent functionality, but it does not sufficiently encapsulate or isolate this functionality from the rest of the code.

The code contains a callable, block, or other code element in which the same variable is used to control more than one unique task or store more than one instance of data.

The product's design documentation does not adequately describe control flow, data flow, system initialization, relationships between tasks, components, rationales, or other important aspects of the design.

The product's documentation does not adequately define inputs, outputs, or system/software interfaces.

The source code contains whitespace that is inconsistent across the code or does not follow expected standards for the product.

The source code contains elements such as source files that do not consistently provide a prologue or header that has been standardized for the project.

The code contains a function or method whose signature and/or associated inline documentation does not sufficiently describe the callable's inputs, outputs, side effects, assumptions, or return codes.

The code is too complex, as calculated using a well-defined, quantitative measure.

The code contains McCabe cyclomatic complexity that exceeds a desirable maximum.

The code is structured in a way that a Halstead complexity measure exceeds a desirable maximum.

The product uses too much self-modifying code.

The source code declares a variable in one scope, but the variable is only used within a narrower scope.

The code is compiled without sufficient warnings enabled, which may prevent the detection of subtle bugs or quality issues.

The product uses a function, library, or third party component that has been explicitly prohibited, whether by the developer or the customer.

The System-on-Chip (SoC) does not have unique, immutable identifiers for each of its components.

The product enables components that contain untrusted firmware before memory and fabric access controls have been enabled.

The reserved bits in a hardware design are not disabled prior to production. Typically, reserved bits are used for future capabilities and should not support any functional logic in the design. However, designers might covertly use these bits to debug or further develop new capabilities in production hardware. Adversaries with access to these bits will write to them in hopes of compromising hardware state.

The product manages resources or behaves in a way that indirectly creates a new, distinct resource that can be used by attackers in violation of the intended policy.

Register lock bit protection disables changes to system configuration once the bit is set. Some of the protected registers or lock bits become programmable after power state transitions (e.g., Entry and wake from low power sleep modes) causing the system configuration to be changeable.

The code uses boxed primitives, which may introduce inefficiencies into performance-critical operations.

The hardware product does not properly clear sensitive information from built-in registers when the user of the hardware block changes.

Access to security-sensitive information stored in fuses is not limited during debug.

The security-sensitive hardware module contains semiconductor defects.

The product provides an application for administrators to manage parts of the underlying operating system, but the application does not accurately identify all of the relevant entities or resources that exist in the OS; that is, the application's model of the OS's state is inconsistent with the OS's actual state.

The CPU is not configured to provide hardware support for exclusivity of write and execute operations on memory. This allows an attacker to execute data from all of memory.