|ISO/IEC JTC 1/SC 22/WG 23 (Programming Language Vulnerabilities)||
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.
|[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 professionals repertoire."|
|[Hatton-2003]||Hatton, Les||ECA 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
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."|
|International Organization for Standardization (ISO)||
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'"|
|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:
|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 softwares 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||
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
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
|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.