Page History

...

• INT50-CPP Do not cast to an out-of-range enumeration value
  • This identifier indicates a rule
  • “INT” stands for the Integer category
  • “50” is the unique identifier
  • “-CPP” stands for the C++ language
• EXP00-J Do not ignore values returned by methods
  • This identifier indicates a rule
  • “EXP” stands for the Expressions category
  • “00” is the unique identifier
  • “-J” stands for the Java language
•  FLP00-C. Understand the limitations of floating-point numbers
  • This identifier indicates a recommendation
  • “FLP” stands for the Floating Point category
  • “00” is the unique identifier
  • “-C” stands for the C programming language

...

Code that is only expected to run on a particular subset platform of platforms should have that platform those platforms mentioned in the code's section header, e.g.: Compliant Solution (POSIX). Likewise, code that is only expected to run on more modern versions of C should indicate the oldest standard that supports them, e.g.: Compliant Solution (C99).

In order to compile the code, you will need to include appropriate header files. For example, if the code invokes malloc(), you may need to include the stdlib.h header.

Many coding examples must lead with some variables initialized to valid values. If any code example (compliant or non-compliant) requires a local variable to be initialized with an unspecified but valid value, then that code should be wrapped inside a function that takes the variable as a function argument. Consequently, unless otherwise noted, function arguments should be assumed to point to valid values. For example, character pointers should not be NULL, but rather point to valid null-terminated byte strings.  Checking that function arguments are valid is important, and is described in detail in recommendation API00-C. Functions should validate their parameters. However, the code involved with checking argument validity would be redundant across all code examples, and so function arguments in these code examples are not validated.

Many code examples will contain ellipsis in comments. This indicates that the comment may be replaced by arbitrary code that code examples will contain ellipsis in comments. This indicates that the comment may be replaced by arbitrary code that satisfies the comment. A comment with only ellipsis suggests that the code may do anything.

...

Likelihood—How likely is it that a flaw introduced by violating the rule can lead to an exploitable vulnerability?

Likelihood—How likely is it that a flaw introduced by violating the rule can lead to an exploitable vulnerability?

Remediation Cost—How expensive is it to comply with the rule?

Detectable—Can a static analysis tool automatically determine if code violates this guideline with high accuracy and precision?

Repairable—Can an automated repair tool reliably fix an alert by making local changes, and can the repair be guaranteed not to break the code even if the alert is a false positive? (There might exist a small set of cases that the tool cannot repair, but the tool can reliably identify these cases.)

These two questions are combined into a single Remediation Cost metric value that ranges from 1 to 3, 

This Remediation Cost metric value, along with the Priority and Severity The three values are then multiplied together for each rule. This product provides a measure that can be used in prioritizing the application of the rules. The products range from 1 to 27, although only the following 10 distinct values are possible: 1, 2, 3, 4, 6, 8, 9, 12, 18, and 27. Rules and recommendations with a priority in the range of 1 to 4 are are  Level 3 rules, 6 to 9 are Level 2 , and 12 to 27 are Level 1 . The following are possible interpretations of the priorities and levels.

...

...

For each entry in a Related Guidelines table, CERT has determined that there is some code flaw for which there is both a violation of some condition of the CERT guideline and a condition of the external-to-CERT guideline, where that condition is violated or that condition is described as a flaw.

Related Guidelines Table headings definitions

• Taxonomy: A named set of coding rules, weaknesses, standards, or guidelines such as Information Technology—Programming Languages, Their Environments and System Software Interfaces—C Secure Coding Rules [ISO/IEC TS 17961:2013]; Information Technology—Programming Languages —Guidance to Avoiding Vulnerabilities in Programming Languages through Language Selection and Use [ISO/IEC TR 24772:2013]; MISRA C 2012: Guidelines for the Use of the C Language in Critical Systems [MISRA C:2012]; and CWE IDs in MITRE’s Common Weakness Enumeration (CWE) [MITRE 2010].

• Taxonomy item: A single named (and/or numbered) item in a taxonomy

• Relationship: For each entry in a Related Guidelines table, CERT has determined that there is some code flaw for which there is both a violation of some condition of the CERT guideline and a condition of the external-to-CERT guideline, where that condition is violated or that condition is described as a flaw.

These relationships may be defined in a precise or imprecise way. For Common Weakness Enumeration (CWE), CERT has made precise mappings between CERT C rules and CWEs, as described below. For other taxonomies of coding flaws or secure coding (such as MISRA or ISO/IEC TR 24772:2013), so far, CERT has made only imprecise (“Unspecified Relationship”) mappings. An “Unspecified Relationship” label indicates there is some overlapping code flaw condition, but the extent is unspecified.

If the mapping was made using an automated process developed by CERT, and not yet verified manually, the mapping is marked at the end with “(A)”.

...

The 10 main precise relationship labels CERT uses are mostly the same as the 10 CWE Mapping Fit relationship labels, with 3 different labels.

An 11th label "None" is specified in cases where previous mappings existed but it has been determined  that there is no overlap of conditions.

Table column formats:

• Taxonomy: Taxonomy name (e.g., “CWE”) followed by version name that was mapped, if that is known (e.g., “CWE 2.11”, “CERT 2016”, or “MISRA”)

• Taxonomy item: A single named (and/or numbered) item in a taxonomy, sometimes with the full title text of the item and sometimes with a hyperlink to the item.

• Relationship: A combined entry with fields for date mapped, organization that did the mapping, and relationship (all in same cell for one mapping, separated by a colon, with one entry per line): <(Optional “Prior to ”)YYYY-MM-DD: ORGANIZATION: RELATIONSHIP(Optional “(A)”)>.  Where specified by mapping day, precise mappings done by CERT use the latest published edition of a non-CERT taxonomy along with the latest published edition of the CERT standard plus changes on the CERT wiki. Precise mappings done by an external organization use the latest published edition of the CERT standard and their own latest published edition. Examples below:

• • Example entries below, in the same cell on different lines: 2017-10-31: CERT: CERT Subset of CWE 2017-05-04: CWE: Exact

• • Example entry for a different mapping, where the exact mapping date is unknown but is known to be before October 03, 2017:

    Prior to 2017-10-03: CERT: Unspecified Relationship

  • Example entry for a different mapping that was made using an automated process and not yet manually verified:

    Prior to 2017-09-05: CERT: Unspecified Relationship (A)

The related guidelines sections contain links to guidelines in related standards, technical specifications, and guideline collections such as Information Technology—Programming Languages, Their Environments and System Software Interfaces—C Secure Coding Rules [ISO/IEC TS 17961:2013]; Information Technology—Programming Languages —Guidance to Avoiding Vulnerabilities in Programming Languages through Language Selection and Use [ISO/IEC TR 24772:2013]; MISRA C 2012: Guidelines for the Use of the C Language in Critical Systems [MISRA C:2012]; and CWE IDs in MITRE’s Common Weakness Enumeration (CWE) [MITRE 2010]. 

You can create a unique URL to get more information on CWEs by appending the relevant ID to the end of a fixed string. For example, to find more information about CWE-192, Integer Coercion Error,” you can append 192.html to http://cwe.mitre.org/data/definitions/ and enter the resulting URL in your browser: http://cwe.mitre.org/data/definitions/192.html. 

The other referenced technical specifications, technical reports, and guidelines are commercially available.

...

Most guidelines have a small bibliography section that lists documents and sections in those documents that provide information relevant to the guideline. Image Removed Image Removed Image Removed