Common Weakness Enumeration

CWE Glossary Definition

Manageable Steps

It is impractical to eliminate all of the software weaknesses known today. Use a phased-in approach to eliminating your specific Top-XX list of common weaknesses in a methodical approach to improving the security of your software.

Some organizations have found that it is impractical to re-train all of their developers in the array of tools available today to detect software weaknesses. These organizations have built a software assurance model where a small group of individuals, highly trained in the use of these detection tools, acts as a roaming “Software Assurance Center of Excellence (SwA CoE).” This team is available to all projects under the organization’s control to step in and evaluate the code being developed and used in their software environment for common weaknesses and known vulnerabilities. Working with the development program manager, the list of issues found is partitioned into three groups: Group 1 is the list of “must fix before release” issues; Group 2 is the “nice to have fixed before release”; and Group 3 is the “exemplar list of issues to be fixed”. The development project manager then devises an eradication plan that is phased-in over time. The amount of time depends on the severity of the issues identified as they relate to your organizations specific sensitivities and ability to accept risk. The list of issues is not simply handed over the wall to the development organization. The assessment team is available to guide and coach the development teams in the art of understanding the threat and the correct resolution of that threat.

The center of excellence will benefit from the rotation of project software developers into the team and then back to the project teams. This will build the knowledge of how to detect and address software assurance issues within your organization.

New Rules for Building Software

Fortune may favor the bold, but for the foreseeable future, good software engineering is going emphasize defensive coding practices. Most programmers and software engineers have not been trained to develop code in a software assurance mode. This means that your best programmers may not be aware they are building weaknesses into the software products they produce. Your newest programmers have also not been trained to build software in a secure mode. Retraining your development engineers will become a necessity in order to build software resilient to known weaknesses and vulnerabilities. Building a Software Assurance Center of Excellence is a good start. Clearly being able to rotate your programming staff through the SwA CoE will strengthen your code security over time and protect the investment you have in your development staff.

Change How Software Is Managed through Its Life Cycle

Traditionally, program managers maintain control and responsibility for the development and/or acquisition of software products. Once the program, or software products, has been released, or acquired, the responsibility of the program manager ends. Placing a stronger emphasis on software assurance and quality may be better served by the program manager maintaining responsibility for the software product through its entire life cycle. The program manager maintains responsibility from the development/acquisition phase, into the sustainment phase, and the eventual retirement phase of the product life cycle.

This approach to program management reduces the benefit of “just getting the software released/acquired” and focuses on the entirety of the product life cycle. For example, adding additional software development gates to pass through, like executing software quality tools on the source code base, add expense and potential delays during the development phase, but reap a high return on investment in the sustainment phase of the product life cycle.

If you are not responsible for the sustainment activities you may optimize the delivery/acquisition portion of the life cycle at the expense of the sustainment portion of the life cycle. This trade-off comes with the potential savings of $1 and potential expense of $1,000, or more, down the line.

Create a Software Assurance Checklist

Below is a software assurance checklist. This is a list of actions your organization can take in order to improve your total software assurance and protection against common weaknesses and known vulnerabilities. This is not a complete list but adding any of these activities to your existing process will benefit your organization. If you are acquiring your software from a “domain expert”, verify that your domain expert is aware that they should be delivering a product that is secure by following industry best practices. This should not add addition cost or time to the contract because as a domain expert they should already be doing all of these suggestions as part of their development processes.

Software Assurance Checklist

• Turn on “Warnings as errors” within your compilers.
• Require written justification as to why a particular “warning” can be ignored.
• Require independent review for compliance to the “warning as errors” policy prior to source code check-in to your configuration management tool.

• Execute a “free” static source code analysis tool and create a policy that then items discovered must be resolved prior to check-in to your configuration management tool.
• Require written justification as to why a particular issue identified by the “free” static analysis tool can be ignored.
• Require independent review for compliance to the resolution of issues identified by the “free” static source code analysis tool policy prior to source code check-in to your configuration management tool.

• Purchase/license several commercial static analysis tools to run as a suite of static source code analysis.
• Require written justification as to why a particular issue identified by the static analysis tool suite can be ignored.
• Require independent review for compliance to the resolution of issues identified by the static source code analysis suite policy prior to source code check-in to your configuration management tool.

• Once all of the static analysis tools have been executed and all of the issues adjudicated, execute a security analysis tool and resolve all of the issues it reports.
• Require written justification as to why a particular issue identified by the security analysis tool can be ignored.

• Hold all open-source code used in your product to the same standards to which you hold your organically developed software.
• If acquiring software, add contract language to ensure that the code being developed for you meets the same software assurance standards as code you would develop.
• Adopt the Common Weakness Scoring System (CWSS) within your organization to identify to which common weaknesses your organization is sensitive
• Adopt the Common Weakness Risk Analysis Framework (CWRAF) within your organization to identify your prioritized “Top-XX Common Weaknesses” list.
• Educate you program management staff in state of the art software assurance methods and technologies at the management level.
• Educate you development staff in state of the art software assurance methods and technologies at the technical level.
• Stand-up a Software Assurance Center of Excellence to work with all of your programs.