1. Requirements

3.11.6 The project manager shall address identified cybersecurity vulnerabilities and weaknesses.

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

Software defects with security ramifications can leave systems compromised and open to attack. Implementing appropriately planned mitigations can help protect space flight software systems, keep them secure, and eliminate or reduce the impact of single points of failure in the systems.

3. Guidance

The engineering team and the project have responsibilities to address any identified cybersecurity vulnerabilities and weaknesses identified in the software requirements, design, code.  Confirm that the requirements associated with the identified cybersecurity vulnerabilities and weaknesses have been tested or are planned to be tested.  The engineering team and the project should run a static analysis tool to assess the cybersecurity vulnerabilities and weaknesses in the source code and check to see that the findings from the static analysis tool have been addressed by the team.

Recommended guidance for the engineering team:

  1. Run a static analysis tool to verify that the source code conforms to a secure coding rule set by running a static analysis tool
  2. Run a static analysis tool to assess the cybersecurity vulnerabilities and weaknesses in the source code, use a tool that assesses the known CWEs 
  3. Address the results of the static analysis tools used to assess the cybersecurity vulnerabilities and weaknesses in the source code
  4. Determine that the software requirements, software design, and code meet the identified cybersecurity vulnerabilities requirements from the project assessment
  5. Use the NIST criteria to assess the software development environment

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 https://nen.nasa.gov/web/coding (NASA access only)

Project Protection Plans are classified documents.  Per the Frequently Asked Questions section of the Community of Practice for Space Asset Protection accessible to NASA users from the NASA Engineering Network, “NASA has developed a process to incrementally lower classification levels of relevant threat information to Secret and worked with project management teams to obtain clearances for their personnel at that level.  Program/Project managers can also be read in at the Secret level for short periods to review Project Protection Plans.”

NASA users should consult center Process Asset Libraries (PALs) for center-specific guidance and resources related to software security.

Additional guidance related to software security may be found in the following related requirements in this Handbook:

SWE-154 - Identify Security Risks
SWE-156 - Evaluate Systems for Security Risks
SWE-157 - Protect Against Unauthorized Access
SWE-158 - Evaluate Software for Security Vulnerabilities
SWE-159 - Verify and Validate Risk Mitigations

4. Small Projects

No additional guidance is available for small projects. 


5. Resources

5.1 References

Enter the necessary modifications to be made in the table below:
SWEREFs to be addedSWEREFS to be deleted


SWEREFs NOT called out in text but listed as germane: 064, 065, 082, 273
SWEREFs called out in text: none

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. Confirm that the project addresses the engineering and assurance identified cybersecurity vulnerabilities and weaknesses. 
7.2 Software Assurance Products
  • None at this time

  • Evidence of confirmation that the project addressed the results from the static code analysis tool results for cybersecurity vulnerabilities and weaknesses.
  • Software problem reporting or defect tracking system results.
7.3 Metrics
    • # of Cybersecurity vulnerabilities and weaknesses identified.
    • # of Cybersecurity vulnerabilities and weaknesses (Open, Closed, Severity).
    • Trending of Open vs. Closed over time.
    • # of Cybersecurity vulnerabilities and weaknesses identified vs. # resolved during Implementation.
    • # of Non-Conformances identified in Cybersecurity coding standard compliance (Open, Closed).
    • # of Cybersecurity mitigation implementations identified from the security vulnerabilities and security weaknesses.
    • # of Cybersecurity mitigation implementations identified with associated test procedures vs. # of Cybersecurity mitigation implementations identified.
    • Trends of Cybersecurity Non-Conformances over time.
7.4 Guidance
Confirm that the engineering team and the project have addressed any identified cybersecurity vulnerabilities and weaknesses in the software requirements, design, code. Check with the project to see where the lists of identified cybersecurity vulnerabilities are and compare these items with the approved changes in the CM system to see if the vulnerabilities listed have resulted in changes in requirements, design, or code. A static analyzer that checks for such vulnerabilities can be rerun to verify that no remaining vulnerabilities exist.
Confirm that the requirements associated with the identified cybersecurity vulnerabilities and weaknesses have been tested or are planned to be tested.  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. See the Software Assurance guidance for SWE-155 (this requirement) and SWE-158 to check that relevant static analysis results were addressed.
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).