This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2D
View this section on the website
See edit history of this section
Post feedback on this section
1. Requirements
3.16.7 The project manager shall verify and validate the required software security risk mitigations to ensure that security objectives identified in the Project Protection Plan for space flight software are satisfied in their implementation.
1.1 Notes
Include assessments for security vulnerabilities during Peer Review/Inspections of software requirements and design and undergo automated security static analysis as well as coding standard static analyses of software code to find potential security vulnerabilities.
1.2 Applicability Across Classes
Class A B C CSC D DSC E F G H Applicable?
Key: - Applicable | - Not Applicable
2. Rationale
Mitigations identified to address security risks need to be confirmed as appropriate and adequate. Software verification and validation (V&V) processes are used to determine whether the software security risk mitigations, as planned and implemented, satisfy their intended use to address security risks in space flight software. The results of V&V activities serve as documented assurance that the correct mitigations were identified, implemented, and will reduce to an acceptable level or eliminate known software security risks.
3. Guidance
Project managers ensure that software security risk mitigations called out in the Project Protection Plan for space flight software are verified and validated as part of the project’s development activities. The verification and validation (V&V) of these mitigations are included in the project’s planned V&V activities, reflected in the project’s V&V plans, and carried out throughout the project life cycle.
When planning V&V for required software security risk mitigations, the following are useful source documents within the project and from the Information System Security Officer (ISSO):
- System level risk assessment report.
- Plan of actions and milestones (POA&M). (POA&M serves as the NASA management tool to address, report, resolve, and remediate security-related weaknesses, both at the information system-level and program-level).
Examples of the type of information found in these documents relevant to planning V&V for software security risk mitigations include:
- Vulnerabilities discovered during the security impact analysis or security control monitoring.
- Corrective efforts associated with the mitigation of identified security weaknesses.
- The NASA goalfor vulnerability remediation identified during vulnerability scanning.
- To have all vulnerabilities categorized as high remediated within five working days of discovery.
- To have all vulnerabilities categorized as moderate remediated within thirty working days of discovery.
- To have all vulnerabilities categorized as low remediated within sixty working days of discovery.
Specific to software security risk mitigations, V&V activities include, at a minimum:
- Security vulnerability checks during peer review/inspections of software requirements, design, code (may require updates to existing peer review/inspection checklists).
- Automated security static code analysis.
- Coding standard static analysis.
Additionally, repeating previous assessments for software security vulnerabilities could be used to confirm that the previously identified vulnerabilities and weaknesses have been addressed and no new vulnerabilities introduced or discovered. To keep costs down and prevent propagation of risks through the project, mitigations are to be put in place as early as possible and verified throughout the life cycle.
Project Protection Plans are classified documents. Per the FAQ 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 time 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 and verification and validation may be found in the following related requirements in this Handbook:
4. Small Projects
No additional guidance is available for small projects.
5. Resources
Renew your license to continue
Your evaluation license has expired. Contact your administrator to renew your Reporting for Confluence license.
5.1 Tools
Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).
NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.
The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.
6. Lessons Learned
No Lessons Learned have currently been identified for this requirement.
