Baseline for Ed 2 of tr 24772

3.2 Symbols and conventions

3.2.1 Symbols

For the purposes of this document, the symbols given in ISO 80000–2 apply. Other symbols are defined where they appear in this document.

3.2.2 Conventions

Programming language tokens and syntactic tokens appear in courier font.

4. Basic concepts

4.1 Purpose of this Technical Report

This Technical Report specifies software programming language vulnerabilities to be avoided in the development of systems where assured behaviour is required for security, safety, mission critical and business critical software. In general, this guidance is applicable to the software developed, reviewed, or maintained for any application.

This Technical Report does not address software engineering and management issues such as how to design and implement programs, use configuration management tools, use managerial processes, and perform process improvement. Furthermore, the specification of properties and applications to be assured are not treated.

While this Technical Report does not discuss specification or design issues, there is recognition that boundaries among the various activities are not clear-cut. This Technical Report seeks to avoid the debate about where low-level design ends and implementation begins by treating selected issues that some might consider design issues rather than coding issues.

The body of this Technical Report provides users of programming languages with a language-independent overview of potential vulnerabilities in their usage. Annexes describe how the general observations apply to specific languages.

4.2 Intended audience

The intended audience for this Technical Report are those who are concerned with assuring the predictable execution of the software of their system; that is, those who are developing, qualifying, or maintaining a software system and need to avoid language constructs that could cause the software to execute in a manner other than intended.

Developers of applications that have clear safety, security or mission-criticality are expected to be aware of the risks associated with their code and could use this Technical Report to ensure that their development practices address the issues presented by the chosen programming languages, for example by subsetting or providing coding guidelines.

It should not be assumed, however, that other developers can ignore this Technical Report. A weakness in a non-critical application may provide the route by which an attacker gains control of a system or otherwise disrupts co-hosted applications that are critical. It is hoped that all developers would use this Technical Report to ensure that common vulnerabilities are removed or at least minimized from all applications.

Specific audiences for this International Technical Report include developers, maintainers and regulators of:

• 
  Safety-critical applications that might cause loss of life, human injury, or damage to the environment.
  
• 
  Security-critical applications that must ensure properties of confidentiality, integrity, and availability.
  
• 
  Mission-critical applications that must avoid loss or damage to property or finance.
  
• 
  Business-critical applications where correct operation is essential to the successful operation of the business.
  
• 
  Scientific, modeling and simulation applications which require high confidence in the results of possibly complex, expensive and extended calculation.
  

4.3 How to use this document

This Technical Report gathers descriptions of programming language vulnerabilities, as well as selected application vulnerabilities, which have occurred in the past and are likely to occur again. Each vulnerability and its possible mitigations are described in the body of the report in a language-independent manner, though illustrative examples may be language specific. In addition, annexes for particular languages describe the vulnerabilities and their mitigations in a manner specific to the language.

Because new vulnerabilities are always being discovered, it is anticipated that this Technical Report will be revised and new descriptions added. For that reason, a scheme that is distinct from sub-clause numbering has been adopted to identify the vulnerability descriptions. Each description has been assigned an arbitrarily generated, unique three-letter code. These codes should be used in preference to sub-clause numbers when referencing descriptions because they will not change as additional descriptions are added to future editions of this Technical Report.

The main part of this Technical Report contains descriptions that are intended to be language-independent to the greatest possible extent. Annexes apply the generic guidance to particular programming languages.

This Technical Report has been written with several possible usages in mind:

• 
  Programmers familiar with the vulnerabilities of a specific language can reference the guide for more generic descriptions and their manifestations in less familiar languages.
  
• 
  Tool vendors can use the three-letter codes as a succinct way to “profile” the selection of vulnerabilities considered by their tools.
  
• 
  Individual organizations may wish to write their own coding standards intended to reduce the number of vulnerabilities in their software products. The guide can assist in the selection of vulnerabilities to be addressed in those standards and the selection of coding guidelines to be enforced.
  
• 
  Organizations or individuals selecting a language for use in a project may want to consider the vulnerabilities inherent in various candidate languages.
  
• 
  Scientists, engineers, economists, statisticians, or others who write computer programs as tools of their chosen craft can read this document to become more familiar with the issues that may affect their work.
  

The descriptions include suggestions for ways of avoiding the vulnerabilities. Some are simply the avoidance of particular coding constructs, but others may involve increased review or other verification and validation methods. Source code checking tools can be used to automatically enforce some coding rules and standards.

Clause 2 provides Normative references.

Clause 3 provides Terms, definitions, symbols and conventions.

Clause 4 provides the basic concepts used for this Technical Report.

Clause 5, Vulnerability Issues, provides rationale for this Technical Report and explains how many of the vulnerabilities occur.

Clause 6, Programming Language Vulnerabilities, provides language-independent descriptions of vulnerabilities in programming languages that can lead to application vulnerabilities. Each description provides:

• 
  a summary of the vulnerability,
  
• 
  characteristics of languages where the vulnerability may be found,
  
• 
  typical mechanisms of failure,
  
• 
  techniques that programmers can use to avoid the vulnerability, and
  
• 
  ways that language designers can modify language specifications in the future to help programmers mitigate the vulnerability.
  

Clause 7, Application Vulnerabilities, provides descriptions of selected application vulnerabilities which have been found and exploited in a number of applications and which have well known mitigation techniques, and which result from design decisions made by coders in the absence of suitable language library routines or other mechanisms. For these vulnerabilities, each description provides:

• 
  a summary of the vulnerability,
  
• 
  typical mechanisms of failure, and
  
• 
  techniques that programmers can use to avoid the vulnerability.
  

Clause 8, New Vulnerabilities, provides new vulnerabilities that have not yet had corresponding programming language text developed.

Annex A, Vulnerability Taxonomy and List, is a categorization of the vulnerabilities of this report in the form of a hierarchical outline and a list of the vulnerabilities arranged in alphabetic order by their three letter code.

Annex B, Language Specific Vulnerability Template, is a template for the writing of programming language specific annexes that explain how the vulnerabilities from clause 6 are realized in that programming language (or show how they are absent), and how they might be mitigated in language-specific terms.

This technical report is supported by a set of Technical reports numbered TR 24772-2, TR 24772-3, and so on. Each additional part is named for a particular programming language lists the vulnerabilities of Clauses 6 and 7 and describe how each vulnerability appears in that specific language and specifies how it may be mitigated in that language, whenever possible. All of the language-dependent descriptions assume that the user adheres to the standard for the language as listed in the sub-clause of each Part.