1. Requirements

3.11.8 The project manager shall identify, record, and implement secure coding practices.

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

Key:    - Applicable | - Not Applicable

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 ⁰⁰⁴ defines specific guidelines to assist in designing and developing secure code. The best practices identified in the document cover the entire software development lifecycle, from requirements through operations. As with most everything in software, the earlier in the lifecycle issues and problems are identified and resolved, the less impact those problems have on schedule, budget, and rework. Additionally, security flaws and vulnerabilities can be introduced at any point during the lifecycle. Therefore, it is important to implement secure coding best practices throughout the lifecycle.

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.

  
  

  Objective Evidence

  • The software development organization secure coding standard.
  • Static analysis results.
   Definition of objective evidence

  Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

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 ⁶⁶⁵ from NIST that is the U.S. government repository of standards-based vulnerability data. Software weaknesses can be identified using Common Weakness Enumeration (CWE) ⁶⁶⁶ - a dictionary created by MITRE.

See the secure coding site ⁶⁶⁴for more information (NASA access only).