Common Weakness Enumeration (CWE)

The product uses an unnecessarily complex internal representation for its data structures or interrelationships between those structures.

The product contains an index range scan for a large data table, but the scan can cover a large number of rows.

The product uses a loop with a control flow condition based on a value that is updated within the body of the loop.

The product implements a Singleton design pattern but does not use appropriate locking or other synchronization mechanism to ensure that the singleton class is only instantiated once.

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.