1. Requirements

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 History

1.3 Applicability Across Classes

2. Rationale

Secure coding practices should be identified, recorded, and implemented to include all life cycle phases of the project.  Unsafe coding practices result in costly vulnerabilities in application software that leads to the theft of sensitive data.   Some secure practices include but are not limited to the strict language adherence and use of automated tools to identify problems either at compile time or run time; language-specific guidance, domain-specific guidance, local standards for code organization and commenting, and standard file header format are often specified as well.

3. Guidance

The Secure Coding Best Practices document

Requirements

It is important to consider security issues and secure coding principles during the development of requirements. Well-defined and complete security requirements help to drive a secure design and provide traceability through design, implementation, and testing to ensure a secure system.

Architecture

During the development of the architecture, it is important to consider the security vulnerabilities of the different architecture options. The team must weigh these vulnerabilities against the benefits of each option to make informed decisions that will provide the ideal solution for the system to be built. The level of security required by the system must also be considered.

Design

In the detailed design of the system, there are many more security-related decisions to be made which directly impact how the system will be implemented. Make design decisions that simplify the implementation, eliminate or minimize security vulnerabilities, and satisfy the security requirements of the system. Note that the practices in this section are not additional tasks that must be done. Instead, they guide making good design choices.

Implementation

Even with good requirements and good design, many vulnerabilities are introduced during implementation through poor coding practices. The development team must be trained in secure coding so that they are aware of the possible security vulnerabilities and know how to avoid them. As with the design practices, the implementation practices below also are not extra tasks or additional work but are guiding principles to perform more secure coding.

Automated Static Analysis

Automated static analysis is useful in detecting problems and issues in the code, including secure coding issues. Static analysis can be performed as soon as the first code is developed even before the system is executing. It is good practice to define, acquire, and configure the static analysis tools for the project before coding begins so that developers can perform static analysis on the code from the start and regularly thereafter. Performing static analysis throughout development as opposed to once at the end is typically more efficient and results in better code sooner.

Automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives. It also might not be able to detect the usage of custom API functions or third-party libraries that indirectly invoke OS commands, leading to false negatives, especially if the API/library code is not available for analysis. It generally does not account for environmental considerations when reporting out-of-bounds memory operations. This fact can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.

Manual Static Analysis

Manual static analysis is commonly referred to as code inspection or code review. It involves manually examining the code for errors and compliance with coding standards. It is recommended to perform automated static analysis on code before performing the manual code review so that the obvious issues identified by automated tools are resolved before the manual inspection. The manual inspection can then focus on logic issues, business rules, and other types of errors that cannot be discovered through automated analysis.

Manual static analysis can be performed at any point once the code has been written. As with the static analysis, it is recommended to perform manual static analysis incrementally as the code is being developed, rather than one time once the implementation is complete. Incremental evaluation results in more effective reviews because the amount of code being reviewed at any one time is smaller, resulting in shorter reviews. Additionally, errors and bad practices can be caught early in development and corrected so that the development team learns and improves throughout the implementation cycle.

Build

It is important when building the code to use tools and available compiler features to ensure the highest quality code possible. Pay attention to compiler warnings and resolve all warnings, especially those related to secure coding weaknesses.

Automated Dynamic Analysis

The automated dynamic analysis examines the code behavior during the execution of the system and automatically identifies possible issues. As a result, the automated dynamic analysis must be performed once the system is working.

As with automated static analysis, no single tool or method will identify all of the issues in the system. It is best to use a combination of tools to provide sufficient coverage. Some of the methods below are time-consuming and some may not provide sufficient payback to warrant their use, depending on the system being examined. Evaluate the different methods below and choose the ones that will be most effective and efficient for the project of interest.

Manual Dynamic Analysis

The manual dynamic analysis examines the code behavior during the execution of the system but requires manual analysis to identify possible issues. The manual dynamic analysis must be performed once the system is working so that there is some behavior to analyze.

The advantage of manual dynamic analysis is that since the behavior of the system is manually analyzed, errors in business rules and unexpected behavior in different scenarios can be identified. However, since it is manual, it requires more time and effort than automated dynamic analysis.

As with some of the other analysis types, it is not realistic to perform all of the types of dynamic analysis below. No single tool or method will identify all of the issues in the system. It is best to use a combination of methods to provide sufficient coverage. Some of these methods are very time-consuming and expensive or require special knowledge or experience. Choose the methods that are most effective and efficient for the project of interest.

Testing

The testing methods below are likely additional effort to the normal testing performed. However, each type of specialized testing below provides some benefit to increasing the security and robustness of the system being developed. Once again, it is not practical to perform all of the testing methods below, but depending on the system and the level of security required, one or more of the methods may provide some benefit.

Operation/System Configuration

Once the system has been developed and tested, the security of the system cannot be forgotten. It is important to be aware of security vulnerabilities and weaknesses that can be introduced in the deployment, configuration, and operation of the system. Choose the guidelines below that to apply to the system and its testing and operational environments and provide the most benefit.

Additional guidance related to secure coding practices may be found in the following related requirements in this Handbook:

4. Small Projects

No additional guidance is available for small projects.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

1. Assess that the software coding guidelines (e.g., coding standards) include secure coding practices.

7.2 Software Assurance Products

• Source Code Analysis

• SA assessment of software coding guidelines for inclusion of secure coding practices.

• The results of SA independent static code analysis, on the source code, showing that the source code follows the defined secure coding practices.

  
  

  Note
  title Objective Evidence
  The software development organization secure coding standard. Static analysis results.

  Expand
  title Definition of objective evidence
  Include Page SITE:Definition of Objective Evidence SITE:Definition of Objective Evidence

7.3 Metrics

• # of Non-Conformances identified in Cybersecurity coding standard compliance (Open, Closed)

7.4 Guidance

1. Confirm the coding guidelines (e.g., coding standards) address secure coding practices.  The selection of which coding standard to use should be done during the planning part of the software project

Some of the widely used coding standards that consider safety are:

• For C language: MISRA C, SEI CERT C Coding Standard. The SEI CERT C Coding Standard is a software coding standard for the C programming language, developed by the CERT Coordination Center to improve the safety, reliability, and security of software systems.
• For C++ language: MISRA C++, JSF AV C++ Coding Standard, SEI CERT C++ Coding Standard, AUTOSAR C++ Coding Guidelines.

2. Confirm that secure coding practices are used.

Review the Software Development Plan to see which coding standards for secure coding practices have been selected. Confirm with the project (the software development lead and with the project manager) that the code standards selected are actually being used. Viewing the results obtained from a standard checker can help verify that the standard is being followed. If no standard checker is being used, a quick spot check can also be done on the code to verify that the secure coding practices recommended by the standards are being followed in the code.

3. Perform an independent static code analysis for secure coding practices.

Use a static code analysis tool on the source code to look for compliance with the coding standard rules.  Doing this by hand without a tool is nearly impossible, due to too many coding rules and too much code.

If engineering is running a tool that does the standard checking then SA can look at and use the tool output to determine if the code meets the code standards. 

It is best if SA runs a code standard checker on the source code. Part of this is to get SA more involved directly in the source code product so SA won't just rely on what engineering is saying about the source code. 

IV&V may be able to help with the use of independent static code analysis for secure coding practices.

Check to see if the engineering team and the project have run a static analysis tool to assess the cybersecurity vulnerabilities and weaknesses in the source code if so check to see that the findings from the static analysis tool have been addressed by the team.

 Confirm that the engineering team and the project have addressed any identified cybersecurity vulnerabilities and weaknesses in the software requirements, design, code and that any changes to address these vulnerabilities have been tested or are planned for the test.

A method of identifying weaknesses and vulnerabilities is to use the National Vulnerability Database

See the secure coding site