SW_Code_Assessment_PWS_Appendix_H_Artifacts_Attachment_0001.pdf

APPENDIX H

SOFTWARE CODE ASSESSMENT ARTIFACTS

The Government process for performing code assessments are already in place. The following figures provide a summary and flow of the SwA process required:

SwA Assessment Phase Definitions:

W56JSR-17-R-0004

SwA Assessment Process:

Sample Raw Findings Report:

EXAMPLE Executive Report on the Software Assurance Assessment for the <<System Name>> (<<System Acronym>>)

<<Delivery Date>>

Prepared by

Communications Electronics Command (CECOM) Software Engineering Center (SEC)

Software Assurance

Software Assurance Assessment of the <<ACRONYM>>

Table of Contents

1.0 Introduction

2.0 Evaluation Methodology

3.1 Risks Identified

3.2 Breakdown of Risk by Threat Type

3.3 Breakdown of Risk by Weakness Type

4.0 Conclusions

1.0 Introduction

At the request of the <<System Owner>>, CECOM SEC performed a Software Assurance assessment of the <<System Name>> (<<System Acronym>>) in order to <<determine the compliance of <<ACRONYM>> with the requirements of the Defense Information Systems Agency (DISA) Application Security and Development Security Technical Implementation Guide (STIG) || identify the security posture of the system>>.

The subject evaluation identifies weakness and overall risk of operating the <<System Acronym>>.

<<Due to the fact that an environment for building/compiling the <<ACROYNM>> source code was unavailable, this assessment leveraged only static code analysis tools that do not require compilation of the source code. If compilation of the code were possible, further analysis of the source code may identify additional findings which would change the perceived risk posture of the system. It should be noted that the fact that the code could not be compiled in the Software Assurance Lab indicates that there are limitations to the portability of the build environment. These limitations introduce <<significant>> risk to the maintainability of the system over time.>>

The total number of potentially high risk defects associated with the <<ACRONYM>> was <<number>>.

2.0 Evaluation Methodology

On <<source code provided date>>, <<System Owner>> provided the source code for the <<ACRONYM>> to the SEC Software Assurance team. SEC analyzed the source code with a suite of tools, and normalized the data using the Code DX Software Assurance tool. The following table identifies the source code languages, lines of code, and analysis tools used.

Language Lines of Code Analysis tools

The intent of this evaluation is to identify potential issues with <<ACRONYM>> which could impact its performance, reliability, readiness, and security. The tools used are intended to identify potential defects in the code, and categorize those defects based on the Common Weakness Enumeration (CWE), an industry standard dictionary of software weakness types. Additionally, all applicable findings are mapped to the requirements of the Defense Information Systems Agency (DISA) Application Security and Development Security Technical Implementation Guide (STIG), which identifies requirements for the development of secure DoD software.

Following the automated scans, manual analysis was performed by the Software Assurance team to eliminate findings identified to be potential false positives. Each finding was reviewed in the context of its source file to determine whether it was a true finding, and determine the associated level of risk. <<Insert any applicable statements regarding interaction with the developers to vet the findings>>.

3.1 Risks Identified

3.2 Breakdown of Risk by Threat Type

The following figure identifies the breakdown of software defects based on types of threats to <<ACRONYM>>. The threat types are defined as follows:

• Access Control – Defects which affect access control may affect the ability of the system to effectively restrict the access of users only to resources to which they are authorized.

• Authentication – Defects which affect authentication may affect the ability of the system to validate that a user requesting access to or use of a system resource is who they assert that they are.

• Availability – Defects which affect availability may affect whether the system is mission capable when required, and whether the data within the system is accessible to authorized users.

• Confidentiality – Defects which affect confidentiality may allow system data to be disclosed to unauthorized individuals, entities, or processes.

• Integrity – Defects which affect integrity may allow system data to be modified in an unauthorized or undetected manner.

<<Replace following example chart with actual report chart for system>>

Figure 1: Breakdown of defects by threat type

<<Replace following example with summary of actual chart>> As Figure 1 shows, the predominant threat type affected by the defects within <<ACRONYM>> is availability.

Issues affecting the availability of the system are found in areas such as resource control, for example memory leaks. It is recommended that development focus be put toward improving resource control within the application source code.

3.3 Breakdown of Risk by Weakness Type

The following figure provides a breakdown of defects based on the type of weakness associated with the defects. The defects are defined as follows:

• <<Type 1 - CWE definition of Type 1>>

<<Insert summary of the trends identified by the findings in the above chart>>

4.0 Conclusions

The analysis of <<ACRONYM>> has been completed by SEC’s Software Assurance capability. The results indicate that the majority of the findings associated with the system are in the area of <<high priority areas (e.g. memory leaks and resource management)>>. These issues could introduce <<performance, reliability, security>> risks to the system. A separate artifact has been provided to the development team identifying the specific vulnerabilities. It is recommended that the system owner review the findings and determine the actions they will take moving forward to remediate the findings identified.