WG 23 (Programming Language Vulnerabilities)
Maintained by
Jim Moore,
James.W.Moore@ieee.org
If you don't see two frames, click here.

Disclaimer

References to Work of Others

This is an listing of papers and publications related to the work of the WG 23. Inclusion in this list does not imply endorsement by WG 23 or any participant of WG 23.

. Author Publication Title Abstract

. . . . .

[Dewar-2008] Dewar, Robert B. K. and Schonberg, Edmond Crosstalk, Jan 2008 Computer Science Education: Where Are the Software Engineers of Tomorrow? "It is our view that Computer Science (CS) education is neglecting basic skills, in particular in the areas of programming and formal methods. We consider that the general adoption of Java as a first programming language is in part responsible for this decline. We examine briefly the set of programming skills that should be part of every software professional’s repertoire."

[Hatton-2003] Hatton, Les EC–A measurement based safer subset of ISO C suitable for embedded system development, November 5, 2003 [pdf] "...This paper attempts to define a relatively small number of rules which avoid known fault modes in the [C] language which have published occurrence rates. It will studiously avoid any rules for which no measurement support is available. It is anticipated that the base subset may be extended as time goes by as further data becomes available. Much of the subset is equally relevant to ISO C++, although very little data exists to guide similar initiatives for the considerable part of C++ which lies outside C."

[Hatton-2004] Hatton, Les Information and Software Technology. 46(7), June 2004, pp. 465-472 Safer Language Subsets: an overview and a case history, MISRA C "This paper gives an overview of safer language subsets in general and considers one widely-used one, MISRA C, in particular.... The approach taken is necessarily empirical and where it is able quotes measurements.
The real objective of this paper is to produce an empirically based taxonomy of programming language subset rules to bring all these issues together and promote the concept that a safer subset must be based on measurement principles however crudely they are practised currently in software development.
The concept of signal to noise ratio of a programming standard is also introduced."

[Holzmann-2006] Holzmann, Gerard J. Computer, vol. 39, no. 6, pp. 95-97, Jun., 2006 or here The Power of 10: Rules for Developing Safety-Critical Code "Existing coding guidelines therefore offer limited benefit, even for critical applications. A verifiable set of well-chosen coding rules could, however, assist in analyzing critical software components for properties that go well beyond compliance with the set of rules itself. To be effective, though, the set of rules must be small, and it must be clear enough that users can easily understand and remember it. In addition, the rules must be specific enough that users can check them thoroughly and mechanically. To put an upper bound on the number of rules, the set is restricted to no more than 10 rules that will provide an effective guideline. Although such a small set of rules cannot be all-encompassing, following it can achieve measurable effects on software reliability and verifiability."

[ISO-15942] International Organization for Standardization (ISO) ISO/IEC TR 15942:2000 Information technology -- Programming languages -- Guide for the use of the Ada programming language in high integrity systems "This Technical Report provides guidance on the use of Ada when producing high integrity systems. In producing such applications it is usually the case that adherence to guidelines or standards has to be demonstrated to independent bodies. These guidelines or standards vary according to the application area, industrial sector or nature of the risk involved."

[ISO-24731
-Rat] International Organization for Standardization (ISO) ISO/IEC JTC1/SC22 WG14 N1173
Rationale for TR 24731,
Extensions to the C Library
Part I: Bounds-checking interfaces "Preventing buffer overruns is the primary, but not the only, motivation for this technical report."

[Jones-2004] Jones, Derek M. The new C standard: An economic and cultural commentary, v1.1, 2008 "This book contains a detailed analysis of the International Standard for the C language, excluding the library, from a number of perspectives. The organization of the material is unusual in that it is based on the actual text of the published C Standard. The unit of discussion is the individual sentences from the C Standard (2022 of them)."

[Jones-2006] Jones, Derek M. Loops and their control variables: Discussion and proposed guidelines, v0.2, February 27, 2006 "This proposal discusses for loop usage and possible recommendations that restrict the use of loop control variables for reasons based on programming language semantics and/or developer expectations."

[Jones-200x] Jones, Derek M. Coding Guidelines Bibliography (updated occasionally) "List of substantial documents containing coding guideline recommendations and source code measurements. These documents provide recommendations to people who already know the language. Maintained by Derek Jones. Send suggested additions to derek (at) knosof.co dot uk'"

[LMC
-JSF++] Lockheed Martin Corporation 2RDU00001 Rev C Joint Strike Fighter, Air Vehicle, C++ Coding Standards for the System Development and Demonstration Program, December 2005 "The intent of this document is to provide direction and guidance to C++ programmers that will enable them to employ good programming style and proven programming practices leading to safe, reliable, testable, and maintainable code. Consequently, the rules contained in this document are required for Air Vehicle C++ development and recommended for non-Air Vehicle C++ development."

[MISRA-C:2004] Motor Industry Software Reliability Association (Available for purchase at web site.) MISRA-C: 2004, Guidelines for the use of the C language in critical systems
"Since its launch in 1998, the uptake and usage of MISRA C has far exceeded our expectations. ...We have received a considerable amount of feedback on MISRA C and recognized that a revision was appropriate, in particular to address the following:

Ensuring that the language used is consistent with the standard language
Replacing generalized rules for Undefined Behaviour with specific rules targeted at Undefined Behaviour only
Ensuring "one rule, one issue"; i.e. complex rules are split into atomic rules for ease of compliance
Adding to and improving the code examples
Removing the option for tool-less use. "

[NASA-GB
-8719.13] National Aeronautics and Space Administration (NASA) NASA GB-8719.13 NASA Software Safety Guidebook "This document has been issued to make available to software safety practitioners a guidebook for assessing software systems for software’s contribution to safety and techniques for analyzing and applying appropriate safety techniques and methods to software. Software developers and software safety engineers are the primary focus; however, software assurance (SA) engineers, project managers, system engineers, and system safety engineers will also find this guidebook useful."

[NIST-2006] National Institute of Standards and Technology, Information Technology Laboratory, Software Diagnostics and Conformance Testing Division Source Code Analysis Tool Functional Specification, [Most recent draft] "This document specifies the functional behavior of one class of software assurance tool: the source code analyzer. Because the majority of software weaknesses today are introduced at the implementation phase, a specification that defines a "baseline" source code analysis tool capability can help software professionals select a tool that will meet their software assurance needs."

[RTCA-99] RTCA, Inc. RTCA DO-178B, Issued 12-1-92, Errata Issued 3-26-99 Software Considerations in Airborne Systems and Equipment Certification Guidance for determining, in a consistent manner and with an acceptable level of confidence, that the software aspects of airborne systems and equipment comply with airworthiness requirements.

[Seacord-2005] Seacord, Robert C.; Householder, Allen D. Software Engineering Institute Technical Note CMU/SEI 2005-TN-003, January 2005 A Structured Approach to Classifying Security Vulnerabilities "In this report a classification scheme that uses attribute-value pairs to provide a multidimensional view of vulnerabilities is proposed. Attributes and values are selected based on engineering distinctions that allow vulnerabilities to be exploited by a given technique or determine which countermeasures are effective. Successful classification of vulnerabilities should lead to greater automation in analyzing code vulnerabilities and supporting effective communication between geographically remote vulnerability handling teams and vendors."

[Skalka-2005] Skalka, Christian IEEE Security and Privacy, May/June 2005 Programming Languages
and Systems Security "I briefly survey the current language-based security technology, particularly as it affects secure system design."

[Ward-2004] Ward, Craig E. Department of Electrical Engineering and Computer Science,
College of Science and Engineering,
Loyola Marymount University Implications of Programming Language Selection
On the Construction of Secure Software Systems "Selecting an implementation programming language for a software system is one
of the most important decisions made during the creation of any software system.
Different programming languages have different implications for the difficulty or
ease of developing secure code. This paper takes eleven vulnerabilities including
buffer overruns, malicious input, and race conditions known to exist in deployed
systems and analyzes five different languages (C, C++, Java, Perl, and ML) to
compare how each language either aids or hinders the creation of a secure
software system."

Disclaimer Most of the items contained in this web site and its associated files and directories are preliminary working material of ISO/IEC JTC 1/SC 22, subject to review and correction.

The web site is maintained for the convenience of the participants in SC 22/WG 23 (Programming Language Vulnerabilities) by:

James W. Moore, James.W.Moore@ieee.org.

ISO/IEC JTC 1/SC 22/WG 23 (Programming Language Vulnerabilities)	Maintained by Jim Moore, James.W.Moore@ieee.org	If you don't see two frames, click here.
	Maintained by Jim Moore, James.W.Moore@ieee.org

.	Author	Publication	Title	Abstract
.	.	.	.	.
[Dewar-2008]	Dewar, Robert B. K. and Schonberg, Edmond	Crosstalk, Jan 2008	Computer Science Education: Where Are the Software Engineers of Tomorrow?	"It is our view that Computer Science (CS) education is neglecting basic skills, in particular in the areas of programming and formal methods. We consider that the general adoption of Java as a first programming language is in part responsible for this decline. We examine briefly the set of programming skills that should be part of every software professional’s repertoire."
[Hatton-2003]	Hatton, Les		EC–A measurement based safer subset of ISO C suitable for embedded system development, November 5, 2003 [pdf]	"...This paper attempts to define a relatively small number of rules which avoid known fault modes in the [C] language which have published occurrence rates. It will studiously avoid any rules for which no measurement support is available. It is anticipated that the base subset may be extended as time goes by as further data becomes available. Much of the subset is equally relevant to ISO C++, although very little data exists to guide similar initiatives for the considerable part of C++ which lies outside C."
[Hatton-2004]	Hatton, Les	Information and Software Technology. 46(7), June 2004, pp. 465-472	Safer Language Subsets: an overview and a case history, MISRA C	"This paper gives an overview of safer language subsets in general and considers one widely-used one, MISRA C, in particular.... The approach taken is necessarily empirical and where it is able quotes measurements. The real objective of this paper is to produce an empirically based taxonomy of programming language subset rules to bring all these issues together and promote the concept that a safer subset must be based on measurement principles however crudely they are practised currently in software development. The concept of signal to noise ratio of a programming standard is also introduced."
[Holzmann-2006]	Holzmann, Gerard J.	Computer, vol. 39, no. 6, pp. 95-97, Jun., 2006 or here	The Power of 10: Rules for Developing Safety-Critical Code	"Existing coding guidelines therefore offer limited benefit, even for critical applications. A verifiable set of well-chosen coding rules could, however, assist in analyzing critical software components for properties that go well beyond compliance with the set of rules itself. To be effective, though, the set of rules must be small, and it must be clear enough that users can easily understand and remember it. In addition, the rules must be specific enough that users can check them thoroughly and mechanically. To put an upper bound on the number of rules, the set is restricted to no more than 10 rules that will provide an effective guideline. Although such a small set of rules cannot be all-encompassing, following it can achieve measurable effects on software reliability and verifiability."
[ISO-15942]	International Organization for Standardization (ISO)	ISO/IEC TR 15942:2000	Information technology -- Programming languages -- Guide for the use of the Ada programming language in high integrity systems	"This Technical Report provides guidance on the use of Ada when producing high integrity systems. In producing such applications it is usually the case that adherence to guidelines or standards has to be demonstrated to independent bodies. These guidelines or standards vary according to the application area, industrial sector or nature of the risk involved."
[ISO-24731 -Rat]	International Organization for Standardization (ISO)	ISO/IEC JTC1/SC22 WG14 N1173	Rationale for TR 24731, Extensions to the C Library Part I: Bounds-checking interfaces	"Preventing buffer overruns is the primary, but not the only, motivation for this technical report."
[Jones-2004]	Jones, Derek M.		The new C standard: An economic and cultural commentary, v1.1, 2008	"This book contains a detailed analysis of the International Standard for the C language, excluding the library, from a number of perspectives. The organization of the material is unusual in that it is based on the actual text of the published C Standard. The unit of discussion is the individual sentences from the C Standard (2022 of them)."
[Jones-2006]	Jones, Derek M.		Loops and their control variables: Discussion and proposed guidelines, v0.2, February 27, 2006	"This proposal discusses for loop usage and possible recommendations that restrict the use of loop control variables for reasons based on programming language semantics and/or developer expectations."
[Jones-200x]	Jones, Derek M.		Coding Guidelines Bibliography (updated occasionally)	"List of substantial documents containing coding guideline recommendations and source code measurements. These documents provide recommendations to people who already know the language. Maintained by Derek Jones. Send suggested additions to derek (at) knosof.co dot uk'"
[LMC -JSF++]	Lockheed Martin Corporation	2RDU00001 Rev C	Joint Strike Fighter, Air Vehicle, C++ Coding Standards for the System Development and Demonstration Program, December 2005	"The intent of this document is to provide direction and guidance to C++ programmers that will enable them to employ good programming style and proven programming practices leading to safe, reliable, testable, and maintainable code. Consequently, the rules contained in this document are required for Air Vehicle C++ development and recommended for non-Air Vehicle C++ development."
[MISRA-C:2004]	Motor Industry Software Reliability Association	(Available for purchase at web site.)	MISRA-C: 2004, Guidelines for the use of the C language in critical systems	"Since its launch in 1998, the uptake and usage of MISRA C has far exceeded our expectations. ...We have received a considerable amount of feedback on MISRA C and recognized that a revision was appropriate, in particular to address the following: Ensuring that the language used is consistent with the standard language Replacing generalized rules for Undefined Behaviour with specific rules targeted at Undefined Behaviour only Ensuring "one rule, one issue"; i.e. complex rules are split into atomic rules for ease of compliance Adding to and improving the code examples Removing the option for tool-less use. "
[NASA-GB -8719.13]	National Aeronautics and Space Administration (NASA)	NASA GB-8719.13	NASA Software Safety Guidebook	"This document has been issued to make available to software safety practitioners a guidebook for assessing software systems for software’s contribution to safety and techniques for analyzing and applying appropriate safety techniques and methods to software. Software developers and software safety engineers are the primary focus; however, software assurance (SA) engineers, project managers, system engineers, and system safety engineers will also find this guidebook useful."
[NIST-2006]	National Institute of Standards and Technology, Information Technology Laboratory, Software Diagnostics and Conformance Testing Division		Source Code Analysis Tool Functional Specification, [Most recent draft]	"This document specifies the functional behavior of one class of software assurance tool: the source code analyzer. Because the majority of software weaknesses today are introduced at the implementation phase, a specification that defines a "baseline" source code analysis tool capability can help software professionals select a tool that will meet their software assurance needs."
[RTCA-99]	RTCA, Inc.	RTCA DO-178B, Issued 12-1-92, Errata Issued 3-26-99	Software Considerations in Airborne Systems and Equipment Certification	Guidance for determining, in a consistent manner and with an acceptable level of confidence, that the software aspects of airborne systems and equipment comply with airworthiness requirements.
[Seacord-2005]	Seacord, Robert C.; Householder, Allen D.	Software Engineering Institute Technical Note CMU/SEI 2005-TN-003, January 2005	A Structured Approach to Classifying Security Vulnerabilities	"In this report a classification scheme that uses attribute-value pairs to provide a multidimensional view of vulnerabilities is proposed. Attributes and values are selected based on engineering distinctions that allow vulnerabilities to be exploited by a given technique or determine which countermeasures are effective. Successful classification of vulnerabilities should lead to greater automation in analyzing code vulnerabilities and supporting effective communication between geographically remote vulnerability handling teams and vendors."
[Skalka-2005]	Skalka, Christian	IEEE Security and Privacy, May/June 2005	Programming Languages and Systems Security	"I briefly survey the current language-based security technology, particularly as it affects secure system design."
[Ward-2004]	Ward, Craig E.	Department of Electrical Engineering and Computer Science, College of Science and Engineering, Loyola Marymount University	Implications of Programming Language Selection On the Construction of Secure Software Systems	"Selecting an implementation programming language for a software system is one of the most important decisions made during the creation of any software system. Different programming languages have different implications for the difficulty or ease of developing secure code. This paper takes eleven vulnerabilities including buffer overruns, malicious input, and race conditions known to exist in deployed systems and analyzes five different languages (C, C++, Java, Perl, and ML) to compare how each language either aids or hinders the creation of a secure software system."

ISO/IEC JTC 1/SC 22/WG 23 (Programming Language Vulnerabilities) Maintained by Jim Moore, James.W.Moore@ieee.org If you don't see two frames, click here.

Disclaimer

References to Work of Others

ISO/IEC JTC 1/SC 22/WG 23 (Programming Language Vulnerabilities)
Maintained by
Jim Moore,
James.W.Moore@ieee.org
If you don't see two frames, click here.