Approach

To achieve higher levels of security, reliability and availability of digital systems, we need to answer questions such as:

• Does this software have bugs of these critical classes?
• Do two software assurance tools find the same set of bugs or different, complimentary sets?
• Can we guarantee that a new technique discovers all problems of this type?

To be able to answer these questions, we need a vastly improved way to describe classes of vulnerabilities and chains of failures.

For that we are developing the Bugs Framework (BF) by factoring and restructuring of information contained in Common Weakness Enumeration (CWE), Software Fault Patterns (SFP), Semantic Templates (ST) and numerous other sources on software vulnerabilities and attacks (see the Enlightenment link). The goal is to categorize unambiguously the types of weaknesses, allowing similarities and differences to be easily explored and examined.

The BF organizes software weaknesses (bugs) into distinct classes, such as Buffer Overflow (BOF), Injection (INJ), and Control of Interaction Frequency (CIF). It is an hierarchy of abstract & concrete classes of bugs with:

• Precise Definitions.
• Level: either low (language-related) or high (semantic). A low level class only occurs in some languages, like BOF, or relates to numbers, like integer overflow in ARC. A high level class, like CRY, INJ, or CIF, deals with domain concepts like passwords and accounts and commands; it does not depend on the number of bits in an int.
• Attributes that identify or distinguish the software fault. Each attribute is an enumeration of possible values. For instance, some BOF attributes are "Access: Read or Write", "Boundary: Above or Below", and "Location: Heap or Stack".
• Directed graph(s) of Causes that bring about faults, which include implementation mistakes, conditions, preceding weaknesses and circumstances that bring about the fault. Some causes are nested hierarchically. For instance, "Data Exceeds Array" in BOF is either "Array Too Small" or "Too Much Data."
• Directed graph(s) of Consequences faults could lead to. Consequences also may be hierarchical.
• Causes-Attributes-Consequences Mappings.
• Possible Sites in code where faults might occur under circumstances indicated by the causes. That is, locations that must be reviewed for possible faults. Note that the attributes describe an event, not the site in code that gives rise to the event.