Common Weakness Enumeration (CWE)

The product uses a storable data element that does not have all of the associated functions or methods that are necessary to support comparison.

The code contains a data element with a pointer that does not have an associated copy or constructor method.

The product's code, documentation, or other artifacts do not consistently use the same naming conventions for variables, callables, groups of related callables, I/O capabilities, data types, file names, or similar types of elements.

The product uses automatically-generated code that cannot be executed without a specific runtime support component.

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.