A Collection of Information Security Community Standardization Activities and Initiatives

Software Assurance

Software assurance begins with code quality and evidence of that quality. You can assume a software defect found during the development of a product may require $1 to remedy. If the defect escapes the development phase and enters the independent testing phase the cost will be approximately $100 to remedy. If the defect escapes the independent testing phase and makes it into production the cost will be approximately $1,000 to remedy. If sensitive data is lost or attackers make the software do things they are not supposed to do, through exploitation of a known software weakness, the costs of this defect may exceed many thousands of dollars to repair — if repair is even possible — and the impact could go well beyond anything that money can represent.

Software assurance (SwA) is defined as the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle, and that the software functions in the intended manner.

The first step in gaining software assurance is to improve the various aspects of quality of the applications/software you directly control and have evidence to support your confidence in the quality of that software. This segment can be further refined into three sections, all of which can include software weaknesses that could be exploitable when the software is in operation:

  • The software you write directly.
  • The software that you contract someone else to write for you (typically a domain expert).
  • The software you, or your developing contractor, includes into your software applications from third-party libraries, open-source, licensed or purchased software utilities.

Organizing, managing and presenting evidence to support assertions about the quality of software can be approached in many ways. Within the some organizations this is one aspect of a system Certification and Accreditation, but another approach, which is fairly new but promising is with an Assurance Case.

The Software Assurance Program of the Department of Homeland Security's National Cyber Security Division co-sponsors Software and Supply Chain Assurance (SSCA) Forums semi-annually with organizations in the Department of Defense and the National Institute for Standards and Technology. DHS also provides online resources to support the industry-wide community and working groups with their Software Assurance Community Resources and Information Clearinghouse (SwA CRIC) and Build Security-In Web site.

Lacking common characterization of exploitable software constructs presented one of the major challenges to realizing software assurance. As part of its Software Assurance public-private collaboration efforts, DHS has continued to provide the sponsorship for the Common Weakness Enumeration (CWE™) to provide the requisite characterization of exploitable software constructs. CWE better enables the needed education and training of programmers on how to eliminate all-too-common errors before software is delivered and put into operation. Mitigation practices are associated with each CWE identifier, along with common attack patterns (CAPEC™). This aligns with the DHS "Build Security In" approach for software assurance so that software is developed more securely on the front end; avoiding security issues in the longer term. CWE, along with Common Weakness Risk Analysis Framework (CWRAF™) and Common Weakness Scoring System (CWSS™), provides a standard means for understanding residual risks and thus enabling more informed decision-making by suppliers and consumers about the security and resilience of software.