This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C

SWE-159 - Verify and Validate Risk Mitigations

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























Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.

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

5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.


6. Lessons Learned

No Lessons Learned have currently been identified for this requirement.

  • No labels