NIST SP 800-231 日本語訳

Formalizing Cybersecurity Weaknesses and Vulnerabilities

Irena Bojanova

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-231

Formalizing Cybersecurity Weaknesses and Vulnerabilities

Irena Bojanova

Software and Systems Division Information Technology Laboratory

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-231

July 2024

U.S. Department of Commerce Gina M. Raimondo, Secretary

National Institute of Standards and Technology

Laurie E. Locascio, NIST Director and Under Secretary of Commerce for Standards and Technology

Certain equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately. Such identification does not imply recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

NIST Technical Series Policies Copyright, Use, and Licensing Statements NIST Technical Series Publication Identifier Syntax

Publication History Approved by the NIST Editorial Review Board on 2024-05-16

How to cite this NIST Technical Series Publication: Bojanova I (2024) Bugs Framework (BF): Formalizing Cybersecurity Weaknesses and Vulnerabilities. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP), NIST SP 800-231. https://doi.org/10.6028/NIST.SP.800-231

NIST Author ORCID iD 0000-0002-3198-7026

Contact Information bf@nist.gov

The Bugs Framework (BF) is a classification of security bugs and related faults that features a formal language for the unambiguous specification of software and hardware security weaknesses and vulnerabilities. BF bugs models, multidimensional weakness and failure taxonomies, and vulnerability models define the lexis, syntax, and semantics of the BF formal language and form the basis for the definition of secure coding principles. The BF formalism supports a deeper understanding of vulnerabilities as chains of weaknesses that adhere to strict causation, propagation, and composition rules. It enables the generation of comprehensively labeled weakness and vulnerability datasets and multidimensional vulnerability classifications. It also enables the development of new algorithms for code analysis and the use of AI models and formal methods to identify bugs and detect, analyze, prioritize, and resolve or mitigate vulnerabilities.

bug classification; bug identification; software/hardware weakness taxonomy; vulnerability detection; safe coding; formal language; specification generation; weakness dataset; vulnerability dataset; vulnerability classification; software bug; firmware bug; hardware defect; hardware logic bug; bug triaging; software error; software fault; software weakness; hardware weakness; software vulnerability; hardware vulnerability; exploit; security failure; secure coding; vulnerability resolution; vulnerability mitigation; labeled dataset; generation tool; graph generation; AI models; formal methods; CVE; CWE; NVD; KEV.

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

Audience

The intended audience includes security researchers, software and hardware developers, information technology (IT) managers, and IT executives.

The Bugs Framework (BF) [1] is a classification of security bugs and related faults with multidimensional weakness and failure taxonomies that features a formal language for the unambiguous specification of security weaknesses and vulnerabilities. The goal of BF is to help better understand and detect software, firmware, or hardware security weaknesses and vulnerabilities, as well as to resolve or mitigate them. Both cybersecurity experts and automated systems need precise descriptions of the publicly disclosed vulnerabilities and the weakness types related to them. Automated analysis via formal methods requires formal definitions of the weakness and vulnerability concepts. The automated analysis via artificial intelligence (AI) models requires comprehensively labeled weakness and vulnerability datasets.

The BF organizes bugs by the operations of orthogonal software, firmware, or hardware execution phases; faults by their input operands; and errors by their output results. An error either propagates to a fault or is final and enables a security failure. Bugs and faults are causes of security weaknesses, and errors and final errors are their consequences. A bug is a code or specification defect. A fault is a name, data, type, address, or size error.

A BF weakness class is a taxonomic category of a weakness type that relates to a distinct execution phase defined by a set of operations and their input operands and output results. It defines finite sets of ⟨cause, operation⟩→consequence causal relations, operation and operand attributes, and code sites. Causes are bugs or faults, and consequences are errors or final errors.

BF bugs models, weakness and failure taxonomies, and vulnerability models define the BF formal language lexis, syntax, and causal semantics. The BF bugs models define the sets of operations for related execution phases and the proper flow between these operations. The BF weakness taxonomies comprise structured, orthogonal, multidimensional, and context-free BF weakness classes. The BF failure taxonomy comprises corresponding BF failure classes. The BF vulnerability models define state and specification views of a vulnerability, possibly converged and chained with other vulnerabilities. The BF formal language is generated by the BF left-to-right leftmost derivation one-symbol lookahead (LL(1)) attribute context-free grammar (ACFG) based on the BF taxonomies and models.

Analogous to the periodic table, the BF weakness taxonomies allow for the identification or prediction of as yet unencountered security weakness types, which would allow for the prediction of new kinds of vulnerabilities.

The BF taxonomies and models also form the basis for defining secure coding principles, such as input/output check safety (e.g., injection safety), memory safety (e.g., buffer overflow safety or use-after-free safety), and data type safety (e.g., floating point safety or subtype confusion safety). While the BF formal language is descriptive of weaknesses and vulnerabilities, the BF secure coding principles are prescriptive against them — they prevent bugs and faults that compromise code safety.

The BF formalism supports a deeper understanding of vulnerabilities as chains of weaknesses that adhere to strict causation, propagation, and composition rules and allows for backward bug identification from a failure. It enables a new range of research and development efforts for the creation of comprehensively labeled weakness and vulnerability datasets and the generation of formal vulnerability specifications and multidimensional vulnerability classifications.

The BF also supports the development of new static or dynamic analysis and simulation or emulation algorithms [2], as well as AI models and capabilities to identify bugs and detect vulnerabilities. Given the formal specification of code and the BF definitions of weakness and vulnerability, formal methods could also be applied to detect vulnerabilities. The next steps would be to prioritize and resolve or mitigate each of these vulnerabilities (i.e., fix the bug or a fault) to secure critical infrastructure and supply chains.

The datasets of weakness and vulnerability BF specifications formally augment the Common Weakness Enumeration (CWE) [3], the Common Vulnerabilities and Exposures (CVE) [4], and the National Vulnerability Database (NVD) [5]. However, the BF has the expressive power to clearly describe any other security weaknesses and vulnerabilities.

This NIST Special Publication (SP) provides a detailed overview of the Bugs Framework (BF) systematic approach and methodologies for classifying bugs and faults by orthogonal execution phases, formally specifying weaknesses and vulnerabilities, defining secure coding principles, generating comprehensively labeled weakness and vulnerability datasets and vulnerability classifications, and developing BF-based algorithms and systems.

Further details will be available in the following forthcoming NIST SPs:

The current state of the art in describing security weaknesses and vulnerabilities are the CWE [3] and CVE [4]. The current state of the art in labeling security weaknesses and vulnerabilities is the NVD [5], which assigns to a CVE the CWE weakness type that most closely matches the vulnerability. The Known Exploited Vulnerabilities (KEV) catalog [6] is also closely related to the CVE.

The CWE and CVE adopted a one-dimensional list (i.e., enumeration) approach to organizing the entries by unique IDs with natural language descriptions. The CWE added tree-based pillar, class, base, variant, and compound abstractions. Both repositories are regularly refined, and new weakness types, vulnerabilities, and related content are added [7].

The NVD maps CVE entries to CWE entries and assigns Common Vulnerability Scoring Sys-tem (CVSS) [10, 11] severity scores. The KEV catalog organizes publicly exploited CVEs pri-oritzed for remediaton, although they are not necessarily the most severe.

However, the CWE hierarchical structure implies that the weakness types are interdepen-dent and may be too broad, not orthogonal, and ambiguous. Many of the CWE and CVE descriptions are not sufficient, accurate, or precise enough [12–15]; have unclear causal-ity [16–18]; and include programming language and domain-specific notions. The CWE has gaps and overlaps in coverage [16–18], and while some gaps are being identified, new overlaps may be created [19]. Many CVEs do not describe the entire chain of weaknesses underlying the vulnerability. Some list the final error at the sink as the root cause instead of the bug or hardware-induced fault that starts the chain. Focusing on the final error helps identify mitigation techniques, but the actual root cause must be known and fixed to resolve the vulnerability. In the case of CVEs that overlap by root cause [20], fixing that one root cause would resolve all of them. These CWE and CVE challenges propagate to the NVD and KEV and may lead to imprecise or wrong CWE-to-CVE assignments by NVD.

Additonally, the CWE and CVE do not exhibit strict methodologies for tracking the weak-nesses underlying a vulnerability, systematic comprehensive vulnerability labeling, or back-ward root cause identficaton from a security failure. There are no tools to aid the creation and visualizaton of weakness and vulnerability descriptions (see Table 1).

Table 1. CWE, CVE, and NVD challenges

The imprecise descriptions and lack of explainability make CWEs and CVEs difficult to use in modern cybersecurity research [21]. For example, the description of CWE-502 mixes the notons of validation (syntax check) and verification (semantics check), for which BF defines two distinct weakness classes [16]. The descriptions of some CWEs reveal possible causing weaknesses and even chains of weaknesses, which could be helpful but may also imply that these are the only possible causing weaknesses. They also introduce terms that are unrelated to the main weakness and may mislead experts and automated analysis about the single weakness that the CWE is meant to describe. Augmentng the CWE and CVE nat-ural language descriptions with unambiguous formal specifications that adhere to within and between weaknesses causation rules will make them more suitable for algorithms and as comprehensively labeled datasets for training AI models [22].

CVEs that have the same root cause are also difficult to identify. For example, the CVE-2016-7523 and CVE-2016-7524, CVE-2016-7518 and CVE-2017-6500, and CVE-2019-13295 and CVE-2019-13297 couples each have the same bug with the last couple patched in two versions of the product via two different commits [20]. As the chains are incomplete for many CVEs, there is no way to go backward from the failure to reveal the root cause.

The BF addresses the challenges with the CWE and CVE descriptions via its orthogonal, multidimensional, and context-free classification structure. The BF weakness and vulner-ability specifications provide formal augmentaton to the CWE, CVE, and NVD entries.

A BF weakness class is a taxonomic representation of a weakness type defined by finite sets of operations, causes, consequences, attributes, and sites. It is associated with the operations of a distinct phase of software, firmware, or hardware execution, where weaknesses of this type could happen, as well as their input operands and output results.

A BF operation is the minimal input-process-output code that can produce or propagate improper data. A cause is a bug in the operation or a fault of an input operand. A consequence is an erroneous output result from the operation over the operands. The error propagates to a fault or is a final error that enables a failure. Consequently, a BF operation is the minimal input-process-output code that can produce an error from a bug or fault, where the error propagates to another fault or is final (i.e., it is a final error).

The attributes describe the operations and operands with details on what, how, and where it went wrong. They help understand the severity of the bug or fault causing the weakness. For example, pointer overbounds faults on the stack are more severe than those on the heap because buffer overflows on the stack, although easier to exploit, are more severe than those on the heap. The sites point to syntactic places in code that should be checked for bugs or faults that cause such weaknesses.

Orthogonal means that the intersection of the sets of operations of any two BF classes is the empty set. It ensures that the BF weakness types do not overlap in coverage.

Multidimensional means that weaknesses are organized not only by their operations but also by their causes, consequences, and operation and operand attributes. It ensures the BF’s expressive power.

Context-free means an operation cannot have different meanings depending on the language or domain. It ensures that the BF is applicable for code in any programming language and for any platform or application technology.

The BF formal language (see Sec. 8) is generated by the BF LL(1) ACFG, whose lexis, syntax, and semantics reflect the BF weakness taxonomies and bugs and vulnerability models that utilize the strict BF concept definitions for security bug, final error, weakness, vulnerability, exploit vector, and failure as well as fault and error. The LL1 CFG is pivotal, as it ensures precise, unambiguous specifications.

The BF bugs models and weakness taxonomies are developed iteratively according to the BF methodology (see Sec. 6.3) and alongside the BF, BFCWE, and BFCVE tools (see Sec. 10).

The BF formalism guarantees precise descriptions with clear causality of weaknesses (in-cluding CWE) and vulnerabilities (including CVE) and complete, orthogonal, and context-free weakness-type coverage. It forms the basis for the formal definition of secure coding principles, such as memory safety. It also enables the creation of comprehensively labeled weakness and vulnerability datasets, vulnerability classifications, and BF-based systems for bug identficaton and vulnerability detection, analysis, and resolution or mitgaton.

A BF operation is the minimal input-process-output code that can produce or propagate improper data (see Fig. 1). An input operand or output result data is of a specific data type. A data type defines a set or range of data values and the operations allowed on them. It can be primitive (e.g., char, int, double, string, boolean) or structured (e.g., array, record, class). A data value is stored in a finite region of memory called an object. The boundaries of that memory define the size of the object. The address of the memory must be held by at least one pointer or determined as an offset on the stack. Otherwise, the object would be unreachable. Code (i.e., functions) and data type metadata are also stored in memory and can be referred to by pointers. A function is an organized, reusable block of code that takes inputs and returns outputs of specific data types.

Consequently, the possible enttes stored in memory are objects, functions, and types. The possible BF input operands and output results are: name, data (i.e., the data value), type (i.e., the data type), address, and size. A BF operation then is the minimal input-process-output code that can produce or propagate improper name, data, type, address, or size (see the purple terms in Fig. 1). BF operations could be as simple as dereferencing or repositioning a pointer or as com-plex as encryption or authentcaton involving sophistcated algorithms. Other examples include data verification, type coercion, and reading or deallocatng an object. Examples of improper output results and input operands are wrong value and wrap-around as data, insufficient size and cast pointer as type, dangling pointer and over-bounds pointer as ad-dress, and wrong resolved object and wrong generic function bound as name.

The output result of a BF operation is always erroneous; for that, either the operation or an input operand is improper. An operation is improper if it has a bug, and an operand is improper if it is ill-formed (i.e., it is at fault). The erroneous output propagates to become the improper input of another BF operation or eventually is final. Consequently, a BF operation is the minimal input-process-output code that — because of a bug or fault — results in an error that propagates to another fault or is final (i.e., it is a final error). The fault is of a name, data, type, address, or size (see Fig. 1).

The BF bugs and faults landscape covers the operations in software, firmware, and hardware execution phases at appropriate levels of abstraction. The software operations relate to code in applications, libraries, utilities, programming languages, services, and OSs. The firmware operations relate to code in device drivers, basic input/output systems (BIOS), bootloaders, and microcontrollers, as well as to microcode in central processing units (CPU) and other hardware components that require low-level control and flexibility. The hardware operations relate to electronic circuit logic, which adheres to the same input-process-output model as software and firmware operations.

A BF security bug is a defect in the code or specification (i.e., metadata or algorithm) of software, firmware, or hardware circuit logic. A bug could be introduced in an operation (i.e., the improper operation) by a programmer, be the result of a design flaw, or be induced by a hardware defect. Hardware defects can result from overheating, radiation effects, electromagnetic interference (EMI), electrical noise, voltage variations, electromagnetic fields, photon injection, wear and tear, or other physical factors.

Examples of code bugs include missing code (i.e., part of an operation or an entire operation is missing) or erroneous code (e.g., use of a wrong operator in an operation). A memory bit flip due to a hardware defect can corrupt a low-level instruction. Examples of specification bugs include the use of an under-restrictive safelist for input validation or a wrong algorithm for encryption.

A bug could also resurface from design flaws, such as an unaccounted-for system configuration or environment. For example, while an operation may run perfectly in a 64-bit operating system (OS) environment, it may exhibit a security bug on a 32-bit platform. The declaration of an int instead of uint object would lead to a wraparound from a 32-bit calculation that would eventually propagate to a buffer overflow.

A BF fault 1 is a name, data, type, address, or size error (i.e., an improper operand). Name relates to a resolved or bound object, function, or data type. Data, type, address, and size relate to an object. A fault of an operand (i.e., the improper operand) could result from a bug or another fault or be induced by a hardware defect. Only in the case of low-level storage (e.g., cache and CPU registers) is there no type fault. Adding to the examples of improper input operands in Sec. 3.1, other faults include invalid data, wild pointer, wrong type, or missing overridden function. A wrong value could result from a missing validation or an erroneous calculation bug, but also from bit flips or signal disruption due to overheating or other physical factors.

enables a Failure. The possible improper states depending on the cause and consequence of a security weak-ness are presented in Fig. 3. An improper state is caused by a security bug (i.e., the oper-aton is improper) or a fault (i.e., an input operand is improper). The consequence of an improper state is an error that propagates to another fault or is a security final error.

The BF models a security vulnerability as a chain of improper states that propagate as the error (i.e., the erroneous output) from one state becomes the fault (i.e., the improper input) for the next state until a final error that can be exploited toward a security failure is reached (see Fig. 4). That is, a vulnerability is a causal chain of weaknesses. The initial state (depicted in blue) is caused by a software or firmware bug (i.e., an operation defect) (see the blue solid arrow), which if fixed will resolve the vulnerability. A vulnerability chain may also start from a hardware defect-induced bug or fault (see the green dashed arrows), which if fixed will resolve that vulnerability.

A propagation state (depicted in light purple) is caused by a fault (i.e., an operand er-ror). The final state (shown in dark purple) results in a final error (i.e., an undefined or exploitable system behavior) and can lead to a failure (i.e., a violation of a system security requirement). It usually directly relates to a CWE, but there are also CWEs that correspond to initial or propagation weakness states. An error is the result of an improper state opera-ton over its operands. It becomes an improper operand — a fault — for the next improper state. A final error is the result of the operation from the final improper state. It introduces an exploit vector — that is, the pathway for exploitaton — toward a security failure.

For example, in Fig. 4, \(operation_1\) from Improper \(State_1\) is improper due to a bug and results in \(Error_1\) that propagates to the improper \(operand_{2j}\), which leads to Improper \(State_2\). The last \(operation_n\) with improper \(operand_{np}\) results in a Final Error that propagates to an Exploit Vector to enable a Failure.

As errors propagate to faults, the examples of faults also apply to errors. However, an error may be on a higher level of abstraction than a specific fault. For example, an inconsistent value error may propagate to the more specific wrong argument data fault (e.g., see the discussion about Fig. 5) or wrong size fault (e.g., see the discussion about Fig. 17).

Examples of final errors include integer overflow, query injection, buffer overflow, and side communication channels. Legitmate and side channels may also be direct exploit vectors without prior causation. Examples of failures include information exposure (IEX) (i.e., con-fidentality loss), data tampering (TPR) (i.e., integrity loss), denial of service (DOS) (i.e., availability loss), and arbitrary code execution (ACE) (i.e., everything could be lost).

The initial bug state is of an improper operation over proper operands. It is the state with a defect in the operation. The bug must be fixed to resolve the vulnerability. A fault state is of a proper operation over an improper operand. It is a state with a defect in an operand that — if fixed — would only mitigate a vulnerability. If the initial state is caused by a hardware defect-induced fault, its fix will resolve the vulnerability.

Vulnerabilities may also converge at their final states and chain via faults resulting from exploits. The converged final states enable a security failure, which would not have been harmful if only one were present. The chained faults-only vulnerabilities propagate toward a final security failure.

A particular BF security vulnerability chain may correspond to more than one CVE. For example, BadAlloc is a vulnerability pattern that covers more than 25 similar CVEs [25] related to memory allocators, such as malloc() and calloc(). They were found in widely used real-time operating systems (RTOS), standard C libraries, IoT device SDKs, and other self-memory management applications going as far back as the early ‘90s [26].

Consequently, a much smaller wrong size is used at allocation resulting in a memory buffer with an insufficient size — that is, a BF Memory Management (MMN) weakness [1]. This al-lows a pointer to be repositioned outside the buffer boundary — a BF Memory Addressing (MAD) weakness [1]— and data to be written there — a BF Memory Use (MUS) weakness [1]. The buffer overflow final error can then be exploited toward a DOS or ACE (specifically, remote code execution [RCE] on a targeted device) failure.

CVE-2021-21834 is one particular vulnerability that strictly follows the BadAlloc pattern (see its BF CVE-2021-21834 specification at [1]).

If there is a cybersecurity failure, there should be a way to identify the root cause (i.e., the security bug) and the chain of triggered improper execution states that enables the failure.

Theoretcally, addressing the problem of identfying a security bug would be first to gen-erate the graph of all possible vulnerability chains of weaknesses. Then, search the graph via brute force recursive backtracking with specific constraints to find the set of possible valid paths. Finally, select the only proper path via code analysis.

A BF security bug or weakness type relates to a distinct software, firmware (including microcode), or hardware circuit logic execution phase defined by a set of BF operations and their input operands and output results.

A BF operation is the minimal input-process-output code that can produce or propagate an improper name, data, type, address, or size.

The BF defines the concepts of bug, fault, error, final error, weakness, vulnerability, exploit vector, and failure in the context of cybersecurity to provide the level of detail and granularity needed to understand the causation within a weakness and the causation and propagation between weaknesses and between vulnerabilities.

A bug could be introduced by a programmer, be the result of a design flaw, or induced by a hardware defect (e.g., due to overheating). A bug could also resurface from a design flaw (e.g., an unaccounted-for system configuration or environment).

A fault could result from a bug or another fault or be induced by a hardware defect. In the case of low-level storage (e.g., cache and CPU registers), there is no type fault.

The first weakness concerns the root cause of the vulnerability, and the last weakness concerns its sink.

The BF security concept definitions are contextually visualized in Fig. 7. Following the blue solid initial arrow, a security vulnerability may start with a software or firmware security bug (i.e., a code or specification defect within an operation). Following the green dashed arrow, a vulnerability chain may also start from a hardware defect-induced fault. Fixing the bug or hardware defect-induced fault will resolve the vulnerability, as well as any other vulnerability with the same root cause. Fixing a propagated fault, including the cause of the final error at the sink, will only mitigate the vulnerability. Occasionally, several vulnerabilities must converge at their final errors for an exploit to be harmful. Fixing the bug or starting fault of at least one of the chains would avoid the failure. An exploit of a vulnerability may result in a fault starting a new faults-only vulnerability. Fixing the bug or starting fault of the first vulnerability will resolve the entire chain of vulnerabilities.

For more details, refer to the forthcoming SP 800-231A, Bugs Framework: Security Con-cepts.

The BF security bugs and related faults landscape covers the operations (i.e., the BF op-eratons) in software, firmware, and hardware execution phases at appropriate levels of abstraction. A BF operation is the minimal input-process-output code that — because of a bug or fault — results in an error that propagates to another fault or is final (see Sec. 3.1).

The BF bugs models define related execution phases with orthogonal sets of operations in which particular types of bugs or faults could occur. They also define the proper flow of operations within and between the phases, which helps identify causation between weaknesses, as well as missing operations (i.e., missing code bugs) backward from a failure.

Some execution phases may only be on an application level (e.g., input/output check), while others may cover deeper levels of abstraction (e.g., the programming language type system, the OS file system, or the CPU). In any case, if there is a security failure, there must have been an operation with a security bug or a hardware defect-induced fault that propagated through faults of other operations until a security final error that introduces an exploit vector is reached.

The BF Input/Output Check ( INP) Bugs Model shows that input/output data check bugs could be introduced at the data validation (DVL) or data verification (DVR) execution phase (see Fig. 8). The phases determine the BF INP classes: Data Validation (DVL) and Data Verification (DVR) [1, 16].

Each input/output check-related bug or fault involves a Validate, Sanitize, Verify, or Correct operation. According to the flow of operations, input/output data must be validated and sanitized and/or verified and corrected.

The BF Memory ( MEM) Bugs Model shows that memory-related bugs could be introduced at any phase in the life cycle of an object: memory addressing (MAD), memory allocation (MAL), memory use (MUS), or memory deallocation (MDL) (see Fig. 9). The phases de-termine the BF MEM classes: Memory Addressing (MAD), Memory Management (MMN) that combines the MAL and MDL phases, and Memory Use (MUS) [1, 17].

Each memory-related bug or fault involves an Initialize Pointer, Dereference, Reposition, Reassign, Allocate, Extend, Reallocate–Extend, Initialize Object, Read, Write, Clear, Reduce, Reallocate–Reduce, or Deallocate operation.

The main memory-related operations flow is presented in Fig. 9 via blue and black solid arrows. The green dashed arrows show the flow for allocation at a specific address. The red dot-dashed arrows show the extra flow in case of reallocation. Following the blue arrows, the first operation is MAL Allocate an object. Following the green arrows, the first operation is MAD Initialize Pointer. The next operation following the blue arrows must be MAD Initialize Pointer for the allocated object to the address returned by the Allocate operation. In contrast, the next operation following the green arrows must be MAL Allocate an object at the address that the pointer holds.

After an object is allocated and its pointer initialized, MUS Initialize Object (i.e., the first write) must follow. Then, it may be accessed via MAD Dereference and used via MUS Read or Write at any point before it is cleared and deallocated.

The boundaries and size of an object set at allocation can be changed via MAL Extend, MAL Reallocate-Extend, MDL Reduce, or MDL Reallocate-Reduce. Operations that involve reallocation must be followed by MAD Reposition for all of the pointers that own the object. MDL Deallocate an object must be preceded by MUS Clear (i.e., the last write) and followed by MAD Reassign for all of its pointers to either NULL or another object.

BF Data Type (_DAT) Bugs Model shows that data type bugs could be introduced at the declaration (DCL), name resolution (NRS), data type conversion (TCV), or data type-related computation (TCM) execution phase (see Fig. 10). The phases determine the BF _DAT classes: Declaration (DCL), Name Resolution (NRS), Type Conversion (TCV), or Type Computation (TCM) [1, 18]. Each data type-related bug or fault involves a Declare, Define, Refer, Call, Cast, Coerce, Calculate, or Evaluate operation.

According to the data type-related operations flow shown in Fig. 10, the first operations over an entity (i.e., object, function, data type, or namespace) are DCL Declare and DCL Define. Then, it can be referred to in code by its name via NRS Refer. Names that are referred to in remote scopes get resolved via namespaces. Resolved data types get bound to objects, functions, or generic data types according to their declarations (see the purple dot-dashed arrow flow). Resolved functions get bound to implementations and may be called via NRS Call.

A resolved and bound object may be explicitly converted to another data type via TCV Cast and used to call a member function via NRS Call or as an argument or return of a computation function. A passed-in argument is expected to be of the declared parameter data type, and the passed-out result is expected to be of the return data type. Otherwise, TCV Cast is expected before or at the end of the call (see the blue large-dashed arrow flow), or the value will get implicitly converted via TCV Coerce to the parameter or return data type, respectively (see the green dashed arrow flow).

The green arrow flow is only about passed-in or passed-out objects that are coerced. It starts from NRS Call and never from DCL Declare. A comprehensive BF bugs model would combine and connect all BF bugs models via the proper flow between their operations. For example, DAT DCL Declare and INP DVR Verify may be followed by MEM MAD Reposition, DAT TCM Calculate, or DAT TCV Coerse. DAT TCV Coerse may be followed by MEM MMN Allocate, MEM MAD Reposition, DAT TCM Calculate, or MEM MMN Deallocate. DAT TCM Calculate may be followed by MEM MMN Reallocate-Reduce. For more bugs models and details, refer to the forthcoming SP 800-231B, Bugs Framework: Bugs Models.

The BF taxonomy comprises weakness and failure categories. The BF Weakness category comprises BF weakness class types, such as:

The BF Failure category comprises the BF failure class type:

The BF weakness taxonomy structure is based on orthogonal by operations phases of software, firmware, and hardware execution. A BF weakness class defines sets of possible bugs and faults as causes for the operations of a specific phase over their operands to result in errors and final errors as consequences.

As an error propagates to a fault (see Sec. 4), the set of errors is the same as the set of faults across classes. However, a specific propagation may be via values on different levels of abstraction (see Sec. 3.2). Similarly, the set of final errors across classes is the same as the set of exploit vectors toward failures. A BF weakness class also defines operation and operand attributes and code sites.

A BF weakness class type encompasses strictly defined weakness classes of closely related execution phases. For example, the BF INP class type comprises the Data Validation (DVL) and Data Verification (DVR) classes. The BF MEM class type comprises the Memory Addressing (MAD), Memory Management (MMN), and Memory Use (MUS) classes [17]. The BF DAT class type comprises the Declaration (DCL), Name Resolution (NRS), Type Conversion (TCV), and Type Computation (TCM) classes [18]. For all current BF class types, refer to the BF Taxonomy at at [1].

The definition of the BF Data Validation (DVL) class (see Fig. 11) is “Data is validated (i.e., syntax check) or sanitized (i.e., escape, filter, or repair) improperly.” It organizes security bugs by the Validate and Sanitize operations and faults by their Data operand as causes [16]. Possible causes are the Missing Code bug and Corrupted Policy Data fault. Possible consequences are the Invalid Data error and Query Injection and Command Injection final injection errors, which relate to input/output check safety (see 9.1).

The definition of the BF Memory Use (MUS) class (see Fig. 12) is “An object is initial-ized, read, written, or cleared improperly.” It organizes security bugs by the Initialize Ob-ject, Read, Write, and Clear operations and faults by their Data, Type, Address, and Size operands as causes [17]. Possible causes are the Wrong Size and Cast Pointer faults. Pos-sible consequences are the Uninitialized Object error and Buffer Overflow and Use After Deallocate (e.g., use after free or use after return) memory corruption or disclosure final errors, which relate to memory safety (see 9.2).

The definition of the BF Type Conversion (TCV) class (see Fig. 13) is “Data is converted or coerced into other types improperly.” It organizes security bugs by the Cast and Coerce operations and faults by their Name, Data, and Type operands as causes [18]. Possible causes are the Over Range and Wrong Type faults. Possible consequences are the Rounded Value and Downcast Pointer errors, which relate to data type safety (see 9.3). The BF strictly defines the type taxons (e.g., see the terms in black in Figs. 11, 12, and 13) for causes as bugs or faults, for consequences as errors or final errors, and for operation and operand attributes. For example, the Specification Bug, Data Fault, Injection and Memory Corruption/Disclosure Final Errors (see Figs. 11 and 12) taxon types are defined in Table 2. The BF also strictly defines the value taxons (e.g., see the terms in purple in Figs. 11, 12, and 13) for class, operations, causes (as bugs or faults), consequences (as errors or final er-rors), and operation and operand attributes. For example, the Under-Restrictve Policy bug,

Wrong Size fault, Sanitize and Write operations, and Query Injection and Buffer Overflow final errors (see Figs. 11 and 12) taxon values are defined in Table 3.

The operation attribute types are defined in Table 4. Their values per BF class may be dif-ferent for the same operation attribute type (e.g., the Mechanism for MUS Write is Direct or Sequential, while for TCV Coerce, it is Pass in or Pass out). The possible operand at-tribute types are defined in Table 5. Their values per BF class may be different for the same operand attribute type.

Each BF class taxonomy also defines a matrix of semantic rules for propagation between weaknesses, as error to fault match is always by type but may be on different levels of abstraction by value (for details, see the forthcoming SPs 800-231Cx and [1]).

For example, the two most severe weaknesses — missing validation of input data leads to a SQL query injection and writing data via a pointer beyond the upper bound of an array leads to a buffer overflow [27] — are specified with BF as follows: ⟨Missing Code, Validate⟩→Query Injection and ⟨Overbound Pointer, Write⟩→Buffer Overflow.

The BF class taxonomies with built-in taxon definitions are available in machine-readable formats (e.g., see the BF in XML format in Fig. 14 and query it via the BF API at [1]).

The type and value taxon definitions are visualized in the graphical representation of the BF class taxonomies (e.g., see the BF MUS class at [1]) and BFCVE specifications (e.g., the BF CVE-2014-0160 specification at [1]), and as tooltips of the BF tool (see Sec. 10.3).

Fig. 14. BF taxonomy in XML

A BF failure class defines sets of possible exploit vectors used for the exploits of a specific vulnerability to result in the loss of security properties. The exploit vectors propagate from the final errors of BF weakness classes.

The BF Failure ( FLR) class type encompasses strictly defined failure classes, such as:

Remote code execution (RCE) is a sub-case of ACE on a target system or device from a remote location, typically over a network.

An IEX, ACE, or TPR failure may result in a fault that starts a new chained vulnerability.

The methodology for developing BF bugs models and weakness classes involves the following 12 steps (also see Fig. 15):

For example, the MAD and MUS classes (see Fig. 12) correspond to the related memory addressing and memory use execution phases. They are also of the BF _MEM class type [1, 17].

For example, the DVL class has two operations (see Fig. 11), MUS has four operations (see Fig. 12), TCV has two operations (see Fig. 13), and their sets of operations do not overlap.

For example, the BF Memory Bugs Model covers the MAD, MAL, MUS, and MDL phases and the flow between their operations (see Fig. 9).

For example, the DVL class has two values for each of the Code Bug and Code Speci-ficaton bug types — Missing Code and Erroneous Code, and Under-Restrictve Policy and Over-Restrictve Policy, respectively (see Fig. 11).

For example, the MUS class has Data Fault, Type Fault, Address Fault, Size Fault, and Data Error types — the first four as causes, the last one as a consequence. It also has 11 fault values (see Fig. 12).

For example, there is one error value for DVL — Invalid Data (see Fig. 11), one for MUS — Uninialized Object (See Fig. 12), and eight for TCV — five of Data Error and three of Type Error type (see Fig. 13).

For example, MUS has one final error type — Memory Corruption/Disclosure — with eight final error values (see Fig. 12).

For example, DVL has the Safelist, Denylist, Format, and Length values for the Mechanism attribute type (see Fig. 11), while TCV has Pass In and Pass Out (see Fig. 13).

For example, the TCV class has the Resolved and Bound values for the Name State operand attribute type; Numeric, Text, Pointer, and Boolean values for Data Kind; and Primitive and Structure values for Type Kind (see Fig. 13).

Finally, create the BF weakness class taxonomies in machine-readable formats, generate graphical representations to enhance understanding, regenerate the BF LL(1) CFG to include the new taxonomies, and update the BFDB database (see Sec. 10).

The methodology for developing BF failure classes is analogous but also simpler, as final errors of BF weakness classes directly match to exploit vectors of BF Failure classes, and the exploit, at least for now, is on an abstract level.

For more BF classes and details, refer to the forthcoming SPs 800-231Cx, Bugs Framework: yyy Taxonomy, where yyy is a BF class type.

The initial state corresponds to a weakness caused by a bug in the operation or a hardware defect-induced fault of an operand. It results in an error or — if it is the only state — is a final error (i.e., an undefined or exploitable system behavior). A propagation state corresponds to a weakness that is caused by a fault of an operand and results in an error. The final state corresponds to a weakness caused by a fault of an operand or — if it is the only state — by a bug in the operation. It results in a final error that introduces an exploit vector that enables a failure. The initial state relates to the root cause of the vulnerability, and the final state relates to its sink. For simplicity, Fig. 16 does not detail vulnerability chains that start with a hardware defect-induced bug or fault, as Fig. 4 does.

Fixing the bug or a hardware defect-induced fault will resolve the vulnerability, while fixing a non-hardware-defect-induced fault will only mitigate it. Fixing a bug may relate to fixing a design flaw, such as an unaccounted-for system configuration or environment. For a one-chain improper states example, recall the BadAlloc pattern in Fig. 5.

Heartbleed, CVE-2014-0160 — as a real-world example — was a severe vulnerability in the OpenSSL cryptographic library [23]. A server (or client) with a vulnerable heartbeat extension would bleed data via a small heartbeat message with a large requested length (i.e., larger than the actual array size). Each exploit could reveal up to 64KB of raw memory of highly sensitive information (e.g., private keys and login credentials) via buffer over-reads. However, NVD labels it with CWE-125: Out-of-bounds Read, which covers both under-lower-bound and over-upper-bound reads from a buffer. In addition, it reflects only the weakness with the final error at the sink, not the weakness with the bug as the root cause.

The BF state view of Heartbleed is presented in Fig. 17 as two converging vulnerability chains of underlying weaknesses. The BF taxonomy helps identify and comprehensively label three weaknesses in the main chain and one more in the secondary chain.

The analysis reveals two fault states: when pl is repositioned over the array upper bound and when data values are read from there. The former is an instance of the BF Memory Addressing (MAD) class [1] as the (Reposition, Data: Wrong Size, Type, Address, Size) tuple with an improper Data operand element (see the second state in Fig. 17) that results in an Overbound Pointer error. There is no bug in the Reposition operation itself, but a value that is inconsistent with the size of the pl object is used to control the iteration. The later is an instance of the BF Memory Use (MUS) class [1] as the (Read, Data, Type, Address: Overbound Pointer, Size) tuple with an improper Address operand element (see the third state in Fig. 17) that results in a Buffer Over-Read final error. Again, there is no bug in the Read operation itself, but because pl points overbound, it is possible to read data that should not be read (i.e., buffer over-read).

The three-state BF chain so far (see the upper row in Fig. 17) shows that data can be read from over the bound of the array pointed by pl. However, it does not show why an exploit would reach sensitive information, such as private keys or login credentials. The vulnera-bility triggered by the missing size verification bug is only a part (although the main one) of the puzzle. typedef struct ssl3_record_st {

There must have been another coding error due to which an unused object with sensitive data was left in memory unaware of the risks. The bug state of this parallel vulnerability is again an instance of the BF MUS class but as the (Clear: Missing Code, Data, Type, Address) tuple with an improper Clear operation (see the second chain in Fig. 17) that results in a Not Cleared Object final error. Converging the final errors from both chains (i.e., buffer over-read and not cleared object), the vulnerable software can now reach and expose sensitive information.

The bug and fault state automata of Heartbleed (see Fig. 17) expresses it as two converging vulnerability chains of underlying weaknesses. Missing input data verification leads to the use of inconsistent size for a buffer and allows for a pointer reposition over its bound, which — converging with missing clear — allows for remote reads and the exposure of sensitive information. Multiple exploits of Heartbleed, each exposing up to 64KB of memory, can accumulate huge amounts of data, such as “secret keys used for certificates, user names and passwords, instant messages, emails, and business-critical documents and communication” [29].

The fix of the bug in the main Heartbleed chain was to add input data semantics checks and silently ignore the heartbeat message if the requested length was larger than the actual array size (see Fig. 19) [30]. Lines 1468 and 1469 discard heartbeats with zero length. Lines 1472 and 1473 ensure that the actual length of the record data is sufficiently large.

Fig. 19. Heartbleed fix in Heartbeat

For more details on the BF Vulnerability State Model, refer to the forthcoming SP 800-231D, Bugs Framework: Vulnerability Models.

Combined, the memory disclosure final errors Buffer Over-Read and Not Cleared Object cause an information exposure (IEX) security failure. Either the missing Verify bug or the missing Clear bug has to be fixed to avoid this security failure. The corresponding BF specification of Heartbleed — CVE-2014-0160.bfcve — in XML for-mat is shown in Fig. 26. For more details, see BF CVE-2014-0160 Heartbleed at [1].

For more details on the BF Vulnerability Specification Model, refer to the forthcoming SP 800-231D, Bugs Framework: Vulnerability Models.

The BF formal language is generated by the BF left-to-right leftmost derivation one-symbol lookahead (LL(1)) attribute context-free grammar (ACFG) derived from the BF CFG. Since it is based on an LL(1) grammar, the BF formal language is guaranteed to be unambiguous, and the BF weakness and vulnerability specifications are guaranteed to be clear and precise.² The BF lexis, syntax, and semantics are based on the BF structured causal taxonomies (e.g., Fig. 12), bugs models (e.g., Fig. 9), and vulnerability models (e.g., Fig. 16 and 20). Lexis refers to the vocabulary (i.e., words and symbols) used by a specification language. Syntax is about validating the grammatical structure (i.e., the form) of a specification. Semantics is about verifying the logical structure (i.e., the meaning) of a specification.

The BF CFG is a powerful tool for specifying and analyzing security weaknesses and vulnerabilities. It is defined in Listing 1 as a four-tuple

where:

◦ A finite set of variables (nonterminals)

and

◦ A finite set of syntactic rules (productions) in the form

where:

(4)

The BF formal language syntax is about validating the grammatical structure of a BF specification. It adheres to the BF production rules (i.e., nonterminals) for constructing (producing) valid specifications of the language that correspond to the BF Vulnerability Specification Model structure and flow (see Fig. 20), including the converging and chaining rules (see Fig. 16) defined by the BF Vulnerability State Model.

The BF CFG syntax defines a vulnerability that possibly converges with other vulnerabilities, leading to one or more failures. The CFG production rules are expressed via the EBNF using the following meta-notations:

(5)

(6)

To ensure that the BF specifications are unambiguous, the next step is to demonstrate the successful derivation of a BF LL(1)³ formal grammar from the BF CFG. A CFG is an LL(1) grammar if and only if only one token (terminal) or variable (nonterminal) is needed to make a parsing decision [32]. LL(1) grammars are not ambiguous and not left-recursive.

The BF LL(1) formal CFG is derived from the BF EBNF productions on Listing 6 via left factorization and left recursion elimination. It is suitable for recursive descent parsing, as the start of each production option is unique. The rule to choose on each step is uniquely determined by the current variable and the next taxon (if there is one).

Listing 7 defines the BF LL(1) CFG production rules for constructing valid, unambiguous BF specifications. Compared to Listing 6, it also details the bug, fault, error, and final error type non-terminals.

The BF formal language semantics is about verifying the logical structure of a BF specification. It is defined by extending the BF LL(1) CFG to a BF LL(1) ACFG with static semantic rules that adhere to the BF Vulnerability Models causation and propagation rules (see Fig. 16 and 20). The static semantic rules are expressed via a set of grammar attributes (i.e., properties to which values can be assigned), a set of semantic functions for computing the attribute values, and a possibly empty set of predicate functions for each production rule (e.g., Donald Knuth’s attribute grammars [33]).

For example, listing 9 expresses the formal BF specification of CVE-2014-0160 Heartbleed.

For the fully expressed BF lexis, syntax, and semantics in EBNF, refer to the forthcoming SP 800-231E, Bugs Framework: Formal Language.

The Software Engineering Institute (SEI) Computer Emergency Response Team (CERT) Coding Standards (e.g., [34] and [35]) and the Open Worldwide Application Security Project (OWASP) Secure Coding Practices [36] set the current state of the art in secure coding. They provide rules and practices that are grouped by topic and described in natural language. The CERT rules are also programming language-specific, though they do provide useful non-compliant code examples and compliant solutions.

In contrast, the BF bugs models, weakness and failure taxonomies, and vulnerability models (see Sec. 5, 6, and 7) form the basis for the formal definition of secure coding principles by software, firmware, or hardware execution phases, that are also programming language-independent. For example, the BF Input/Output Check Bugs Model (see Fig. 8) and classes (see BF _INP at [1]) address input/output check safety (e.g., no SQL injections or use of wrong input values). The BF Memory Bugs Model (see Fig. 9) and classes (see BF _MEM at [1]) address memory safety (e.g., no use after frees or buffer overflows). The BF Data Type Bugs Model (see Fig. 10) and classes (see BF _DAT at [1]) address data type safety (e.g., no integer overflows or subtype confusions). The BF Vulnerability Models rules (see Sec. 7), which are reflected in the BF semantics, help identify the dependencies between different kinds of code safety.

The BF bugs models define the sets of operations where code safety could break. They also define the proper operation flow within and between execution phases that — if not followed — could also break code safety. The x-axis of a model reflects temporal safety. The y-axis of a model may reflect spatial safety. The BF weakness taxonomies are organized by the bugs models phases and define why (i.e., bugs and faults), where (i.e., operations), and how (i.e., errors and final errors) the code safety could break. The BF vulnerability models define the causation, propagation, and convergence rules, which in addition to the proper operation flow, define how breaking one kind of code safety may lead to breaking another.

Input/output check safety ensures the use of proper input/output data in code. That is, data is properly validated and sanitized and/or verified and corrected. It is addressed by the BF Input/Output Check Bugs Model (see Fig. 8) operation flow and the BF DVL and DVR classes (see BF _INP at [1]) that define why, where, and how input/output check safety could break. It relates to the BF data operations Validate, Sanitize, Verify, and Correct. Input/output data must be validated (syntax check) and then sanitized (escaped, filtered, or repaired) and/or verified (semantics check) and then corrected (assigned a new value or removed), if needed.

Avoiding the meaningful ⟨bug/fault, operation⟩ couples of the BF _INP classes would guarantee input/output check safety. That is, avoiding the BF DVL bugs (i.e., missing or erroneous validation, or under-restrictive or over-restrictive validation policy) and faults (i.e., corrupted or tampered data or validation policy) guarantees safety from errors, such as Invalid Data and final errors, such as Query Injection (e.g., SQL injection) and Source Code Injection (e.g., Cross Site Scripting (XSS)). Injections enable the following security failures: IEX, TPR, ACE, and its sub-case RCE. Avoiding the BF DVR bugs (i.e., missing or erroneous verification or under-restrictive or over-restrictive verification) and faults (i.e., invalid data) guarantees safety from errors, such as Wrong Value, Inconsistent Value, and Wrong Type.

Memory safety ensures the proper access and use of memory in code. That is, pointers to objects are properly initialized, dereferenced, repositioned, or reassigned, and objects are properly allocated, initialized, read, written, resized, cleared, or deallocated. It is addressed by the BF Memory Bugs Model (see Fig. 9) operation flow and the BF MAD, MMN, and MUS classes (see BF _MEM at [1]) that define why, where, and how memory safety could break.

Allocation in excess or failure to deallocate unused objects (see the MMN Memory Overflow and Memory Leak final errors, correspondingly) could exhaust memory. The former impacts spatial memory safety. The latter directly impacts temporal safety and indirectly impacts spatial memory safety. Both enable DOS failures.

Pointer Safety ensures that an object is only accessed via its proper pointers (owners). It relates to the MAD, MAL, and MDL operations (see Fig. 9) that assign or reassign the object pointer (owner): Initialize Pointer, Allocate, and Reassign. Use of Wild Pointer, Untrusted Pointer, Cast Pointer, or Forbidden Address (including Null Pointer) would break pointer safety and lead to final errors such as Object Corruption, Memory Leak, Type Confusion, and NULL Pointer Dereference, respectively. Subsequently, bugs and faults covered by any non-_MEM classes, whose operations produce such pointers, should also be avoided.

According to the proper memory-related operation flow (see Fig. 9), a pointer may be initialized before or after the allocation of its object. However, it must be initialized before it is used to address its object, repositioned after the reallocation of its object, and reassigned after the deallocation of its object. These correspond to the MAD Wild Pointer and Dangling Pointer errors. If an object is reallocated because of being extended or reduced, all of its owners must be repositioned.

An object must not be read before it is initialized (i.e., the first write) and must be cleared (i.e., the last write) before it is deallocated. An unneeded object must be cleared and deallocated, and all of its pointers (owners) must be reassigned. It should not be possible to access and use its data after it is deallocated. These correspond to the BF MUS Uninitialized Object error and Not Cleared Object, Memory Leak, and Use After Deallocate (i.e., use after free or use after return) final errors. Memory leaks enable IEX and DOS failures. The use of deallocated objects enables IEX, TPR, DOS, and ACE failures.

Temporal memory safety may depend on input data safety. For example, verification of an input size toward the actual size of a buffer before Read or Write will eliminate related buffer overflows. Spatial memory safety may depend on data type safety. For example, avoiding Cast-related data errors that may lead to the use of an incorrect element size and Reposition overbound or underbound will eliminate related buffer overflows.

Data type safety ensures the proper use of entities (e.g., objects, functions, and data types) in code. That is, objects, functions, and data types are properly declared, defined, and referenced; objects are properly typecast or coerced; and functions are correctly called to perform error-free type-related computations. It is addressed by the BF Data Type Bugs Model (see Fig. 10) operation flow and the BF DCL, NRS, TCM, and TCV classes (see BF _DAT at [1]) that define why, where, and how data type safety could break.

Data type safety has both temporal and spatial aspects. Temporal data type safety ensures the use of data values that are compatble and data types that are non-confused with the declared data type of an object. Enttes must not only be declared but also defined and their names properly resolved and bound. Compute and evaluate functions must also be defined with the appropriate argument data types. Temporal data type safety is mostly covered by the type system of the programming language. However, DCL bugs that cause errors (e.g., Missing Overloaded Function) or propagate to faults (e.g., Wrong Argument Type) could stll break data type safety. Spatial data type safety ensures proper object type conversions and use of its layout. It is addressed by the operations that affect the interpretaton of the object layout or the elements’ size along the y-axis of the DAT Bugs Model (see Fig. 10): TCV Cast and Coerse. Examples of spatial data type safety are cast pointer safety, coerced object safety, and subtype safety. The first prevents a pointer and its object from having incompatble data types. A declared overloaded function must have implementations for all of the needed argument types. Otherwise, Coerce will be forced on the argument values. The last exam-ple prevents a pointer and its object from having confused data types. A cast pointer can cause different element size interpretatons and overall object size that may lead to buffer overflows. A wrong argument type coercion can result in truncated or rounded data val-ues. Downcastng a pointer to a sibling class can cause Subtype Confusion and enable an ACE or RCE (of functions of the sibling class) failure.

The methodology for the definition of secure coding principles by software, firmware, or hardware execution phases involves the following seven steps (also see Fig. 22):

While the BF formal language is descriptive, the secure coding principles are prescriptive against bugs and faults per operation that break specific kinds of code safety.

For more secure coding principles and details, refer to the forthcoming SP 800-231F, Bugs Framework: Secure Coding Principles.

The BF features generation tools that reflect the BF taxonomy, models, and formal language syntax and semantics. The BFCWE tool and the BFCVE tool facilitate the generation of formal weakness and vulnerability specifications. The BF tool guides the creation of complete BF vulnerability specifications. The related BF APIs at [1] provide BF data retrieval and specific tool functionalities.

The BFDB database hosts the BF data. The BF taxonomy structure and semantics rules are organized via a relational database with graph features and via XML and JSON data interchange formats (query them via the BF API at [1]). The BFDB contains the types, names, and definitions of the BF taxons, their relationships within the taxonomy, and the BF weakness and vulnerability semantic relation and propagation matrices and operation flow graphs. The BF mashup database organizes additional data for querying BF toward the CWE, CVE, NVD, GitHub [37], KEV [6], and Exploit Prediction Scoring System (EPSS) [38].

The BFCWE tool is utilized to generate the graphical representations of the CWE2BF mappings for enhanced understanding as directed graphs with parent-child CWE relationships. Examples include _INP CWE2BF [16], _MEM CWE2BF [17], and _DAT CWE2BF [18].

The BFCWE tool is utilized to generate the formal BF specification of each weakness as an entry of the BFCWE security weakness dataset and its graphical representation. However, there could be a set of corresponding BF specifications for some CWEs. For example, the natural language descriptions, demonstrative examples, and potential mitigations for CWE-125 reveal the ⟨Overbound Pointer, Read⟩→Buffer Over-Read and ⟨Underbound Pointer, Read⟩→Buffer Over-Read possible weakness triples. Subsequently, these are the possible BF specifications for the main weakness of a CVE mapped to CWE-125. Figure 23 shows their generated graphical representation.

The BFCWE tool is also useful for the generation and analysis of CWE directed graphs by other criteria. For example, see the directed graphs of hardware CWEs and their analysis in NIST IR 8517 [41].

For more details, refer to the forthcoming SP 800-231G, Bugs Framework: Tools and APIs.

The BF relational database, the NVD Representational State Transfer Application Programming Interface (REST API), and the GitHub REST API are utilized to extract CVEs with assigned CWEs for which Code with Fix is available. For example, as of June 20, 2024, there are 5 162 CVEs that map to BF _INP [1, 16] weakness triples by CWE, 4 484 CVEs that map to BF -MEM [1, 17], and 629 CVEs that map to BF _DAT [1, 18] for which GitHub diffs are available via the NVD. Other repositories may also provide fix commits and even the code of vulnerable functions (e.g., DiverseVul [43]).

The CVE Code with Fix can then be examined by security researchers or utilizing AI and compared with the generated chains of weakness triples to pinpoint the unique unambiguous BF vulnerability specification. For that, the BF tool functionality and automated code analysis — including via large language models (LLMs) — can be used.

Fig. 24. Generated BF weakness chains for Heartbleed

The BFCVE tool generates graphical representations of the BFCVE formal specifications to enhance understanding (see Fig. 21). Related BF tools functionality is the generation of the webpages for the BF class taxonomies (e.g., BF MUS) and the BFCVE specifications (e.g., BF CVE-2014-0160) of the BF website [1].

For more details, refer to the forthcoming SP 800-231G, Bugs Framework: Tools and APIs.

The BF tool is a GUI application that works with both the BF relational database and the BF in XML or JSON format; the latter is useful when the database is unavailable [44]. It allows users to create a new BF CVE specification, save it as a machine-readable .bfcve file, and open and browse previously created .bfcve specifications [22].

Fig. 25. BF GUI tool

If a CVE is being specified, the user can select CVE Year and CVE ID in the CVE Details GroupBox to display its description, vendor, and product from the CVE repository and its CVSS [10, 11] severity score from the NVD. To create a BFCVE specification of that CVE, the user is guided to define an initial weakness, possible propagation weaknesses, and a final weakness leading to a failure. If a vulnerability has only one underlying weakness, it would be both the initial and final weakness.

To start defining a weakness, the user has to select a BF weakness class from the BF Class TreeView in the Weakness GroupBox container, where the classes are grouped by BF class types as parent nodes. The selection of a class populates the five TreeView controls in the Weakness GroupBox container: Bug/Fault, Operand, Error/Final Error, Operation Attributes, and Operand Attributes. To specify the weakness, the user has to select child nodes from the five TreeView controls and enter comments in the text boxes beneath them.

The BF tool can enforce that the initial weakness starts with a bug and the rest of the weaknesses start with a fault. However, this is not necessary for partial specifications or if a vulnerability starts with a hardware defect-induced fault. The Bug/Fault label changes to Bug when the initial weakness is viewed and to Fault when the propagation or final weakness is viewed. In the case of a bug, the child nodes are only allowed under the Code and Specification nodes. In the case of a fault, the child nodes are only allowed under the Data, Type, and Address nodes. Tooltips with term definitions are displayed over all TreeView nodes. The BF tool also enforces that the weakness with the final error consequence is the final weakness leading to a failure.

Once a weakness is specified, the user can proceed via the >> button and create the next weakness of the vulnerability chain. Weakness chaining is restricted by the error-to-fault by type match rule, which — to a large extent — also restricts to meaningful operation flow, as the BF classes are developed to adhere to the BF bugs models that are specific to their BF class types. The Generate BF Description button displays a draft BF description based on the selected values from the five TreeView controls and Comment text boxes.

Figure 26 presents the BF specification of the main vulnerability chain of Heartbleed in XML format generated by the BF tool. In addition to the XML attributes that relate to the BF Taxonomy, the CVE-2014-0160.bfcve also contains generated natural language descriptions, programming language, links to reports, code with bugs, code with fixes, commit IDs, authors, and code locations (i.e., lines) per weakness. For more details, see BF CVE-2014-0160 at [1].

The BF tool demonstrates how the BF taxonomy and causation and propagation rules tie together into the strict BF formal language. It uses the BFCVE tool functionality to generate graphical representations of the BF formal specifications to enhance understanding. For example, refer to the BFCVE-2014-0160 and related BF taxon definitions at [1].

For more details, refer to the forthcoming SP 800-231G, Bugs Framework: Tools and APIs.

Fig. 26. BF Heartbleed in XML

The BF formalism enables systematic comprehensive labeling of common weakness types (including CWEs) and publicly disclosed vulnerabilities (including CVEs). The BF tools and APIs enable the generation of weakness and vulnerability specifications.

As of June 20, 2024, 31 % of the CWEs and 64 % of the CVEs labeled by the NVD with CWEs map to BF INP, MEM, and DAT classes. These provide a solid base for the creation of comprehensively labeled BFCWE weakness and BFCVE vulnerability datasets.

The BF and the continuous development of BFCWE and BFCVE datasets would allow for multidimensional representations of vulnerabilities in contrast to the one-dimensional representation provided by the CVE enumeration [8].

There are 938 CWEs [3] as of June 20, 2024. Of those, 157 map to the BF _INP [1, 16] class type; 60 map to BF _MEM [1, 17]; and 72 map to BF _DAT [1, 18]. These 289 unique CWEs form 31 % (see Fig. 27) of the CWE repository and provide the basis for the systematic creation of a comprehensively labeled BFCWE weakness dataset. Most of them represent the most dangerous weakness types by BF final error: Injection and Memory Corruption/Disclosure [45].

CWEs by BF Class Type

157(17%)

60(6%)

72(8%)

649(69%)

BF _INP BF _MEM BF _DAT Others Fig. 27. CWEs by BF class types

The NVD uses the 130 “most commonly seen weaknesses” from CWE View-1003 [46] to label CVEs but may also list other CWEs assigned by third-party contributors. The BFCWE dataset may cover software, firmware, or hardware weakness types that are not listed in the CWE.

The methodology for the creation of a BFCWE dataset that utilizes the BF formal language involves the following four steps:

As the BFCWE specifications are essentially partial BFCVE specifications, the matrix and dataset are also continuously enriched by newly developed BF specifications of CVEs and other reported security vulnerabilities. All developed BFCWE specifications are added to the comprehensively labeled BFCWE dataset (query it via the BFCWE API at [1]).

The BFCWE dataset augments the NVD (see [47]) and the CWE via formal BF specifications of common weaknesses as BF weakness triples and severity-related attributes. However, the BF has the expressive power to clearly describe any security weakness, not only the types listed in the CWE.

There are over 180 472 CVEs labeled with CWEs by the NVD [5] as of June 20, 2024. Of those, 68 513 map to the BF _INP [1, 16] class type by final error, 46 231 map to MEM [1, 17], and 3 631 map to _DAT [1, 18] (see Fig. 28). These 118 375 unique CVEs represent 64 % of the CVEs labeled with CWEs and provide the basis for the systematic creation of a comprehensively labeled BFCVE vulnerability dataset. Most of them relate to the most dangerous weakness types by BF final error: Injection and Memory Corruption/Disclosure [45].

The methodology for the creation of a BFCVE dataset that utilizes the BF formal language involves the following nine steps:

Fig. 28. CVEs by BF class types

A key part of the BFCVE dataset generation is the use of preliminary sets of partial BF specifications of CVEs for which Code with Fix is available. These CVE sets are generated by querying the NVD and specific GitHub repositories toward the BFDB. For example, Fig. 29 shows a SQL query for vulnerabilities related to the BF _MEM class type [1, 17] toward a repository with fix commits that are extracted via the GitHub REST API. The query also identifies the possible BF chains of weaknesses for each vulnerability. Security experts and LLMs can then conduct deep code analysis to create the complete BF vulnerability specifications.

Fig. 29. NVD-GitHub-BF query for MEM CVEs

A similar NVD-GitHub-BF query is used to generate the BFCVE Partial dataset of CVEs for which GitHub Code with Fix is available. As of June 20, 2024, there are 5 162 BF INP CVEs with GitHub commits in NVD, 4 484 MEM CVEs, and 629 DAT CVEs.

This methodology would also guide the creation of BF specifications of vulnerabilities for which code is not available, and insights from existing BF specifications would contribute to their analyses. Going backward from a final weakness would reveal options for previous weaknesses until a weakness with a bug as a cause is reached. For example, going backward from ⟨Wrong Size, Reposition⟩→Overbound Pointer reveals that the previous causing weakness is a BF Data Validation (DVL) initial weakness among ⟨Missing Code / Erroneous Code / Under-Restrictive Policy / Over-Restrictive Policy, Verify / Correct⟩→Wrong Value / Inconsistent Value.

Developed BFCVE specifications are added to the comprehensively labeled BFCVE dataset (query it via the BFCVE API at [1]). The BF semantic matrices, graphs, and datasets are also continuously enriched by the newly developed formal BF specifications of CVEs and other reported security vulnerabilities.

The BFCVE dataset augments the NVD (see [47]) and CVE via formal BF specifications of thepubliclydisclosedvulnerabilitiesaschainsofweaknesses. However,theBFhastheex-pressivepowertoclearlydescribeanysecurityweaknessandvulnerability,notonlythose listedintheCWEandCVE.Ithasitsowndatabaseswithcausalweaknesstaxonomiesand formalvulnerabilityspecificationscomposedofunderlyingweaknessesspecifications.

For more details, refer to the forthcoming SP 800-231H, Bugs Framework: Datasets and Classifications.

The BF Vulnerability Classification Model (see Fig. 30) defines how the BF taxonomy and tools are utilized to generate BFCWE and BFCVE datasets (see Sec. 11) and query them and possibly other vulnerability-related repositories to create the BFVul dataset of diverse multidimensional vulnerability classifications based on common properties and similarities.

The methodology for the creation of BF-based vulnerability classifications involves the following steps:

Security vulnerabilities could be classified by common root causes (i.e., software or firmware bugs or hardware defect-induced bugs or faults), such as declaring a variable of a wrong data type. They could also be classified by any other BF taxons, such as propagating faults, common final errors, operation and operand attributes, identical BF specifications (i.e., chains of weaknesses), and even the number of underlying weaknesses.

The BF operation and operand attributes provide insight into the severity of the weaknesses and how they relate to commonly used scores, such as CVSS [11] and EPSS [38].

Their analysis would allow for deeper research on the most significant [45] and most ex-ploited [48] weaknesses and vulnerabilities. Intriguing classifications by BF classes and CPE [49] data may reveal systematic input/output check safety, memory safety, data type safety, and other secure coding problems by particular vendors and products.

These multidimensional BF vulnerability classifications (query some of them via the BFVul API at [1]) would contribute to a deeper analysis and refined understanding of security weaknesses, vulnerabilities, exploits, and failures. They would enable more focused cybersecurity research and the highly informed development of effective countermeasures against potential security threats and specific exploits.

For more details, refer to the forthcoming SP 800-231H, Bugs Framework: Datasets and Classifications.

The BF supports the development of diverse systems related to bug identification and triaging, vulnerability detection, analysis, prioritization, reporting, and resolution or mitigation. The methodology for the development of a BF-based system involves the following steps:

An LLM may also be prompted to generate the report for that CVE given a CVE description, examples, reports, other references, the code with bug, the code with fix, BF security concept definitions, machine-readable representations of BF taxonomies (including definitions for the taxons and taxon types), and exemplary BF specifications (i.e., entries from the BFCVE dataset).

For more details, refer to the forthcoming SP 800-231I, Bugs Framework: Systems.

This Special Publication presents an overview of the Bugs Framework (BF) [1] systematic approach and methodologies for the classification of bugs and faults per orthogonal by operation execution phases, formal specification of weaknesses and vulnerabilities, definition of secure coding principles, generation of comprehensively labeled weakness and vulnerability datasets and vulnerability classifications, and development of BF-based algorithms and systems.

The BF weakness and failure taxonomies and bugs and vulnerability models form the basis for the BF ACFG that generates the BF formal language. The BF also helps formally define secure coding principles, such as input/output check safety, memory safety, and data type safety. The BF formal language is descriptive in that it is used to formally specify encountered or predicted weaknesses and vulnerabilities. The BF secure coding principles are prescriptive in that they prevent the bugs and faults per operation that break specific related kinds of code safety.

The BF formalism supports a deeper understanding of vulnerabilities as chains of weaknesses and allows for backward bug identification from a failure. It enables the development of new static and dynamic analysis, simulation, and emulation algorithms (e.g., see [2]). AI or formal methods-enabled capabilities could be used to identify bugs and detect, analyze, prioritize, and resolve or mitigate vulnerabilities (i.e., fix the bug or a fault of each vulnerability, respectively) to secure critical infrastructure and supply chains.

The weakness and vulnerability BF specification datasets augment the CWE, CVE, and NVD. However, the BF has the expressive power to clearly describe any other security weaknesses and vulnerabilities. It also allows for the prediction and identification of as yet unencountered security weakness types, which allows for the prediction and detection of new kinds of vulnerabilities.

The BF aims to become the new standard for the specification and labeling of security weaknesses and vulnerabilities. It enables the clear and precise expression of security bugs, weaknesses, vulnerabilities, and failures. Government institutions could improve the descriptions in public vulnerability repositories and create advanced policies and guidelines for software, firmware, and hardware testing. Security companies could improve their testing tools and bug and vulnerability reports. Academics could teach better about security bugs, weaknesses, and vulnerabilities and conduct deeper security vulnerability and failure research. All of these would lead to unambiguous communication about cybersecurity, the increased precision of code review tools, and a decrease in security bugs, weaknesses, and vulnerabilities.

References

[1] Irena Bojanova (2014-2024) NIST Bugs Framework (BF) Website. Available at https: //usnistgov.github.io/BF. [2] Kedrian James, K Valakuzhy, K Snow, F Monrose (June 2024) CrashTalk: Automated Generation of Precise, Human Readable, Descriptions of Software Security Bugs. CO-DASPY ’24: Proceedings of the Fourteenth ACM Conference on Data and Application Security and Privacy, pp 337 – 347. htps://doi.org/10.1145/3626232.3653256 [3] MITRE (2006-2024) Common Weakness Enumeration (CWE). Available at https://cw e.mitre.org. [4] MITRE (1999-2024) Common Vulnerabilities and Exposures (CVE). Available at https: //cve.mitre.org. [5] NIST (1999-2024) National Vulnerability Database (NVD). Available at https://nvd.ni st.gov. [6] CISA (2021-2024) Known Exploited Vulnerabilities Catalog (KEV). Available at https: //www.cisa.gov/known-exploited-vulnerabilities-catalog. [7] MITRE CWE History. Available at https://cwe.mitre.org/about/history.html. [8] David E Mann, S M Christey (Jan. 8, 1999) Towards a Common Enumeration of Vulner-abilites. Available at https://www.cve.org/Resources/General/Towards-a-Commo n-Enumeration-of-Vulnerabilities.pdf. [9] MITRE CVE History. Available at https://www.cve.org/About/History. [10] Peter Mell, K Kent, S Romanosky (2006) Common vulnerability scoring system. Avail-able at https://tsapps.nist.gov/publication/get pdf.cfm?pub id=50899. [11] FIRST (2015-2024) Common vulnerability scoring system special interest group. Avail-able at https://www.first.org/cvss. [12] Irena Bojanova (Dec. 9, 2014) Formalizing Software Bugs. NIST, ITL, SSD. Available at https://www.nist.gov/publications/formalizing-software-bugs. [13] Irena Bojanova (Apr. 8, 2015) Towards a ’Periodic Table’ of Bugs. NIST, ITL, SSD. Avail-able at https://www.nist.gov/publications/towards-periodic-table-bugs. [14] Yan Wu, I Bojanova, Y Yesha (2015) They Know Your Weaknesses -Do You?: Reintro-ducing Common Weakness Enumeration. CrossTalk (The Journal of Defense Software Engineering), pp 44–50. Available at https://web.archive.org/web/20180425211828 id /http://static1.1.sqspcdn.com/static/f/702523/26523304/1441780301827/20150 9-Wu.pdf?token=WJEmDLgmpr3rIZHriubA20L%2F1%2F4%3D. [15] Irena Bojanova, P E Black, Y Yesha, Y Wu (October 2016) The NIST Bugs Framework (BF): A Structured Approach to Express Bugs. 2016 IEEE International Conference on Software Quality, Reliability and Security (QRS), pp 175–182. htps://doi.org/10.1109/

[16] Irena Bojanova, C E Galhardo (October 2021) Input/Output Check Bugs Taxonomy: In-jecton Errors in Spotlight. 2021 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW), pp 111–120. htps://doi.org/10.1109/ISSREW5361 1.2021.00052

[17] Irena Bojanova, C E Galhardo (July 2021) Classifying Memory Bugs Using Bugs Frame-work Approach. 2021 IEEE 45th Annual Computers, Software, and Applications Con-ference (COMPSAC), pp 1157–1164. htps://doi.org/10.1109/COMPSAC51774.2021. 00159 [18] Irena Bojanova, C E Galhardo, S Moshtari (October 2022) Data Type Bugs Taxon-omy: Integer Overflow, Juggling, and Pointer Arithmetics in Spotlight. 2022 IEEE 29th Annual Software Technology Conference (STC)), pp 192–205. htps://doi.org/

[19] Constable S (Febryary 29, 2024) Chips & Salsa: Industry Collaboraton for new Hard-ware CWEs. Available at https://community.intel.com/t5/Blogs/Products-and-Solut ions/Security/Chips-Salsa-Industry-Collaboraton-for-new-Hardware-CWEs/post/1 575521. [20] Kedrian James, Y Du, S Das, F Monrose (December 2022) Separatng the Wheat from the Chaff: Using Indexing and Sub-Sequence Mining Techniques to Identify Related Crashes During Bug Triage. 2022 IEEE 22nd International Conference on Software Quality, Reliability and Security (QRS), pp 31–42. htps://doi.org/10.1109/QRS575 17.2022.00014 [21] Drew Malzahn, Z Birnbaum, C Wright-Hamor (2020) Automated Vulnerability Testing via Executable Atack Graphs. 2020 International Conference on Cyber Security and Protecton of Digital Services (Cyber Security) (IEEE), p 1–10. htps://doi.org/10.1109/ CyberSecurity49315.2020.9138852 [22] Irena Bojanova (Jan.-Feb. 2024) Comprehensively Labeled Weakness and Vulnerabil-ity Datasets via Unambiguous Formal NIST Bugs Framework (BF) Specifications. IEEE IT Professional, Vol. 26, 1, pp 60–68. htps://doi.org/10.1109/MITP.2024.3358970 [23] Wikipedia (2023) Heartbleed. Available at https://en.wikipedia.org/wiki/Heartbleed. [24] IEEE Computer Society (September, 1990) IEEE Standard 610.12-1990, Glossary of Sof-ware Engineering Terminology. Available at https://ieeexplore.ieee.org/stamp/stam p.jsp?arnumber=159342. [25] CISA (2022) ICS Advisory (ICSA-21-119-04). Available at https://www.cisa.gov/uscert/ ics/advisories/icsa-21-119-04. [26] Omri Ben-Bassat TA (2021) ERROR: BadAlloc! - Broken Memory Allocators Led to Millions of Vulnerable IoT and Embedded Devices. Blackhat USA 2021 Available at https://www.youtube.com/watch?v=lSvygMc8uc0. [27] Assane Gueye, C E Galhardo, I Bojanova (Jul.-Aug. 2023) Critical Software Security Weaknesses. IEEE IT Professional, Vol. 25, 4, pp 11–16. htps://doi.org/10.1109/MITP .2023.3297387 [28] OpenSSL (2005) Openssl/ssl/d1 both.c. Available at https://git.openssl.org/?p=ope nssl.git;a=blob;f=ssl/d1 both.c;h=0a84f957118afa9804451add380eca4719a9765e;h b=4817504d069b4c5082161b02a22116ad75f822b1. [29] Sean Cassidy (April, 2014) Diagnosis of the OpenSSL Heartbleed Bug. Available at ht tps://www.seancassidy.me/diagnosis-of-the-openssl-heartbleed-bug.html.

[30] OpenSSL (2014) openssl/openssl, openssl 1 0 1-stable. Available at https://github.c om/openssl/openssl/commit/96db9023b881d7cd9f379b0c154650d6c108e9a3. [31] ISO/IEC 14977 (1996) International Standard: Information technology — Syntactic metalanguage — Extended BNF. Available at https://www.iso.org/standard/261 53.html. [32] Alfred Aho, M Lam, R Sethi, J Ullman (2006) Compilers: Principles, Techniques, and Tools (Addison-Wesley). [33] Donald Knuth (1968) Semantics of context-free languages. Math. Systems Theory 2,p 127–145. htps://doi.org/10.1007/BF01692511 [34] Software Engineering Institute (2016) SEI CERT C Coding Standard: Rules for Develop-ing Safe, Reliable, and Secure Systems. Available at https://resources.sei.cmu.edu/ downloads/secure-coding/assets/sei-cert-c-coding-standard-2016-v01.pdf. [35] Software Engineering Institute (2016) SEI CERT C++ Coding Standard: Rules for Devel-oping Safe, Reliable, and Secure Systems. Available at https://resources.sei.cmu.ed u/downloads/secure-coding/assets/sei-cert-cpp-coding-standard-2016-v01.pdf. [36] Open Web Application Security Project (2010) OWASP Secure Coding Practces-Quick Reference Guide. Available at https://owasp.org/www-project-secure-coding-pract ices-quick-reference-guide. [37] GitHub (2008) GitHub. Available at https://github.com. [38] FIRST (2021-2024) Exploit Prediction Scoring System (EPSS). Available at https://ww w.first.org/epss. [39] Irena Bojanova (2020-2024) NIST Bugs Framework (BF), BFCWE Tool. Available at ht tps://usnistgov.github.io/BF/info/tools/bfcwe-tool. [40] Irena Bojanova, J J Guerrerio (Sept.-Oct. 2023) Labeling Software Security Vulnerabil-ites. IEEE IT Professional, Vol. 25, 5, pp 64–70. htps://doi.org/10.1109/MITP.2023. 3314368 [41] Peter Mell, Irena Bojanova (2024) NIST IR 8517, Hardware Security Failure Scenarios: Potental Weaknesses in Hardware Design. Available at https://doi.org/10.6028/NI

[42] Irena Bojanova (2020-2024) NIST Bugs Framework (BF), BFCVE Tool. Available at https://usnistgov.github.io/BF/info/tools/bfcve-tool.

[43] Chen Y, at all (2023) DiverseVul: A New Vulnerable Source Code Dataset for Deep Learning Based Vulnerability Detection. Available at https://github.com/wagner-group/diversevul.

[44] Irena Bojanova (2020-2024) NIST Bugs Framework (BF), BF Tool. Available at https://usnistgov.github.io/BF/info/tools/bf-tool.

[45] Carlos EC Galhardo, P Mell, I Bojanova, A Gueye (December 2020) Measurements of the Most Significant Software Security Weaknesses. 2020 Annual Computer Security Applications Conference (ACSAC), p 154–164. https://doi.org/10.1145/3427228.3427257

[46] MITRE (2023) Weaknesses for Simplified Mapping of Published Vulnerabilities. Available at https://cwe.mitre.org/data/definitions/1003.html.

[46] MITRE (2023) Weaknesses for Simplified Mapping of Published Vulnerabilities. Avail-able at https://cwe.mitre.org/data/definitions/1003.html. [47] Kevin Poireault (Mar. 28, 2024) NIST Unveils New Consortum to Operate National Vulnerability Database. Available at https://www.infosecurity-magazine.com/news /nist-unveils-new-nvd-consortium/#: ∼:text=NVD’s%20One%2Dto%2DFive%20Year, years%2C%20especially%20around%20software%20identfication. [48] Peter Mell, I Bojanova, Carlos EC Galhardo (May-Jun. 2024) Measuring the Ex-ploitaton of Weaknesses in the Wild. IEEE IT Professional, Vol. 26, 2, pp 14–21. htps://doi.org/10.1109/MITP.2024.3399485 [49] NIST Common Platform Enumeration (CPE). Available at https://csrc.nist.gov/projec ts/security-content-automation-protocol/specifications/cpe.