"I'm an enthusiastic supporter of the CERT Secure Coding Initiative. Programmers have lots of sources of advice on correctness, clarity, maintainability, performance, and even safety. Advice on how specific language features affect security has been missing. The CERT ^® C Secure Coding Standard fills this need." -Randy Meyers, Chairman of ANSI C "For years we have relied upon the CERT/CC to publish advisories documenting an endless stream of security problems. Now CERT has embodied the advice of leading technical experts to give programmers and managers the practical guidance needed to avoid those problems in new applications and to help secure legacy systems. Well done!" -Dr. Thomas Plum, founder of Plum Hall, Inc. "Connectivity has sharply increased the need for secure, hacker-safe applications. By combining this CERT standard with other safety guidelines, customers gain all-round protection and approach the goal of zero-defect software." -Chris Tapp, Field Applications Engineer, LDRA Ltd. "I've found this standard to be an indispensable collection of expert information on exactly how modern software systems fail in practice. It is the perfect place to start for establishing internal secure coding guidelines. You won't find this information elsewhere, and, when it comes to software security, what you don't know is often exactly what hurts you." -John McDonald, coauthor of The Art of Software Security Assessment Software security has major implications for the operations and assets of organizations, as well as for the welfare of individuals. To create secure software, developers must know where the dangers lie. Secure programming in C can be more difficult than even many experienced programmers believe. This book is an essential desktop reference documenting the first official release of The CERT^® C Secure Coding Standard. The standard itemizes those coding errors that are the root causes of software vulnerabilities in C and prioritizes them by severity, likelihood of exploitation, and remediation costs. Each guideline provides examples of insecure code as well as secure, alternative implementations. If uniformly applied, these guidelines will eliminate the critical coding errors that lead to buffer overflows, format string vulnerabilities, integer overflow, and other common software vulnerabilities.

Robert C. Seacord leads the Secure Coding Initiative at the CERT at the Software Engineering Institute (SEI) in Pittsburgh, Pennsylvania. The CERT, among other security-related activities, regularly analyzes software vulnerability reports and assesses the risk to the Internet and other critical infrastructure. Robert is an adjunct professor in the Carnegie Mellon University School of Computer Science and in the Information Networking Institute and part-time faculty at the University of Pittsburgh. An eclectic technologist, Robert is author of three previous books, Secure Coding in C and C++ (Addison- Wesley, 2005), Building Systems from Commercial Components (Addison-Wesley, 2002), and Modernizing Legacy Systems (Addison-Wesley, 2003), as well as more than 40 papers on software security, componentbased software engineering, Web-based system design, legacy-system modernization, component repositories and search engines, and user interface design and development. Robert started programming professionally for IBM in 1982, working in communications and operating system software, processor development, and software engineering. Robert also has worked at the X Consortium, where he developed and maintained code for the Common Desktop Environment and the X Window System. He represents Carnegie Mellon at PL22. 11 (ANSI "C") and is a technical expert for the JTC1/SC22/WG14 international standardization working group for the C programming language.

Preface xvii Acknowledgments xxxi About the Author xxxiii Chapter 1: Using This Standard 1 System Qualities 1 Automatically Generated Code 2 Compliance 3 Chapter 2: Preprocessor (PRE) 5 PRE00-C. Prefer inline or static functions to function-like macros 6 PRE01-C. Use parentheses within macros around parameter names 11 PRE02-C. Macro replacement lists should be parenthesized 13 PRE03-C. Prefer type definitions to defines for encoding types 15 PRE04-C. Do not reuse a standard header file name 16 PRE05-C. Understand macro replacement when concatenating tokens or performing stringification 18 PRE06-C. Enclose header files in an inclusion guard 21 PRE07-C. Avoid using repeated question marks 22 PRE08-C. Guarantee that header file names are unique 24 PRE09-C. Do not replace secure functions with less secure functions 26 PRE10-C. Wrap multistatement macros in a do-while loop 27 PRE30-C. Do not create a universal character name through concatenation 29 PRE31-C. Never invoke an unsafe macro with arguments containing assignment, increment, decrement, volatile access, or function call 30 Chapter 3: Declarations and Initialization (DCL) 33 DCL00-C. const-qualify immutable objects 35 DCL01-C. Do not reuse variable names in subscopes 36 DCL02-C. Use visually distinct identifiers 38 DCL03-C. Use a static assertion to test the value of a constant expression 39 DCL04-C. Do not declare more than one variable per declaration 42 DCL05-C. Use type definitions to improve code readability 44 DCL06-C. Use meaningful symbolic constants to represent literal values in program logic 45 DCL07-C. Include the appropriate type information in function declarators 51 DCL08-C. Properly encode relationships in constant definitions 54 DCL09-C. Declare functions that return an errno error code with a return type of errno_t 57 DCL10-C. Maintain the contract between the writer and caller of variadic functions 59 DCL11-C. Understand the type issues associated with variadic functions 62 DCL12-C. Implement abstract data types using opaque types 64 DCL13-C. Declare function parameters that are pointers to values not changed by the function as const 66 DCL14-C. Do not make assumptions about the order of global variable initialization across translation units 69 DCL15-C. Declare objects that do not need external linkage with the storage-class specifier static 70 DCL30-C. Declare objects with appropriate storage durations 72 DCL31-C. Declare identifiers before using them 74 DCL32-C. Guarantee that mutually visible identifiers are unique 78 DCL33-C. Ensure that restrict-qualified source and destination pointers in function arguments do not reference overlapping objects 80 DCL34-C. Use volatile for data that cannot be cached 82 DCL35-C. Do not convert a function using a type that does not match the function definition 84 DCL36-C. Do not declare an identifier with conflicting linkage classifications 87 Chapter 4: Expressions (EXP) 91 EXP00-C. Use parentheses for precedence of operation 93 EXP01-C. Do not take the size of a pointer to determine the size of the pointed-to type 95 EXP02-C. Be aware of the short-circuit behavior of the logical AND and OR operators 96 EXP03-C. Do not assume the size of a structure is the sum of the sizes of its members 98 EXP04-C. Do not perform byte-by-byte comparisons between structures 100 EXP05-C. Do not cast away a const qualification 102 EXP06-C. Operands to the sizeof operator should not contain side effects 104 EXP07-C. Do not diminish the benefits of constants by assuming their values in expressions 105 EXP08-C. Ensure pointer arithmetic is used correctly 107 EXP09-C. Use sizeof to determine the size of a type or variable 109 EXP10-C. Do not depend on the order of evaluation of subexpressions or the order in which side effects take place 111 EXP11-C. Do not apply operators expecting one type to data of an incompatible type 114 EXP12-C. Do not ignore values returned by functions 118 EXP30-C. Do not depend on order of evaluation between sequence points 119 EXP31-C. Avoid side effects in assertions 122 EXP32-C. Do not cast away a vol…