The Bugs Framework (BF)* organizes software weaknesses (bugs) into distinct classes, such as Buffer Overflow (BOF), Injection (INJ), and Control of Interaction Frequency (CIF). Each BF class has an accurate and precise definition and comprises:
- Level (high or low) that identifies the fault as language-related or semantic.
- Attributes that identify the software fault.
- Causes that bring about the fault.
- Consequences the fault could lead to.
- Sites in code where the fault might occur.
BF provides a superior, unified approach that allows us to:
- Precisely and unambiguously express software bugs or vulnerabilities.
- Estimate risk and determine best mitigation strategies based on known consequences of different kinds of faults.
- Explain clearly applicability and utility of different software quality or assurance techniques or approaches.
- More formally reason about assurance techniques or mitigation approaches that may work for a fault with certain attributes, but not for the same general kind of fault that has other attributes.
With BF practitioners and researchers can more accurately, precisely and clearly:
- Describe problems in software and discuss the classes of bugs that tools report.
- Explain what vulnerabilities the proposed techniques prevent.
Those concerned with software quality, the reliability of programs and digital systems, or cybersecurity will be able to make more rapid progress by more clearly labeling the results of errors in software. Those responsible for designing, operating and maintaining computer complexes can communicate with more exactness about threats, attacks, patches and exposures.
As BF covers more classes:
- Existing taxonomies, like CWE, can start explaining their current entries with concise forms of BF descriptions.
- Bug trackers (many already use CWEs) also can be enhanced to report in terms of BF descriptions.
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.
*The BF is being created by factoring and restructuring of information contained in CWE, SFP, NSA CAS, SOAR, SEI-CERT, and others, and thus benefits from the community's experience with their use. Instead of trying to match weakness classes that tools find to CWEs, usually far over- or under-generalizing, the BF can describe tool classes much more accurately, precisely and succinctly. We believe that as CWEs migrate to using this kind of taxonomy, they will be easier to comprehend and avoid.