CodeSonar includes a large number of warning classes that support checking for rules and recommendations in the following coding standards, published by the CERT Division of the Carnegie Mellon University Software Engineering Institute (SEI).
Relevant Warning Classes
The following accordion below show the CodeSonar warning classes that are associated with the rules and recommendations in the SEI CERT Coding Standard rules.
Mapping Definition
The table below show classes from our broad mapping which for a given warning class and category kind combines categories from four sources:
- The close mapping for the class.
- Other categories of that kind that are related to the class in a meaningful way, but not eligible for the close mapping. Usually this indicates a substantial overlap between category and warning class, but overlap that cannot be characterized as a subset or superset relationship.
- It the category kind is hierarchical (of the current category taxonomies, only We has this property): tor all categories trom sources 1 and 2, all ancestors in the taxonomy hierarchy
- In a small number of cases, all descendants of a hierarchical category source 1 or 2 are also applicable to the class. In these cases the descendants are also added to the broad mapping
CERT C
Mapping Summary
| Supported | All | Percent Coverage | |
|---|---|---|---|
| All | 194 | 306 | 63.4% |
| Rule | 106 | 120 | 88.3% |
| Recommendation | 88 | 186 | 47.3% |
Mapping Detail
| Rule | Rule Name | Category | Supported |
|---|---|---|---|
| CERT-C:API00-C | Functions should validate their parameters | Recommendation | Yes |
| CERT-C:API01-C | Avoid laying out strings in memory directly before sensitive data | Recommendation | No |
| CERT-C:API02-C | Functions that read or write to or from an array should take an argument to specify the source or target size | Recommendation | No |
| CERT-C:API03-C | Create consistent interfaces and capabilities across related functions | Recommendation | No |
| CERT-C:API04-C | Provide a consistent and usable error-checking mechanism | Recommendation | No |
| CERT-C:API05-C | Use conformant array parameters | Recommendation | No |
| CERT-C:API07-C | Enforce type safety | Recommendation | Yes |
| CERT-C:API09-C | Compatible values should have the same type | Recommendation | No |
| CERT-C:API10-C | APIs should have security options enabled by default | Recommendation | No |
| CERT-C:ARR00-C | Understand how arrays work | Recommendation | Yes |
| CERT-C:ARR01-C | Do not apply the sizeof operator to a pointer when taking the size of an array | Recommendation | Yes |
| CERT-C:ARR02-C | Explicitly specify array bounds, even if implicitly defined by an initializer | Recommendation | No |
| CERT-C:ARR30-C | Do not form or use out-of-bounds pointers or array subscripts | Rule | Yes |
| CERT-C:ARR32-C | Ensure size arguments for variable length arrays are in a valid range | Rule | Yes |
| CERT-C:ARR36-C | Do not subtract or compare two pointers that do not refer to the same array | Rule | Yes |
| CERT-C:ARR37-C | Do not add or subtract an integer to a pointer to a non-array object | Rule | Yes |
| CERT-C:ARR38-C | Guarantee that library functions do not form invalid pointers | Rule | Yes |
| CERT-C:ARR39-C | Do not add or subtract a scaled integer to a pointer | Rule | Yes |
| CERT-C:CON01-C | Acquire and release synchronization primitives in the same module, at the same level of abstraction | Recommendation | Yes |
| CERT-C:CON02-C | Do not use volatile as a synchronization primitive | Recommendation | Yes |
| CERT-C:CON03-C | Ensure visibility when accessing shared variables | Recommendation | No |
| CERT-C:CON04-C | Join or detach threads even if their exit status is unimportant | Recommendation | No |
| CERT-C:CON05-C | Do not perform operations that can block while holding a lock | Recommendation | Yes |
| CERT-C:CON06-C | Ensure that every mutex outlives the data it protects | Recommendation | Yes |
| CERT-C:CON07-C | Ensure that compound operations on shared variables are atomic | Recommendation | Yes |
| CERT-C:CON08-C | Do not assume that a group of calls to independently atomic methods is atomic | Recommendation | Yes |
| CERT-C:CON09-C | Avoid the ABA problem when using lock-free algorithms | Recommendation | No |
| CERT-C:CON30-C | Clean up thread-specific storage | Rule | Yes |
| CERT-C:CON31-C | Do not destroy a mutex while it is locked | Rule | Yes |
| CERT-C:CON32-C | Prevent data races when accessing bit-fields from multiple threads | Rule | Yes |
| CERT-C:CON33-C | Avoid race conditions when using library functions | Rule | Yes |
| CERT-C:CON34-C | Declare objects shared between threads with appropriate storage durations | Rule | Yes |
| CERT-C:CON35-C | Avoid deadlock by locking in a predefined order | Rule | Yes |
| CERT-C:CON36-C | Wrap functions that can spuriously wake up in a loop | Rule | Yes |
| CERT-C:CON37-C | Do not call signal() in a multithreaded program | Rule | Yes |
| CERT-C:CON38-C | Preserve thread safety and liveness when using condition variables | Rule | Yes |
| CERT-C:CON39-C | Do not join or detach a thread that was previously joined or detached | Rule | Yes |
| CERT-C:CON40-C | Do not refer to an atomic variable twice in an expression | Rule | Yes |
| CERT-C:CON41-C | Wrap functions that can fail spuriously in a loop | Rule | Yes |
| CERT-C:CON43-C | Do not allow data races in multithreaded code | Rule | Yes |
| CERT-C:DCL00-C | Const-qualify immutable objects | Recommendation | Yes |
| CERT-C:DCL01-C | Do not reuse variable names in subscopes | Recommendation | Yes |
| CERT-C:DCL02-C | Use visually distinct identifiers | Recommendation | Yes |
| CERT-C:DCL03-C | Use a static assertion to test the value of a constant expression | Recommendation | No |
| CERT-C:DCL04-C | Do not declare more than one variable per declaration | Recommendation | Yes |
| CERT-C:DCL05-C | Use typedefs of non-pointer types only | Recommendation | Yes |
| CERT-C:DCL06-C | Use meaningful symbolic constants to represent literal values | Recommendation | No |
| CERT-C:DCL07-C | Include the appropriate type information in function declarators | Recommendation | Yes |
| CERT-C:DCL08-C | Properly encode relationships in constant definitions | Recommendation | No |
| CERT-C:DCL09-C | Declare functions that return errno with a return type of errno_t | Recommendation | No |
| CERT-C:DCL10-C | Maintain the contract between the writer and caller of variadic functions | Recommendation | No |
| CERT-C:DCL11-C | Understand the type issues associated with variadic functions | Recommendation | Yes |
| CERT-C:DCL12-C | Implement abstract data types using opaque types | Recommendation | No |
| CERT-C:DCL13-C | Declare function parameters that are pointers to values not changed by the function as const | Recommendation | Yes |
| CERT-C:DCL15-C | Declare file-scope objects or functions that do not need external linkage as static | Recommendation | Yes |
| CERT-C:DCL16-C | Use "L," not "l," to indicate a long value | Recommendation | Yes |
| CERT-C:DCL17-C | Beware of miscompiled volatile-qualified variables | Recommendation | Yes |
| CERT-C:DCL18-C | Do not begin integer constants with 0 when specifying a decimal value | Recommendation | Yes |
| CERT-C:DCL19-C | Minimize the scope of variables and functions | Recommendation | Yes |
| CERT-C:DCL20-C | Explicitly specify void when a function accepts no arguments | Recommendation | Yes |
| CERT-C:DCL21-C | Understand the storage of compound literals | Recommendation | No |
| CERT-C:DCL22-C | Use volatile for data that cannot be cached | Recommendation | No |
| CERT-C:DCL23-C | Guarantee that mutually visible identifiers are unique | Recommendation | Yes |
| CERT-C:DCL30-C | Declare objects with appropriate storage durations | Rule | Yes |
| CERT-C:DCL31-C | Declare identifiers before using them | Rule | No |
| CERT-C:DCL36-C | Do not declare an identifier with conflicting linkage classifications | Rule | Yes |
| CERT-C:DCL37-C | Do not declare or define a reserved identifier | Rule | Yes |
| CERT-C:DCL38-C | Use the correct syntax when declaring a flexible array member | Rule | Yes |
| CERT-C:DCL39-C | Avoid information leakage when passing a structure across a trust boundary | Rule | Yes |
| CERT-C:DCL40-C | Do not create incompatible declarations of the same function or object | Rule | Yes |
| CERT-C:DCL41-C | Do not declare variables inside a switch statement before the first case label | Rule | Yes |
| CERT-C:ENV01-C | Do not make assumptions about the size of an environment variable | Recommendation | Yes |
| CERT-C:ENV02-C | Beware of multiple environment variables with the same effective name | Recommendation | No |
| CERT-C:ENV03-C | Sanitize the environment when invoking external programs | Recommendation | No |
| CERT-C:ENV30-C | Do not modify the object referenced by the return value of certain functions | Rule | Yes |
| CERT-C:ENV31-C | Do not rely on an environment pointer following an operation that may invalidate it | Rule | Yes |
| CERT-C:ENV32-C | All exit handlers must return normally | Rule | Yes |
| CERT-C:ENV33-C | Do not call system() | Rule | Yes |
| CERT-C:ENV34-C | Do not store pointers returned by certain functions | Rule | Yes |
| CERT-C:ERR00-C | Adopt and implement a consistent and comprehensive error-handling policy | Recommendation | No |
| CERT-C:ERR01-C | Use ferror() rather than errno to check for FILE stream errors | Recommendation | No |
| CERT-C:ERR02-C | Avoid in-band error indicators | Recommendation | No |
| CERT-C:ERR03-C | Use runtime-constraint handlers when calling the bounds-checking interfaces | Recommendation | No |
| CERT-C:ERR04-C | Choose an appropriate termination strategy | Recommendation | No |
| CERT-C:ERR05-C | Application-independent code should provide error detection without dictating error handling | Recommendation | No |
| CERT-C:ERR06-C | Understand the termination behavior of assert() and abort() | Recommendation | No |
| CERT-C:ERR07-C | Prefer functions that support error checking over equivalent functions that don't | Recommendation | No |
| CERT-C:ERR30-C | Take care when reading errno | Rule | Yes |
| CERT-C:ERR32-C | Do not rely on indeterminate values of errno | Rule | No |
| CERT-C:ERR33-C | Detect and handle standard library errors | Rule | Yes |
| CERT-C:ERR34-C | Detect errors when converting a string to a number | Rule | Yes |
| CERT-C:EXP00-C | Use parentheses for precedence of operation | Recommendation | Yes |
| CERT-C:EXP02-C | Be aware of the short-circuit behavior of the logical AND and OR operators | Recommendation | No |
| CERT-C:EXP03-C | Do not assume the size of a structure is the sum of the sizes of its members | Recommendation | No |
| CERT-C:EXP05-C | Do not cast away a const qualification | Recommendation | Yes |
| CERT-C:EXP07-C | Do not diminish the benefits of constants by assuming their values in expressions | Recommendation | No |
| CERT-C:EXP08-C | Ensure pointer arithmetic is used correctly | Recommendation | Yes |
| CERT-C:EXP09-C | Use sizeof to determine the size of a type or variable | Recommendation | No |
| CERT-C:EXP10-C | Do not depend on the order of evaluation of subexpressions or the order in which side effects take place | Recommendation | Yes |
| CERT-C:EXP11-C | Do not make assumptions regarding the layout of structures with bit-fields | Recommendation | Yes |
| CERT-C:EXP12-C | Do not ignore values returned by functions | Recommendation | Yes |
| CERT-C:EXP13-C | Treat relational and equality operators as if they were nonassociative | Recommendation | No |
| CERT-C:EXP14-C | Beware of integer promotion when performing bitwise operations on integer types smaller than int | Recommendation | Yes |
| CERT-C:EXP15-C | Do not place a semicolon on the same line as an if, for, or while statement | Recommendation | Yes |
| CERT-C:EXP16-C | Do not compare function pointers to constant values | Recommendation | No |
| CERT-C:EXP19-C | Use braces for the body of an if, for, or while statement | Recommendation | No |
| CERT-C:EXP20-C | Perform explicit tests to determine success, true and false, and equality | Recommendation | No |
| CERT-C:EXP30-C | Do not depend on the order of evaluation for side effects | Rule | Yes |
| CERT-C:EXP32-C | Do not access a volatile object through a nonvolatile reference | Rule | No |
| CERT-C:EXP33-C | Do not read uninitialized memory | Rule | Yes |
| CERT-C:EXP34-C | Do not dereference null pointers | Rule | Yes |
| CERT-C:EXP35-C | Do not modify objects with temporary lifetime | Rule | Yes |
| CERT-C:EXP36-C | Do not cast pointers into more strictly aligned pointer types | Rule | Yes |
| CERT-C:EXP37-C | Call functions with the correct number and type of arguments | Rule | Yes |
| CERT-C:EXP39-C | Do not access a variable through a pointer of an incompatible type | Rule | Yes |
| CERT-C:EXP40-C | Do not modify constant objects | Rule | Yes |
| CERT-C:EXP42-C | Do not compare padding data | Rule | Yes |
| CERT-C:EXP43-C | Avoid undefined behavior when using restrict-qualified pointers | Rule | Yes |
| CERT-C:EXP44-C | Do not rely on side effects in operands to sizeof, _Alignof, or _Generic | Rule | Yes |
| CERT-C:EXP45-C | Do not perform assignments in selection statements | Rule | Yes |
| CERT-C:EXP46-C | Do not use a bitwise operator with a Boolean-like operand | Rule | Yes |
| CERT-C:EXP47-C | Do not call va_arg with an argument of the incorrect type | Rule | Yes |
| CERT-C:FIO01-C | Be careful using functions that use file names for identification | Recommendation | Yes |
| CERT-C:FIO02-C | Canonicalize path names originating from tainted sources | Recommendation | Yes |
| CERT-C:FIO03-C | Do not make assumptions about fopen() and file creation | Recommendation | Yes |
| CERT-C:FIO05-C | Identify files using multiple file attributes | Recommendation | No |
| CERT-C:FIO06-C | Create files with appropriate access permissions | Recommendation | Yes |
| CERT-C:FIO08-C | Take care when calling remove() on an open file | Recommendation | No |
| CERT-C:FIO09-C | Be careful with binary data when transferring data across systems | Recommendation | No |
| CERT-C:FIO10-C | Take care when using the rename() function | Recommendation | No |
| CERT-C:FIO11-C | Take care when specifying the mode parameter of fopen() | Recommendation | Yes |
| CERT-C:FIO13-C | Never push back anything other than one read character | Recommendation | No |
| CERT-C:FIO14-C | Understand the difference between text mode and binary mode with file streams | Recommendation | No |
| CERT-C:FIO15-C | Ensure that file operations are performed in a secure directory | Recommendation | No |
| CERT-C:FIO17-C | Do not rely on an ending null character when using fread() | Recommendation | No |
| CERT-C:FIO18-C | Never expect fwrite() to terminate the writing process at a null character | Recommendation | No |
| CERT-C:FIO19-C | Do not use fseek() and ftell() to compute the size of a regular file | Recommendation | No |
| CERT-C:FIO20-C | Avoid unintentional truncation when using fgets() or fgetws() | Recommendation | No |
| CERT-C:FIO21-C | Do not create temporary files in shared directories | Recommendation | Yes |
| CERT-C:FIO22-C | Close files before spawning processes | Recommendation | No |
| CERT-C:FIO23-C | Do not exit with unflushed data in stdout or stderr | Recommendation | No |
| CERT-C:FIO24-C | Do not open a file that is already open | Recommendation | Yes |
| CERT-C:FIO30-C | Exclude user input from format strings | Rule | Yes |
| CERT-C:FIO32-C | Do not perform operations on devices that are only appropriate for files | Rule | No |
| CERT-C:FIO34-C | Distinguish between characters read from a file and EOF or WEOF | Rule | Yes |
| CERT-C:FIO37-C | Do not assume that fgets() or fgetws() returns a nonempty string when successful | Rule | Yes |
| CERT-C:FIO38-C | Do not copy a FILE object | Rule | No |
| CERT-C:FIO39-C | Do not alternately input and output from a stream without an intervening flush or positioning call | Rule | Yes |
| CERT-C:FIO40-C | Reset strings on fgets() or fgetws() failure | Rule | Yes |
| CERT-C:FIO41-C | Do not call getc(), putc(), getwc(), or putwc() with a stream argument that has side effects | Rule | Yes |
| CERT-C:FIO42-C | Close files when they are no longer needed | Rule | Yes |
| CERT-C:FIO44-C | Only use values for fsetpos() that are returned from fgetpos() | Rule | No |
| CERT-C:FIO45-C | Avoid TOCTOU race conditions while accessing files | Rule | Yes |
| CERT-C:FIO46-C | Do not access a closed file | Rule | Yes |
| CERT-C:FIO47-C | Use valid format strings | Rule | Yes |
| CERT-C:FLP00-C | Understand the limitations of floating-point numbers | Recommendation | Yes |
| CERT-C:FLP01-C | Take care in rearranging floating-point expressions | Recommendation | No |
| CERT-C:FLP02-C | Avoid using floating-point numbers when precise computation is needed | Recommendation | No |
| CERT-C:FLP03-C | Detect and handle floating-point errors | Recommendation | No |
| CERT-C:FLP04-C | Check floating-point inputs for exceptional values | Recommendation | No |
| CERT-C:FLP05-C | Do not use denormalized numbers | Recommendation | No |
| CERT-C:FLP06-C | Convert integers to floating point for floating-point operations | Recommendation | Yes |
| CERT-C:FLP07-C | Cast the return value of a function that returns a floating-point type | Recommendation | No |
| CERT-C:FLP30-C | Do not use floating-point variables as loop counters | Rule | Yes |
| CERT-C:FLP32-C | Prevent or detect domain and range errors in math functions | Rule | Yes |
| CERT-C:FLP34-C | Ensure that floating-point conversions are within range of the new type | Rule | Yes |
| CERT-C:FLP36-C | Preserve precision when converting integral values to floating-point type | Rule | Yes |
| CERT-C:FLP37-C | Do not use object representations to compare floating-point values | Rule | Yes |
| CERT-C:INT00-C | Understand the data model used by your implementation(s) | Recommendation | No |
| CERT-C:INT01-C | Use rsize_t or size_t for all integer values representing the size of an object | Recommendation | No |
| CERT-C:INT02-C | Understand integer conversion rules | Recommendation | Yes |
| CERT-C:INT04-C | Enforce limits on integer values originating from tainted sources | Recommendation | Yes |
| CERT-C:INT05-C | Do not use input functions to convert character data if they cannot handle all possible inputs | Recommendation | Yes |
| CERT-C:INT07-C | Use only explicitly signed or unsigned char type for numeric values | Recommendation | Yes |
| CERT-C:INT08-C | Verify that all integer values are in range | Recommendation | Yes |
| CERT-C:INT09-C | Ensure enumeration constants map to unique values | Recommendation | Yes |
| CERT-C:INT10-C | Do not assume a positive remainder when using the % operator | Recommendation | No |
| CERT-C:INT12-C | Do not make assumptions about the type of a plain int bit-field when used in an expression | Recommendation | Yes |
| CERT-C:INT13-C | Use bitwise operators only on unsigned operands | Recommendation | Yes |
| CERT-C:INT14-C | Avoid performing bitwise and arithmetic operations on the same data | Recommendation | No |
| CERT-C:INT15-C | Use intmax_t or uintmax_t for formatted IO on programmer-defined integer types | Recommendation | No |
| CERT-C:INT16-C | Do not make assumptions about representation of signed integers | Recommendation | No |
| CERT-C:INT17-C | Define integer constants in an implementation-independent manner | Recommendation | No |
| CERT-C:INT18-C | Evaluate integer expressions in a larger size before comparing or assigning to that size | Recommendation | Yes |
| CERT-C:INT30-C | Ensure that unsigned integer operations do not wrap | Rule | Yes |
| CERT-C:INT31-C | Ensure that integer conversions do not result in lost or misinterpreted data | Rule | Yes |
| CERT-C:INT32-C | Ensure that operations on signed integers do not result in overflow | Rule | Yes |
| CERT-C:INT33-C | Ensure that division and remainder operations do not result in divide-by-zero errors | Rule | Yes |
| CERT-C:INT34-C | Do not shift an expression by a negative number of bits or by greater than or equal to the number of bits that exist in the operand | Rule | Yes |
| CERT-C:INT35-C | Use correct integer precisions | Rule | Yes |
| CERT-C:INT36-C | Converting a pointer to integer or integer to pointer | Rule | Yes |
| CERT-C:MEM00-C | Allocate and free memory in the same module, at the same level of abstraction | Recommendation | Yes |
| CERT-C:MEM01-C | Store a new value in pointers immediately after free() | Recommendation | Yes |
| CERT-C:MEM02-C | Immediately cast the result of a memory allocation function call into a pointer to the allocated type | Recommendation | No |
| CERT-C:MEM03-C | Clear sensitive information stored in reusable resources | Recommendation | No |
| CERT-C:MEM04-C | Beware of zero-length allocations | Recommendation | No |
| CERT-C:MEM05-C | Avoid large stack allocations | Recommendation | Yes |
| CERT-C:MEM06-C | Ensure that sensitive data is not written out to disk | Recommendation | No |
| CERT-C:MEM07-C | Ensure that the arguments to calloc(), when multiplied, do not wrap | Recommendation | Yes |
| CERT-C:MEM10-C | Define and use a pointer validation function | Recommendation | No |
| CERT-C:MEM11-C | Do not assume infinite heap space | Recommendation | Yes |
| CERT-C:MEM12-C | Consider using a goto chain when leaving a function on error when using and releasing resources | Recommendation | No |
| CERT-C:MEM30-C | Do not access freed memory | Rule | Yes |
| CERT-C:MEM31-C | Free dynamically allocated memory when no longer needed | Rule | Yes |
| CERT-C:MEM33-C | Allocate and copy structures containing a flexible array member dynamically | Rule | Yes |
| CERT-C:MEM34-C | Only free memory allocated dynamically | Rule | Yes |
| CERT-C:MEM35-C | Allocate sufficient memory for an object | Rule | Yes |
| CERT-C:MEM36-C | Do not modify the alignment of objects by calling realloc() | Rule | Yes |
| CERT-C:MSC00-C | Compile cleanly at high warning levels | Recommendation | Yes |
| CERT-C:MSC01-C | Strive for logical completeness | Recommendation | No |
| CERT-C:MSC04-C | Use comments consistently and in a readable fashion | Recommendation | No |
| CERT-C:MSC05-C | Do not manipulate time_t typed values directly | Recommendation | No |
| CERT-C:MSC06-C | Beware of compiler optimizations | Recommendation | Yes |
| CERT-C:MSC07-C | Detect and remove dead code | Recommendation | Yes |
| CERT-C:MSC09-C | Character encoding: Use subset of ASCII for safety | Recommendation | No |
| CERT-C:MSC10-C | Character encoding: UTF8-related issues | Recommendation | No |
| CERT-C:MSC11-C | Incorporate diagnostic tests using assertions | Recommendation | Yes |
| CERT-C:MSC12-C | Detect and remove code that has no effect or is never executed | Recommendation | Yes |
| CERT-C:MSC13-C | Detect and remove unused values | Recommendation | Yes |
| CERT-C:MSC14-C | Do not introduce unnecessary platform dependencies | Recommendation | No |
| CERT-C:MSC15-C | Do not depend on undefined behavior | Recommendation | Yes |
| CERT-C:MSC17-C | Finish every set of statements associated with a case label with a break statement | Recommendation | Yes |
| CERT-C:MSC18-C | Be careful while handling sensitive data, such as passwords, in program code | Recommendation | Yes |
| CERT-C:MSC19-C | For functions that return an array, prefer returning an empty array over a null value | Recommendation | No |
| CERT-C:MSC20-C | Do not use a switch statement to transfer control into a complex block | Recommendation | Yes |
| CERT-C:MSC21-C | Use robust loop termination conditions | Recommendation | Yes |
| CERT-C:MSC22-C | Use the setjmp(), longjmp() facility securely | Recommendation | Yes |
| CERT-C:MSC23-C | Beware of vendor-specific library and language differences | Recommendation | Yes |
| CERT-C:MSC24-C | Do not use deprecated or obsolescent functions | Recommendation | Yes |
| CERT-C:MSC25-C | Do not use insecure or weak cryptographic algorithms | Recommendation | Yes |
| CERT-C:MSC30-C | Do not use the rand() function for generating pseudorandom numbers | Rule | Yes |
| CERT-C:MSC32-C | Properly seed pseudorandom number generators | Rule | Yes |
| CERT-C:MSC33-C | Do not pass invalid data to the asctime() function | Rule | Yes |
| CERT-C:MSC37-C | Ensure that control never reaches the end of a non-void function | Rule | Yes |
| CERT-C:MSC38-C | Do not treat a predefined identifier as an object if it might only be implemented as a macro | Rule | Yes |
| CERT-C:MSC39-C | Do not call va_arg() on a va_list that has an indeterminate value | Rule | Yes |
| CERT-C:MSC40-C | Do not violate constraints | Rule | No |
| CERT-C:MSC41-C | Never hard code sensitive information | Rule | Yes |
| CERT-C:POS01-C | Check for the existence of links when dealing with files | Recommendation | No |
| CERT-C:POS02-C | Follow the principle of least privilege | Recommendation | No |
| CERT-C:POS04-C | Avoid using PTHREAD_MUTEX_NORMAL type mutex locks | Recommendation | No |
| CERT-C:POS05-C | Limit access to files by creating a jail | Recommendation | Yes |
| CERT-C:POS30-C | Use the readlink() function properly | Rule | Yes |
| CERT-C:POS34-C | Do not call putenv() with a pointer to an automatic variable as the argument | Rule | Yes |
| CERT-C:POS35-C | Avoid race conditions while checking for the existence of a symbolic link | Rule | No |
| CERT-C:POS36-C | Observe correct revocation order while relinquishing privileges | Rule | No |
| CERT-C:POS37-C | Ensure that privilege relinquishment is successful | Rule | No |
| CERT-C:POS38-C | Beware of race conditions when using fork and file descriptors | Rule | Yes |
| CERT-C:POS39-C | Use the correct byte ordering when transferring data between systems | Rule | No |
| CERT-C:POS44-C | Do not use signals to terminate threads | Rule | Yes |
| CERT-C:POS47-C | Do not use threads that can be canceled asynchronously | Rule | No |
| CERT-C:POS48-C | Do not unlock or destroy another POSIX thread's mutex | Rule | Yes |
| CERT-C:POS49-C | When data must be accessed by multiple threads, provide a mutex and guarantee no adjacent data is also accessed | Rule | Yes |
| CERT-C:POS50-C | Declare objects shared between POSIX threads with appropriate storage durations | Rule | No |
| CERT-C:POS51-C | Avoid deadlock with POSIX threads by locking in predefined order | Rule | Yes |
| CERT-C:POS52-C | Do not perform operations that can block while holding a POSIX lock | Rule | Yes |
| CERT-C:POS53-C | Do not use more than one mutex for concurrent waiting operations on a condition variable | Rule | No |
| CERT-C:POS54-C | Detect and handle POSIX library errors | Rule | Yes |
| CERT-C:PRE00-C | Prefer inline or static functions to function-like macros | Recommendation | Yes |
| CERT-C:PRE01-C | Use parentheses within macros around parameter names | Recommendation | No |
| CERT-C:PRE02-C | Macro replacement lists should be parenthesized | Recommendation | Yes |
| CERT-C:PRE03-C | Prefer typedefs to defines for encoding non-pointer types | Recommendation | No |
| CERT-C:PRE04-C | Do not reuse a standard header file name | Recommendation | No |
| CERT-C:PRE05-C | Understand macro replacement when concatenating tokens or performing stringification | Recommendation | Yes |
| CERT-C:PRE06-C | Enclose header files in an include guard | Recommendation | No |
| CERT-C:PRE07-C | Avoid using repeated question marks | Recommendation | No |
| CERT-C:PRE08-C | Guarantee that header file names are unique | Recommendation | No |
| CERT-C:PRE09-C | Do not replace secure functions with deprecated or obsolescent functions | Recommendation | No |
| CERT-C:PRE10-C | Wrap multistatement macros in a do-while loop | Recommendation | No |
| CERT-C:PRE11-C | Do not conclude macro definitions with a semicolon | Recommendation | Yes |
| CERT-C:PRE12-C | Do not define unsafe macros | Recommendation | No |
| CERT-C:PRE13-C | Use the Standard predefined macros to test for versions and features. | Recommendation | No |
| CERT-C:PRE30-C | Do not create a universal character name through concatenation | Rule | Yes |
| CERT-C:PRE31-C | Avoid side effects in arguments to unsafe macros | Rule | Yes |
| CERT-C:PRE32-C | Do not use preprocessor directives in invocations of function-like macros | Rule | Yes |
| CERT-C:SIG00-C | Mask signals handled by noninterruptible signal handlers | Recommendation | Yes |
| CERT-C:SIG01-C | Understand implementation-specific details regarding signal handler persistence | Recommendation | Yes |
| CERT-C:SIG02-C | Avoid using signals to implement normal functionality | Recommendation | Yes |
| CERT-C:SIG30-C | Call only asynchronous-safe functions within signal handlers | Rule | Yes |
| CERT-C:SIG31-C | Do not access shared objects in signal handlers | Rule | Yes |
| CERT-C:SIG34-C | Do not call signal() from within interruptible signal handlers | Rule | Yes |
| CERT-C:SIG35-C | Do not return from a computational exception signal handler | Rule | Yes |
| CERT-C:STR00-C | Represent characters using an appropriate type | Recommendation | Yes |
| CERT-C:STR01-C | Adopt and implement a consistent plan for managing strings | Recommendation | No |
| CERT-C:STR02-C | Sanitize data passed to complex subsystems | Recommendation | Yes |
| CERT-C:STR03-C | Do not inadvertently truncate a string | Recommendation | Yes |
| CERT-C:STR04-C | Use plain char for characters in the basic character set | Recommendation | Yes |
| CERT-C:STR05-C | Use pointers to const when referring to string literals | Recommendation | Yes |
| CERT-C:STR06-C | Do not assume that strtok() leaves the parse string unchanged | Recommendation | No |
| CERT-C:STR07-C | Use the bounds-checking interfaces for string manipulation | Recommendation | Yes |
| CERT-C:STR08-C | Use managed strings for development of new string manipulation code | Recommendation | No |
| CERT-C:STR09-C | Don't assume numeric values for expressions with type plain character | Recommendation | No |
| CERT-C:STR10-C | Do not concatenate different type of string literals | Recommendation | No |
| CERT-C:STR11-C | Do not specify the bound of a character array initialized with a string literal | Recommendation | No |
| CERT-C:STR30-C | Do not attempt to modify string literals | Rule | Yes |
| CERT-C:STR31-C | Guarantee that storage for strings has sufficient space for character data and the null terminator | Rule | Yes |
| CERT-C:STR32-C | Do not pass a non-null-terminated character sequence to a library function that expects a string | Rule | Yes |
| CERT-C:STR34-C | Cast characters to unsigned char before converting to larger integer sizes | Rule | Yes |
| CERT-C:STR37-C | Arguments to character-handling functions must be representable as an unsigned char | Rule | Yes |
| CERT-C:STR38-C | Do not confuse narrow and wide character strings and functions | Rule | Yes |
| CERT-C:WIN00-C | Be specific when dynamically loading libraries | Recommendation | Yes |
| CERT-C:WIN01-C | Do not forcibly terminate execution | Recommendation | No |
| CERT-C:WIN02-C | Restrict privileges when spawning child processes | Recommendation | Yes |
| CERT-C:WIN03-C | Understand HANDLE inheritance | Recommendation | No |
| CERT-C:WIN04-C | Consider encrypting function pointers | Recommendation | No |
| CERT-C:WIN30-C | Properly pair allocation and deallocation functions | Rule | Yes |
CERT C++
Mapping Summary
| Supported | All | Percent Coverage | |
|---|---|---|---|
| All | 71 | 83 | 85.5% |
| Rule | 71 | 83 | 85.5% |
| Recommendation | 0 | 0 | 0.0% |
Mapping Detail
| Rule | Rule Name | Category | Supported |
|---|---|---|---|
| CERT-CPP:CON50-CPP | Do not destroy a mutex while it is locked | Rule | Yes |
| CERT-CPP:CON51-CPP | Ensure actively held locks are released on exceptional conditions | Rule | Yes |
| CERT-CPP:CON52-CPP | Prevent data races when accessing bit-fields from multiple threads | Rule | Yes |
| CERT-CPP:CON53-CPP | Avoid deadlock by locking in a predefined order | Rule | Yes |
| CERT-CPP:CON54-CPP | Wrap functions that can spuriously wake up in a loop | Rule | Yes |
| CERT-CPP:CON55-CPP | Preserve thread safety and liveness when using condition variables | Rule | Yes |
| CERT-CPP:CON56-CPP | Do not speculatively lock a non-recursive mutex that is already owned by the calling thread | Rule | Yes |
| CERT-CPP:CTR50-CPP | Guarantee that container indices and iterators are within the valid range | Rule | Yes |
| CERT-CPP:CTR51-CPP | Use valid references, pointers, and iterators to reference elements of a container | Rule | Yes |
| CERT-CPP:CTR52-CPP | Guarantee that library functions do not overflow | Rule | Yes |
| CERT-CPP:CTR53-CPP | Use valid iterator ranges | Rule | Yes |
| CERT-CPP:CTR54-CPP | Do not subtract iterators that do not refer to the same container | Rule | Yes |
| CERT-CPP:CTR55-CPP | Do not use an additive operator on an iterator if the result would overflow | Rule | Yes |
| CERT-CPP:CTR56-CPP | Do not use pointer arithmetic on polymorphic objects | Rule | Yes |
| CERT-CPP:CTR57-CPP | Provide a valid ordering predicate | Rule | No |
| CERT-CPP:CTR58-CPP | Predicate function objects should not be mutable | Rule | No |
| CERT-CPP:DCL50-CPP | Do not define a C-style variadic function | Rule | Yes |
| CERT-CPP:DCL51-CPP | Do not declare or define a reserved identifier | Rule | Yes |
| CERT-CPP:DCL52-CPP | Never qualify a reference type with const or volatile | Rule | Yes |
| CERT-CPP:DCL53-CPP | Do not write syntactically ambiguous declarations | Rule | Yes |
| CERT-CPP:DCL54-CPP | Overload allocation and deallocation functions as a pair in the same scope | Rule | Yes |
| CERT-CPP:DCL55-CPP | Avoid information leakage when passing a class object across a trust boundary | Rule | Yes |
| CERT-CPP:DCL56-CPP | Avoid cycles during initialization of static objects | Rule | Yes |
| CERT-CPP:DCL57-CPP | Do not let exceptions escape from destructors or deallocation functions | Rule | Yes |
| CERT-CPP:DCL58-CPP | Do not modify the standard namespaces | Rule | Yes |
| CERT-CPP:DCL59-CPP | Do not define an unnamed namespace in a header file | Rule | Yes |
| CERT-CPP:DCL60-CPP | Obey the one-definition rule | Rule | Yes |
| CERT-CPP:ERR50-CPP | Do not abruptly terminate the program | Rule | Yes |
| CERT-CPP:ERR51-CPP | Handle all exceptions | Rule | Yes |
| CERT-CPP:ERR52-CPP | Do not use setjmp() or longjmp() | Rule | Yes |
| CERT-CPP:ERR53-CPP | Do not reference base classes or class data members in a constructor or destructor function-try-block handler | Rule | No |
| CERT-CPP:ERR54-CPP | Catch handlers should order their parameter types from most derived to least derived | Rule | Yes |
| CERT-CPP:ERR55-CPP | Honor exception specifications | Rule | Yes |
| CERT-CPP:ERR56-CPP | Guarantee exception safety | Rule | Yes |
| CERT-CPP:ERR57-CPP | Do not leak resources when handling exceptions | Rule | Yes |
| CERT-CPP:ERR58-CPP | Handle all exceptions thrown before main() begins executing | Rule | Yes |
| CERT-CPP:ERR59-CPP | Do not throw an exception across execution boundaries | Rule | No |
| CERT-CPP:ERR60-CPP | Exception objects must be nothrow copy constructible | Rule | No |
| CERT-CPP:ERR61-CPP | Catch exceptions by lvalue reference | Rule | Yes |
| CERT-CPP:ERR62-CPP | Detect errors when converting a string to a number | Rule | Yes |
| CERT-CPP:EXP50-CPP | Do not depend on the order of evaluation for side effects | Rule | Yes |
| CERT-CPP:EXP51-CPP | Do not delete an array through a pointer of the incorrect type | Rule | Yes |
| CERT-CPP:EXP52-CPP | Do not rely on side effects in unevaluated operands | Rule | Yes |
| CERT-CPP:EXP53-CPP | Do not read uninitialized memory | Rule | Yes |
| CERT-CPP:EXP54-CPP | Do not access an object outside of its lifetime | Rule | Yes |
| CERT-CPP:EXP55-CPP | Do not access a cv-qualified object through a cv-unqualified type | Rule | Yes |
| CERT-CPP:EXP56-CPP | Do not call a function with a mismatched language linkage | Rule | No |
| CERT-CPP:EXP57-CPP | Do not cast or delete pointers to incomplete classes | Rule | Yes |
| CERT-CPP:EXP58-CPP | Pass an object of the correct type to va_start | Rule | Yes |
| CERT-CPP:EXP59-CPP | Use offsetof() on valid types and members | Rule | Yes |
| CERT-CPP:EXP60-CPP | Do not pass a nonstandard-layout type object across execution boundaries | Rule | No |
| CERT-CPP:EXP61-CPP | A lambda object must not outlive any of its reference captured objects | Rule | No |
| CERT-CPP:EXP62-CPP | Do not access the bits of an object representation that are not part of the object's value representation | Rule | Yes |
| CERT-CPP:EXP63-CPP | Do not rely on the value of a moved-from object | Rule | Yes |
| CERT-CPP:FIO50-CPP | Do not alternately input and output from a file stream without an intervening positioning call | Rule | Yes |
| CERT-CPP:FIO51-CPP | Close files when they are no longer needed | Rule | Yes |
| CERT-CPP:INT50-CPP | Do not cast to an out-of-range enumeration value | Rule | Yes |
| CERT-CPP:MEM50-CPP | Do not access freed memory | Rule | Yes |
| CERT-CPP:MEM51-CPP | Properly deallocate dynamically allocated resources | Rule | Yes |
| CERT-CPP:MEM52-CPP | Detect and handle memory allocation errors | Rule | Yes |
| CERT-CPP:MEM53-CPP | Explicitly construct and destruct objects when manually managing object lifetime | Rule | Yes |
| CERT-CPP:MEM54-CPP | Provide placement new with properly aligned pointers to sufficient storage capacity | Rule | Yes |
| CERT-CPP:MEM55-CPP | Honor replacement dynamic storage management requirements | Rule | No |
| CERT-CPP:MEM56-CPP | Do not store an already-owned pointer value in an unrelated smart pointer | Rule | Yes |
| CERT-CPP:MEM57-CPP | Avoid using default operator new for over-aligned types | Rule | No |
| CERT-CPP:MSC50-CPP | Do not use std::rand() for generating pseudorandom numbers | Rule | Yes |
| CERT-CPP:MSC51-CPP | Ensure your random number generator is properly seeded | Rule | Yes |
| CERT-CPP:MSC52-CPP | Value-returning functions must return a value from all exit paths | Rule | Yes |
| CERT-CPP:MSC53-CPP | Do not return from a function declared [[noreturn]] | Rule | Yes |
| CERT-CPP:MSC54-CPP | A signal handler must be a plain old function | Rule | No |
| CERT-CPP:OOP50-CPP | Do not invoke virtual functions from constructors or destructors | Rule | Yes |
| CERT-CPP:OOP51-CPP | Do not slice derived objects | Rule | Yes |
| CERT-CPP:OOP52-CPP | Do not delete a polymorphic object without a virtual destructor | Rule | Yes |
| CERT-CPP:OOP53-CPP | Write constructor member initializers in the canonical order | Rule | Yes |
| CERT-CPP:OOP54-CPP | Gracefully handle self-copy assignment | Rule | Yes |
| CERT-CPP:OOP55-CPP | Do not use pointer-to-member operators to access nonexistent members | Rule | Yes |
| CERT-CPP:OOP56-CPP | Honor replacement handler requirements | Rule | No |
| CERT-CPP:OOP57-CPP | Prefer special member functions and overloaded operators to C Standard Library functions | Rule | Yes |
| CERT-CPP:OOP58-CPP | Copy operations must not mutate the source object | Rule | Yes |
| CERT-CPP:STR50-CPP | Guarantee that storage for strings has sufficient space for character data and the null terminator | Rule | Yes |
| CERT-CPP:STR51-CPP | Do not attempt to create a std::string from a null pointer | Rule | Yes |
| CERT-CPP:STR52-CPP | Use valid references, pointers, and iterators to reference elements of a basic_string | Rule | Yes |
| CERT-CPP:STR53-CPP | Range check element access | Rule | Yes |
CERT JAVA
Mapping Summary
| Supported | All | Percent Coverage | |
|---|---|---|---|
| All | 57 | 295 | 19.3% |
| Rule | 56 | 212 | 26.4% |
| Recommendation | 1 | 83 | 1.2% |
Mapping Detail
| Rule | Rule Name | Category | Supported |
|---|---|---|---|
| CERT-Java:CON50-J | Do not assume that declaring a reference volatile guarantees safe publication of the members of the referenced object | Recommendation | No |
| CERT-Java:CON51-J | Do not assume that the sleep(), yield(), or getState() methods provide synchronization semantics | Recommendation | No |
| CERT-Java:CON52-J | Document thread-safety and use annotations where applicable | Recommendation | No |
| CERT-Java:DCL00-J | Prevent class initialization cycles | Rule | Yes |
| CERT-Java:DCL01-J | Do not reuse public identifiers from the Java Standard Library | Rule | No |
| CERT-Java:DCL02-J | Do not modify the collection's elements during an enhanced for statement | Rule | No |
| CERT-Java:DCL50-J | Use visually distinct identifiers | Recommendation | No |
| CERT-Java:DCL51-J | Do not shadow or obscure identifiers in subscopes | Recommendation | No |
| CERT-Java:DCL52-J | Do not declare more than one variable per declaration | Recommendation | No |
| CERT-Java:DCL53-J | Minimize the scope of variables | Recommendation | No |
| CERT-Java:DCL54-J | Use meaningful symbolic constants to represent literal values in program logic | Recommendation | No |
| CERT-Java:DCL55-J | Properly encode relationships in constant definitions | Recommendation | No |
| CERT-Java:DCL56-J | Do not attach significance to the ordinal associated with an enum | Recommendation | No |
| CERT-Java:DCL57-J | Avoid ambiguous overloading of variable arity methods | Recommendation | No |
| CERT-Java:DCL58-J | Enable compile-time type checking of variable arity parameter types | Recommendation | No |
| CERT-Java:DCL59-J | Do not apply public final to constants whose value might change in later releases | Recommendation | No |
| CERT-Java:DCL60-J | Avoid cyclic dependencies between packages | Recommendation | No |
| CERT-Java:DCL61-J | Do not use raw types | Recommendation | No |
| CERT-Java:DRD00 | Do not store sensitive information on external storage (SD card) unless encrypted first | Rule | Yes |
| CERT-Java:DRD01-X | Limit the accessibility of an app's sensitive content provider | Rule | No |
| CERT-Java:DRD02-J | Do not allow WebView to access sensitive local resource through file scheme | Rule | No |
| CERT-Java:DRD03-J | Do not broadcast sensitive information using an implicit intent | Rule | No |
| CERT-Java:DRD04-J | Do not log sensitive information | Rule | No |
| CERT-Java:DRD05-J | Do not grant URI permissions on implicit intents | Rule | No |
| CERT-Java:DRD06 | Do not act on malicious intents | Rule | No |
| CERT-Java:DRD07-X | Protect exported services with strong permissions | Rule | No |
| CERT-Java:DRD08-J | Always canonicalize a URL received by a content provider | Rule | No |
| CERT-Java:DRD09 | Restrict access to sensitive activities | Rule | No |
| CERT-Java:DRD10-X | Do not release apps that are debuggable | Rule | No |
| CERT-Java:DRD11 | Ensure that sensitive data is kept secure | Rule | No |
| CERT-Java:DRD12 | Do not trust data that is world writable | Rule | No |
| CERT-Java:DRD13 | Do not provide addJavascriptInterface method access in a WebView which could contain untrusted content. (API level JELLY_BEAN or below) | Rule | Yes |
| CERT-Java:DRD14-J | Check that a calling app has appropriate permissions before responding | Rule | No |
| CERT-Java:DRD15-J | Consider privacy concerns when using Geolocation API | Rule | No |
| CERT-Java:DRD16-X | Explicitly define the exported attribute for private components | Rule | No |
| CERT-Java:DRD17-J | Do not use the Android cryptographic security provider encryption default for AES | Rule | Yes |
| CERT-Java:DRD18 | Do not use the default behavior in a cryptographic library if it does not use recommended practices | Rule | Yes |
| CERT-Java:DRD19 | Properly verify server certificate on SSL/TLS | Rule | No |
| CERT-Java:DRD20-C | Specify permissions when creating files via the NDK | Rule | No |
| CERT-Java:DRD21-J | Always pass explicit intents to a PendingIntent | Rule | No |
| CERT-Java:DRD22 | Do not cache sensitive information | Rule | Yes |
| CERT-Java:DRD23 | Do not use world readable or writeable to share files between apps | Rule | No |
| CERT-Java:DRD23-J | Do not use loopback when handling sensitive data | Rule | No |
| CERT-Java:DRD24 | Do not bundle OAuth security-related protocol logic or sensitive data into a relying party's app | Rule | No |
| CERT-Java:DRD25 | To request user permission for OAuth, identify relying party and its permissions scope | Rule | No |
| CERT-Java:DRD26-J | For OAuth, use a secure Android method to deliver access tokens | Rule | No |
| CERT-Java:DRD27-J | For OAuth, use an explicit intent method to deliver access tokens | Rule | No |
| CERT-Java:ENV00-J | Do not sign code that performs only unprivileged operations | Rule | No |
| CERT-Java:ENV01-J | Place all security-sensitive code in a single JAR and sign and seal it | Rule | Yes |
| CERT-Java:ENV02-J | Do not trust the values of environment variables | Rule | No |
| CERT-Java:ENV03-J | Do not grant dangerous combinations of permissions | Rule | Yes |
| CERT-Java:ENV04-J | Do not disable bytecode verification | Rule | No |
| CERT-Java:ENV05-J | Do not deploy an application that can be remotely monitored | Rule | No |
| CERT-Java:ENV06-J | Production code must not contain debugging entry points | Rule | Yes |
| CERT-Java:ERR00-J | Do not suppress or ignore checked exceptions | Rule | Yes |
| CERT-Java:ERR01-J | Do not allow exceptions to expose sensitive information | Rule | No |
| CERT-Java:ERR02-J | Prevent exceptions while logging data | Rule | Yes |
| CERT-Java:ERR03-J | Restore prior object state on method failure | Rule | No |
| CERT-Java:ERR04-J | Do not complete abruptly from a finally block | Rule | No |
| CERT-Java:ERR05-J | Do not let checked exceptions escape from a finally block | Rule | No |
| CERT-Java:ERR06-J | Do not throw undeclared checked exceptions | Rule | No |
| CERT-Java:ERR07-J | Do not throw RuntimeException, Exception, or Throwable | Rule | Yes |
| CERT-Java:ERR08-J | Do not catch NullPointerException or any of its ancestors | Rule | Yes |
| CERT-Java:ERR09-J | Do not allow untrusted code to terminate the JVM | Rule | Yes |
| CERT-Java:ERR50-J | Use exceptions only for exceptional conditions | Recommendation | No |
| CERT-Java:ERR51-J | Prefer user-defined exceptions over more general exception types | Recommendation | No |
| CERT-Java:ERR52-J | Avoid in-band error indicators | Recommendation | No |
| CERT-Java:ERR53-J | Try to gracefully recover from system errors | Recommendation | No |
| CERT-Java:ERR54-J | Use a try-with-resources statement to safely handle closeable resources | Recommendation | No |
| CERT-Java:EXP00-J | Do not ignore values returned by methods | Rule | Yes |
| CERT-Java:EXP01-J | Do not use a null in a case where an object is required | Rule | Yes |
| CERT-Java:EXP02-J | Do not use the Object.equals() method to compare two arrays | Rule | Yes |
| CERT-Java:EXP03-J | Do not use the equality operators when comparing values of boxed primitives | Rule | Yes |
| CERT-Java:EXP04-J | Do not pass arguments to certain Java Collections Framework methods that are a different type than the collection parameter type | Rule | No |
| CERT-Java:EXP05-J | Do not follow a write by a subsequent write or read of the same object within an expression | Rule | No |
| CERT-Java:EXP06-J | Expressions used in assertions must not produce side effects | Rule | Yes |
| CERT-Java:EXP07-J | Prevent loss of useful data due to weak references | Rule | No |
| CERT-Java:EXP50-J | Do not confuse abstract object equality with reference equality | Recommendation | No |
| CERT-Java:EXP51-J | Do not perform assignments in conditional expressions | Recommendation | No |
| CERT-Java:EXP52-J | Use braces for the body of an if, for, or while statement | Recommendation | No |
| CERT-Java:EXP53-J | Use parentheses for precedence of operation | Recommendation | No |
| CERT-Java:EXP54-J | Understand the differences between bitwise and logical operators | Recommendation | No |
| CERT-Java:EXP55-J | Use the same type for the second and third operands in conditional expressions | Recommendation | No |
| CERT-Java:FIO00-J | Do not operate on files in shared directories | Rule | No |
| CERT-Java:FIO01-J | Create files with appropriate access permissions | Rule | Yes |
| CERT-Java:FIO02-J | Detect and handle file-related errors | Rule | Yes |
| CERT-Java:FIO03-J | Remove temporary files before termination | Rule | No |
| CERT-Java:FIO04-J | Release resources when they are no longer needed | Rule | Yes |
| CERT-Java:FIO05-J | Do not expose buffers or their backing arrays methods to untrusted code | Rule | No |
| CERT-Java:FIO06-J | Do not create multiple buffered wrappers on a single byte or character stream | Rule | No |
| CERT-Java:FIO07-J | Do not let external processes block on IO buffers | Rule | No |
| CERT-Java:FIO08-J | Distinguish between characters or bytes read from a stream and -1 | Rule | No |
| CERT-Java:FIO09-J | Do not rely on the write() method to output integers outside the range 0 to 255 | Rule | Yes |
| CERT-Java:FIO10-J | Ensure the array is filled when using read() to fill an array | Rule | No |
| CERT-Java:FIO11-J | Do not convert between strings and bytes without specifying a valid character encoding | Rule | No |
| CERT-Java:FIO12-J | Provide methods to read and write little-endian data | Rule | No |
| CERT-Java:FIO13-J | Do not log sensitive information outside a trust boundary | Rule | No |
| CERT-Java:FIO14-J | Perform proper cleanup at program termination | Rule | No |
| CERT-Java:FIO15-J | Do not reset a servlet's output stream after committing it | Rule | No |
| CERT-Java:FIO16-J | Canonicalize path names before validating them | Rule | No |
| CERT-Java:FIO50-J | Do not make assumptions about file creation | Recommendation | No |
| CERT-Java:FIO51-J | Identify files using multiple file attributes | Recommendation | No |
| CERT-Java:FIO52-J | Do not store unencrypted sensitive information on the client side | Recommendation | No |
| CERT-Java:FIO53-J | Use the serialization methods writeUnshared() and readUnshared() with care | Recommendation | No |
| CERT-Java:IDS00-J | Prevent SQL injection | Rule | Yes |
| CERT-Java:IDS01-J | Normalize strings before validating them | Rule | No |
| CERT-Java:IDS02-J | Canonicalize path names before validating them | Rule | No |
| CERT-Java:IDS03-J | Do not log unsanitized user input | Rule | Yes |
| CERT-Java:IDS04-J | Safely extract files from ZipInputStream | Rule | No |
| CERT-Java:IDS05-J | Use a safe subset of ASCII for file and path names | Rule | No |
| CERT-Java:IDS06-J | Exclude unsanitized user input from format strings | Rule | No |
| CERT-Java:IDS07-J | Sanitize untrusted data passed to the Runtime.exec() method | Rule | Yes |
| CERT-Java:IDS08-J | Sanitize untrusted data included in a regular expression | Rule | Yes |
| CERT-Java:IDS09-J | Specify an appropriate locale when comparing locale-dependent data | Rule | No |
| CERT-Java:IDS10-J | Don't form strings containing partial characters | Rule | No |
| CERT-Java:IDS11-J | Perform any string modifications before validation | Rule | No |
| CERT-Java:IDS13-J | Use compatible character encodings on both sides of file or network IO | Rule | No |
| CERT-Java:IDS14-J | Do not trust the contents of hidden form fields | Rule | Yes |
| CERT-Java:IDS15-J | Do not allow sensitive information to leak outside a trust boundary | Rule | No |
| CERT-Java:IDS16-J | Prevent XML Injection | Rule | No |
| CERT-Java:IDS17-J | Prevent XML External Entity Attacks | Rule | No |
| CERT-Java:IDS50-J | Use conservative file naming conventions | Recommendation | No |
| CERT-Java:IDS51-J | Properly encode or escape output | Recommendation | No |
| CERT-Java:IDS52-J | Prevent code injection | Recommendation | No |
| CERT-Java:IDS53-J | Prevent XPath Injection | Recommendation | No |
| CERT-Java:IDS54-J | Prevent LDAP injection | Recommendation | No |
| CERT-Java:IDS55-J | Understand how escape characters are interpreted when strings are loaded | Recommendation | No |
| CERT-Java:IDS56-J | Prevent arbitrary file upload | Recommendation | No |
| CERT-Java:JNI00-J | Define wrappers around native methods | Rule | No |
| CERT-Java:JNI01-J | Safely invoke standard APIs that perform tasks using the immediate caller's class loader instance (loadLibrary) | Rule | No |
| CERT-Java:JNI02-J | Do not assume object references are constant or unique | Rule | No |
| CERT-Java:JNI03-J | Do not use direct pointers to Java objects in JNI code | Rule | No |
| CERT-Java:JNI04-J | Do not assume that Java strings are null-terminated | Rule | No |
| CERT-Java:LCK00-J | Use private final lock objects to synchronize classes that may interact with untrusted code | Rule | Yes |
| CERT-Java:LCK01-J | Do not synchronize on objects that may be reused | Rule | No |
| CERT-Java:LCK02-J | Do not synchronize on the class object returned by getClass() | Rule | No |
| CERT-Java:LCK03-J | Do not synchronize on the intrinsic locks of high-level concurrency objects | Rule | No |
| CERT-Java:LCK04-J | Do not synchronize on a collection view if the backing collection is accessible | Rule | No |
| CERT-Java:LCK05-J | Synchronize access to static fields that can be modified by untrusted code | Rule | Yes |
| CERT-Java:LCK06-J | Do not use an instance lock to protect shared static data | Rule | No |
| CERT-Java:LCK07-J | Avoid deadlock by requesting and releasing locks in the same order | Rule | No |
| CERT-Java:LCK08-J | Ensure actively held locks are released on exceptional conditions | Rule | No |
| CERT-Java:LCK09-J | Do not perform operations that can block while holding a lock | Rule | Yes |
| CERT-Java:LCK10-J | Use a correct form of the double-checked locking idiom | Rule | Yes |
| CERT-Java:LCK11-J | Avoid client-side locking when using classes that do not commit to their locking strategy | Rule | No |
| CERT-Java:MET00-J | Validate method arguments | Rule | No |
| CERT-Java:MET01-J | Never use assertions to validate method arguments | Rule | No |
| CERT-Java:MET02-J | Do not use deprecated or obsolete classes or methods | Rule | No |
| CERT-Java:MET03-J | Methods that perform a security check must be declared private or final | Rule | No |
| CERT-Java:MET04-J | Do not increase the accessibility of overridden or hidden methods | Rule | No |
| CERT-Java:MET05-J | Ensure that constructors do not call overridable methods | Rule | No |
| CERT-Java:MET06-J | Do not invoke overridable methods in clone() | Rule | No |
| CERT-Java:MET07-J | Never declare a class method that hides a method declared in a superclass or superinterface | Rule | No |
| CERT-Java:MET08-J | Preserve the equality contract when overriding the equals() method | Rule | Yes |
| CERT-Java:MET09-J | Classes that define an equals() method must also define a hashCode() method | Rule | Yes |
| CERT-Java:MET10-J | Follow the general contract when implementing the compareTo() method | Rule | No |
| CERT-Java:MET11-J | Ensure that keys used in comparison operations are immutable | Rule | No |
| CERT-Java:MET12-J | Do not use finalizers | Rule | No |
| CERT-Java:MET13-J | Do not assume that reassigning method arguments modifies the calling environment | Rule | No |
| CERT-Java:MET50-J | Avoid ambiguous or confusing uses of overloading | Recommendation | No |
| CERT-Java:MET51-J | Do not use overloaded methods to differentiate between runtime types | Recommendation | No |
| CERT-Java:MET52-J | Do not use the clone() method to copy untrusted method parameters | Recommendation | No |
| CERT-Java:MET53-J | Ensure that the clone() method calls super.clone() | Recommendation | Yes |
| CERT-Java:MET54-J | Always provide feedback about the resulting value of a method | Recommendation | No |
| CERT-Java:MET55-J | Return an empty array or collection instead of a null value for methods that return an array or collection | Recommendation | No |
| CERT-Java:MET56-J | Do not use Object.equals() to compare cryptographic keys | Recommendation | No |
| CERT-Java:MSC00-J | Use SSLSocket rather than Socket for secure data exchange | Rule | No |
| CERT-Java:MSC01-J | Do not use an empty infinite loop | Rule | No |
| CERT-Java:MSC02-J | Generate strong random numbers | Rule | Yes |
| CERT-Java:MSC03-J | Never hard code sensitive information | Rule | Yes |
| CERT-Java:MSC04-J | Do not leak memory | Rule | No |
| CERT-Java:MSC05-J | Do not exhaust heap space | Rule | Yes |
| CERT-Java:MSC06-J | Do not modify the underlying collection when an iteration is in progress | Rule | No |
| CERT-Java:MSC07-J | Prevent multiple instantiations of singleton objects | Rule | No |
| CERT-Java:MSC08-J | Do not store nonserializable objects as attributes in an HTTP session | Rule | No |
| CERT-Java:MSC09-J | For OAuth, ensure (a) [relying party receiving user's ID in last step] is same as (b) [relying party the access token was granted to]. | Rule | No |
| CERT-Java:MSC10-J | Do not use OAuth 2.0 implicit grant (unmodified) for authentication | Rule | No |
| CERT-Java:MSC11-J | Do not let session information leak within a servlet | Rule | No |
| CERT-Java:MSC50-J | Minimize the scope of the @SuppressWarnings annotation | Recommendation | No |
| CERT-Java:MSC51-J | Do not place a semicolon immediately following an if, for, or while condition | Recommendation | No |
| CERT-Java:MSC52-J | Finish every set of statements associated with a case label with a break statement | Recommendation | No |
| CERT-Java:MSC53-J | Carefully design interfaces before releasing them | Recommendation | No |
| CERT-Java:MSC54-J | Avoid inadvertent wrapping of loop counters | Recommendation | No |
| CERT-Java:MSC55-J | Use comments consistently and in a readable fashion | Recommendation | No |
| CERT-Java:MSC56-J | Detect and remove superfluous code and values | Recommendation | No |
| CERT-Java:MSC57-J | Strive for logical completeness | Recommendation | No |
| CERT-Java:MSC58-J | Prefer using iterators over enumerations | Recommendation | No |
| CERT-Java:MSC59-J | Limit the lifetime of sensitive data | Recommendation | No |
| CERT-Java:MSC60-J | Do not use assertions to verify the absence of runtime errors | Recommendation | No |
| CERT-Java:MSC61-J | Do not use insecure or weak cryptographic algorithms | Recommendation | No |
| CERT-Java:MSC62-J | Store passwords using a hash function | Recommendation | No |
| CERT-Java:MSC63-J | Ensure that SecureRandom is properly seeded | Recommendation | No |
| CERT-Java:NUM00-J | Detect or prevent integer overflow | Rule | Yes |
| CERT-Java:NUM01-J | Do not perform bitwise and arithmetic operations on the same data | Rule | No |
| CERT-Java:NUM02-J | Ensure that division and remainder operations do not result in divide-by-zero errors | Rule | No |
| CERT-Java:NUM03-J | Use integer types that can fully represent the possible range of unsigned data | Rule | No |
| CERT-Java:NUM04-J | Do not use floating-point numbers if precise computation is required | Rule | No |
| CERT-Java:NUM07-J | Do not attempt comparisons with NaN | Rule | No |
| CERT-Java:NUM08-J | Check floating-point inputs for exceptional values | Rule | No |
| CERT-Java:NUM09-J | Do not use floating-point variables as loop counters | Rule | No |
| CERT-Java:NUM10-J | Do not construct BigDecimal objects from floating-point literals | Rule | No |
| CERT-Java:NUM11-J | Do not compare or inspect the string representation of floating-point values | Rule | No |
| CERT-Java:NUM12-J | Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data | Rule | Yes |
| CERT-Java:NUM13-J | Avoid loss of precision when converting primitive integers to floating-point | Rule | Yes |
| CERT-Java:NUM14-J | Use shift operators correctly | Rule | No |
| CERT-Java:NUM50-J | Convert integers to floating point for floating-point operations | Recommendation | No |
| CERT-Java:NUM51-J | Do not assume that the remainder operator always returns a nonnegative result for integral operands | Recommendation | No |
| CERT-Java:NUM52-J | Be aware of numeric promotion behavior | Recommendation | No |
| CERT-Java:NUM53-J | Use the strictfp modifier for floating-point calculation consistency across platforms | Recommendation | No |
| CERT-Java:NUM54-J | Do not use denormalized numbers | Recommendation | No |
| CERT-Java:OBJ01-J | Limit accessibility of fields | Rule | No |
| CERT-Java:OBJ02-J | Preserve dependencies in subclasses when changing superclasses | Rule | No |
| CERT-Java:OBJ03-J | Prevent heap pollution | Rule | No |
| CERT-Java:OBJ04-J | Provide mutable classes with copy functionality to safely allow passing instances to untrusted code | Rule | No |
| CERT-Java:OBJ05-J | Do not return references to private mutable class members | Rule | No |
| CERT-Java:OBJ06-J | Defensively copy mutable inputs and mutable internal components | Rule | No |
| CERT-Java:OBJ07-J | Sensitive classes must not let themselves be copied | Rule | Yes |
| CERT-Java:OBJ08-J | Do not expose private members of an outer class from within a nested class | Rule | Yes |
| CERT-Java:OBJ09-J | Compare classes and not class names | Rule | No |
| CERT-Java:OBJ10-J | Do not use public static nonfinal fields | Rule | No |
| CERT-Java:OBJ11-J | Be wary of letting constructors throw exceptions | Rule | No |
| CERT-Java:OBJ12-J | Respect object-based annotations | Rule | No |
| CERT-Java:OBJ13-J | Ensure that references to mutable objects are not exposed | Rule | No |
| CERT-Java:OBJ14-J | Do not use an object that has been freed. | Rule | No |
| CERT-Java:OBJ50-J | Never confuse the immutability of a reference with that of the referenced object | Recommendation | No |
| CERT-Java:OBJ51-J | Minimize the accessibility of classes and their members | Recommendation | No |
| CERT-Java:OBJ52-J | Write garbage-collection-friendly code | Recommendation | No |
| CERT-Java:OBJ53-J | Do not use direct buffers for short-lived, infrequently used objects | Recommendation | No |
| CERT-Java:OBJ54-J | Do not attempt to help the garbage collector by setting local reference variables to null | Recommendation | No |
| CERT-Java:OBJ55-J | Remove short-lived objects from long-lived container objects | Recommendation | No |
| CERT-Java:OBJ56-J | Provide sensitive mutable classes with unmodifiable wrappers | Recommendation | No |
| CERT-Java:OBJ57-J | Do not rely on methods that can be overridden by untrusted code | Recommendation | No |
| CERT-Java:OBJ58-J | Limit the extensibility of classes and methods with invariants | Recommendation | No |
| CERT-Java:SEC00-J | Do not allow privileged blocks to leak sensitive information across a trust boundary | Rule | No |
| CERT-Java:SEC01-J | Do not allow tainted variables in privileged blocks | Rule | Yes |
| CERT-Java:SEC02-J | Do not base security checks on untrusted sources | Rule | No |
| CERT-Java:SEC03-J | Do not load trusted classes after allowing untrusted code to load arbitrary classes | Rule | No |
| CERT-Java:SEC04-J | Protect sensitive operations with security manager checks | Rule | No |
| CERT-Java:SEC05-J | Do not use reflection to increase accessibility of classes, methods, or fields | Rule | Yes |
| CERT-Java:SEC06-J | Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar | Rule | Yes |
| CERT-Java:SEC07-J | Call the superclass's getPermissions() method when writing a custom class loader | Rule | No |
| CERT-Java:SEC08-J | Trusted code must discard or clean any arguments provided by untrusted code | Rule | No |
| CERT-Java:SEC09-J | Never leak the results of certain standard API methods from trusted code to untrusted code | Rule | No |
| CERT-Java:SEC10-J | Never permit untrusted code to invoke any API that may (possibly transitively) invoke the reflection APIs | Rule | No |
| CERT-Java:SEC50-J | Avoid granting excess privileges | Recommendation | No |
| CERT-Java:SEC51-J | Minimize privileged code | Recommendation | No |
| CERT-Java:SEC52-J | Do not expose methods that use reduced-security checks to untrusted code | Recommendation | No |
| CERT-Java:SEC53-J | Define custom security permissions for fine-grained security | Recommendation | No |
| CERT-Java:SEC54-J | Create a secure sandbox using a security manager | Recommendation | No |
| CERT-Java:SEC55-J | Ensure that security-sensitive methods are called with validated arguments | Recommendation | No |
| CERT-Java:SEC56-J | Do not serialize direct handles to system resources | Recommendation | No |
| CERT-Java:SEC57-J | Do not let untrusted code misuse privileges of callback methods | Recommendation | No |
| CERT-Java:SEC58-J | Deserialization methods should not perform potentially dangerous operations | Recommendation | No |
| CERT-Java:SER00-J | Enable serialization compatibility during class evolution | Rule | Yes |
| CERT-Java:SER01-J | Do not deviate from the proper signatures of serialization methods | Rule | Yes |
| CERT-Java:SER02-J | Sign then seal objects before sending them outside a trust boundary | Rule | Yes |
| CERT-Java:SER03-J | Do not serialize unencrypted sensitive data | Rule | Yes |
| CERT-Java:SER04-J | Do not allow serialization and deserialization to bypass the security manager | Rule | No |
| CERT-Java:SER05-J | Do not serialize instances of inner classes | Rule | No |
| CERT-Java:SER06-J | Make defensive copies of private mutable components during deserialization | Rule | Yes |
| CERT-Java:SER07-J | Do not use the default serialized form for classes with implementation-defined invariants | Rule | Yes |
| CERT-Java:SER08-J | Minimize privileges before deserializing from a privileged context | Rule | No |
| CERT-Java:SER09-J | Do not invoke overridable methods from the readObject() method | Rule | No |
| CERT-Java:SER10-J | Avoid memory and resource leaks during serialization | Rule | Yes |
| CERT-Java:SER11-J | Prevent overwriting of externalizable objects | Rule | No |
| CERT-Java:SER12-J | Prevent deserialization of untrusted data | Rule | Yes |
| CERT-Java:SER13-J | Deserialization methods should not perform potentially dangerous operations | Rule | No |
| CERT-Java:STR00-J | Don't form strings containing partial characters from variable-width encodings | Rule | No |
| CERT-Java:STR01-J | Do not assume that a Java char fully represents a Unicode code point | Rule | No |
| CERT-Java:STR02-J | Specify an appropriate locale when comparing locale-dependent data | Rule | No |
| CERT-Java:STR03-J | Do not encode noncharacter data as a string | Rule | No |
| CERT-Java:STR04-J | Use compatible character encodings when communicating string data between JVMs | Rule | No |
| CERT-Java:STR50-J | Use the appropriate method for counting characters in a string | Recommendation | No |
| CERT-Java:STR51-J | Use the charset encoder and decoder classes when more control over the encoding process is required | Recommendation | No |
| CERT-Java:THI00-J | Do not invoke Thread.run() | Rule | Yes |
| CERT-Java:THI01-J | Do not invoke ThreadGroup methods | Rule | No |
| CERT-Java:THI02-J | Notify all waiting threads rather than a single thread | Rule | No |
| CERT-Java:THI03-J | Always invoke wait() and await() methods inside a loop | Rule | No |
| CERT-Java:THI04-J | Ensure that threads performing blocking operations can be terminated | Rule | No |
| CERT-Java:THI05-J | Do not use Thread.stop() to terminate threads | Rule | No |
| CERT-Java:TPS00-J | Use thread pools to enable graceful degradation of service during traffic bursts | Rule | No |
| CERT-Java:TPS01-J | Do not execute interdependent tasks in a bounded thread pool | Rule | No |
| CERT-Java:TPS02-J | Ensure that tasks submitted to a thread pool are interruptible | Rule | No |
| CERT-Java:TPS03-J | Ensure that tasks executing in a thread pool do not fail silently | Rule | No |
| CERT-Java:TPS04-J | Ensure ThreadLocal variables are reinitialized when using thread pools | Rule | No |
| CERT-Java:TSM00-J | Do not override thread-safe methods with methods that are not thread-safe | Rule | No |
| CERT-Java:TSM01-J | Do not let the this reference escape during object construction | Rule | No |
| CERT-Java:TSM02-J | Do not use background threads during class initialization | Rule | No |
| CERT-Java:TSM03-J | Do not publish partially initialized objects | Rule | No |
| CERT-Java:VNA00-J | Ensure visibility when accessing shared primitive variables | Rule | Yes |
| CERT-Java:VNA01-J | Ensure visibility of shared references to immutable objects | Rule | No |
| CERT-Java:VNA02-J | Ensure that compound operations on shared variables are atomic | Rule | No |
| CERT-Java:VNA03-J | Do not assume that a group of calls to independently atomic methods is atomic | Rule | Yes |
| CERT-Java:VNA04-J | Ensure that calls to chained methods are atomic | Rule | No |
| CERT-Java:VNA05-J | Ensure atomicity when reading and writing 64-bit values | Rule | No |