Welcome to BF!
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.
Types of Attributes
There are several kinds of BF fault class attributes. Attributes are either nominal (unordered values) or ordinal (typically ratio - the natural numbers).
Like numbers, Ordinal attributes, have a natural order. Typically, ordinal attributes are ratio scales, with consistent
intervals and a natural zero. BOF
Magnitude (how far outside) and
Size (how much data) and ARC
Magnitude (how much of an overflow, etc.) are just numbers. We usually partition the values
into discrete ranges to group their effect. For example, canaries are useful to detect
Write only when
Small. In contrast, protected memory pages are generally not useful to detect BOF unless
Far. Heartbleed would not have been a severe problem if the
Size of IEX data was a
Little. Partitions are informal or fuzzy; we don't formally define them to be, say, exactly
Nominal attributes do not have a natural ordering. They are just possible values. We do distinguish
between two kinds of nominal attributes: enumerations and collections.
An enumeration is a rather definite, relatively small list. BOF
Access can either be
Write. No other values make sense for that attribute. FRS
Operation can be
=, etc. There are two or three dozen operations, but they can be listed and it doesn't
change (often). IEX
Data State is
Collections are nominal attributes that are hard to enumerate because they tend to be unlimited.
Special Element are specific values, but it makes little sense to try to list ALL the languages or
special elements that may suffer INJ faults.
*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.