Software QualitySoftware Assurance begins with code quality. For example, one can assume a software defect found during the development of a product costs $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, 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. The first step in gaining Software Assurance is to improve the quality of the applications/software you directly control. This segment can be further refined into three sections:
Software You WriteLooking at section one; software compilers are the first line of defense against software weaknesses. Turn on all of the "warnings" your compiler is capable of generating. If you can, treat compiler warnings as "compile errors". This step utilizes software quality and software assurance tools you have already invested in, to improve the quality of the software you develop. You may experience a compiler warning that you want to ignore. Before disabling that particular compiler warning one should fully understand the risk tradeoff being made by disabling that specific compiler warning. If a warning message is disabled, you should document the rationale for your decision. Unit tests are a Software Industry best practice. The software you develop directly should have unit tests written, and executed successfully, for each software module developed. An additional policy you may consider for your development environment is to prohibit checking in software into your configuration management system until it compiles:
Compiler generated warnings and errors are a good first step in achieving software quality. However, the main function of a compiler is not code quality. There are specific software tools and packages designed to improve software quality. Unfortunately, no single tool will cover all of the possible software weaknesses known to date and to be discovered. This means you will need to identify a suite of tools in order to ensure sufficient coverage of your application and be vigilant about updating your tool suite as new vulnerabilities are discovered. The tools you select will be guided by the sensitivities you have identified within your software. Software Written for YouThe software developer hired or contracted to write custom software for you should be a domain expert. If the developer is a domain expert, they should already be doing all of the software assurance steps you would do, if you were building the software yourself. If the developer you selected is not doing all of the steps above already, are they really a domain expert? When composing the Terms of Agreement or contract between you and your software developer, items should be added to the contract that ensures you receive quality software (as well as correctly functioning software). Provide your software developer with the rules or requirements by which their delivered software product will be accepted or rejected. For example, if your organization is sensitive to a group of Common Weaknesses, then add contract language to the contract that specifically calls out the Common Weaknesses you are concerned with, and insist on verifiable proof from the developer that these Common Weaknesses (by CWE number) have been addressed. This may include compiler output from the software build being delivered so that it can be verified that no compiler warnings were generated. You may also request to verify the source code does not disable compiler warning messages. This verification can be done whether or not the source code is a delivered artifact of the contract. The software developer should be informed that you will be executing a software assurance test suite on the delivered product and that the software product must "pass" these tests as a stipulation of your acceptance of the software. Allow the developer to also use your acceptance criteria tests during development. In order to do this effectively, you will need to have identified which Common Weaknesses (by CWE number) you are most sensitive to, and the suite of software quality tools you plan to use when determining the quality of the software delivered. Tacitly Inherited Software WeaknessesAt the beginning of the software development evolution, all the software developed was completely written in-house and was custom to the specific environment and task at hand. As the software development industry matured, it became a common practice to generate libraries of common functions and to make these libraries available to other software development projects within your organization. Later developments led to software libraries being made commercially available. Open-source libraries and code bases also emerged as viable ways to generate complex software functions. Open-source and function libraries allowed building upon the work of others who created building-blocks for the mundane, niche-specific, or flashy code segments. These building blocks were needed as the foundation of more complex applications being developed. Once the software development industry relinquished direct control of all aspects of the software code built into their projects, the industry had to accept tacitly inherited software weaknesses. These are weaknesses in the code developed outside of your control that are included within the software application you are building, or are in the software runtimes that your application needs to utilize. Selecting your upstream software components carefully will assist in reducing the number and severity of the software weaknesses built into these included software components. Bear in mind that these software libraries, open-source libraries, or commercial packages, may not have intentionally included software weaknesses into their code base, but may have used accepted high-quality coding practices in vogue at the time the software was designed. Many of the known software weaknesses known today are relatively new in their discovery. Now, add the internet into the mix and you have software that was designed to operate in isolation now expected to operate in an internet environment with a significantly enhanced attack surface. See Prioritizing Weaknesses Based on Your Organization's Mission for guidance on how to best identify which CWEs you are sensitive to, and to produce a prioritized list of those CWEs. |
