# SecureFalcon: Are We There Yet in Automated Software Vulnerability Detection
with LLMs?

Mohamed Amine Ferrag14, Ammar Battah1, Norbert Tihanyi1, Ridhi Jain1, Diana
Maimuţ1,
Fatima Alwahedi1, Thierry Lestable1, Narinderjit Singh Thandi1,
Abdechakour Mechri1, Merouane Debbah2, and Lucas C. Cordeiro3

1Technology Innovation Institute, UAE  2Khalifa University of Science and
Technology, UAE  3University of Manchester, UK  4Corresponding author:
<EMAIL_ADDRESS>
###### Abstract

Software vulnerabilities can cause numerous problems, including crashes, data
loss, and security breaches. These issues greatly compromise quality and can
negatively impact the market adoption of software applications and systems.
Traditional bug-fixing methods, such as static analysis, often produce false
positives. While bounded model checking, a form of Formal Verification (FV),
can provide more accurate outcomes compared to static analyzers, it demands
substantial resources and significantly hinders developer productivity. Can
Machine Learning (ML) achieve accuracy comparable to FV methods and be used in
popular instant code completion frameworks in near real-time? In this paper,
we introduce SecureFalcon, an innovative model architecture with only 121
million parameters derived from the Falcon-40B model and explicitly tailored
for classifying software vulnerabilities. To achieve the best performance, we
trained our model using two datasets, namely the FormAI dataset and the
FalconVulnDB. The FalconVulnDB is a combination of recent public datasets,
namely the SySeVR framework, Draper VDISC, Bigvul, Diversevul, SARD Juliet,
and ReVeal datasets. These datasets contain the top 25 most dangerous software
weaknesses, such as CWE-119, CWE-120, CWE-476, CWE-122, CWE-190, CWE-121,
CWE-78, CWE-787, CWE-20, and CWE-762. SecureFalcon achieves 94% accuracy in
binary classification and up to 92% in multiclassification, with instant CPU
inference times. It outperforms existing models such as BERT, RoBERTa,
CodeBERT, and traditional ML algorithms, promising to push the boundaries of
software vulnerability detection and instant code completion frameworks.

###### Index Terms:

FalconLLM, Large Language Model, Software Security, Security, Generative Pre-
trained Transformers.

##  I Introduction

As we are undoubtedly passing through a digital age, technology affects every
aspect of our lives [1]. In such a context, vulnerability detection tools are
essential safeguards in our continuously evolving digital landscape [2, 3].
With the emergence of new technologies, the palette of cyber threats becomes
wider and more sophisticated in terms of employed techniques. Vulnerability
detection tools assist in scanning, probing, and inspecting software,
identifying weaknesses that could serve as entry points for potential
malicious users or attackers. While integral to software security measures,
vulnerability detection tools encounter inherent limitations in their scope
and efficiency. Such tools typically depend on known patterns and signatures
derived from synthetic datasets, making them less effective for detecting bugs
in real-world software [4]. Furthermore, the datasets used by these tools are
often too small [5] or have a skewed distribution of vulnerable programs [6],
hampering the accuracy of static analyzer tools. Although the advancements in
deep learning (DL) seem promising for vulnerability detection [7, 8, 9, 10],
their accuracy heavily relies on the data quality as well [6, 11]. Most of the
popular datasets are either fully synthetic [12, 13], non-compilable [14, 15,
16], or have an unfair distribution of vulnerable vs non-vulnerable code [11,
15, 17]. Moreover, the labels associated with these datasets are subject to
the detection method used. For instance, manual labeling is affected by human
errors, whereas using static analysis tools to label the data can result in
high false positives [18, 19]. While the DL-based approaches are often
employed for quick inference, they may compromise the model’s accuracy in
detecting bugs. Formal Verification (FV) approaches such as Model Checking
(MC) are preferred for verification in safety-critical systems [20]. Even
though MC provides safety assurances for software systems [21, 22], they are
often expensive, even for a small piece of code. Bounded Model Checking (BMC)
[23, 24] improves the traditional MC techniques by restricting the exploration
to a predefined bound or depth. To prove safety in BMC for programs, we must
compute the completeness threshold (CT), which can be smaller than or equal to
the maximum number of loop iterations occurring in the program. Although BMC
offers performance improvement to some extent, it is still expensive.

Code completion tools are gaining popularity in software engineering, where
rapid inference is essential. For example, tools such as GitHub Copilot
111https://github.com/features/copilot/ and Amazon Code Whisperer
222https://aws.amazon.com/codewhisperer/ suggest code snippets based on
contextual analysis and training data, which, according to recent studies, can
also introduce vulnerabilities [25]. This raises a critical question: Can we
develop a model that detects vulnerabilities efficiently without the lengthy
processing times associated with BMC methods while still maintaining high
accuracy? This is essentially a trade-off between accuracy and speed. BMC
methods can achieve high accuracy by eliminating false positives with
counterexamples and providing stack traces. Despite this, verifying the entire
state space of even simple programs can take hours. This issue is illustrated
in Figure 1, where the red line represents the BMC method achieving high
accuracy over several hours – an impractical timeframe for real-time code
completion tools. Conversely, the blue line represents a Large Language Model
(LLM), which, while not reaching the same accuracy as BMC methods, still
predicts high reliability and can quickly identify software vulnerabilities.

Figure 1: Vulnerable Code Detection Rate (BMC vs LLMs).

The red-highlighted area represents the gap that can only be closed through
rigorous mathematical formal verification [26]. However, overall, formal
program verification is undecidable [27, 28]. We cannot devise a computational
method to decide whether an arbitrary program is error-free. Much progress has
been made in program verification. Nowadays, verification methods create
abstractions to determine whether the program is error-free. Still, for an
arbitrary program that includes unbounded memory usage, we cannot give $100$%
certainty that it is error-free due to the well-known halting problem [27].
However, to achieve high accuracy detection rate for vulnerable code almost
instantly with a fine-tuned model would be a significant achievement. We aim
to minimize this gap (red-highlighted area) as much as possible and
dramatically reduce vulnerability detection times, making it practical for
real-time code completion frameworks. While it is unrealistic to expect LLMs
to match the results of BMC verification tools at this stage, there is promise
in using ML techniques to swiftly identify the most vulnerable programs.
Integrating a robust BMC tool with a pre-trained LLM can enhance the pace of
vulnerability detection, benefiting the overall software development process.
The success of a vulnerability detection model greatly depends on the quality
and relevance of the dataset it uses. Thus, a dataset that provides a balanced
distribution of vulnerable and non-vulnerable programs, mirrors real-world
coding, and is labeled with a reliable method can enhance the model’s
accuracy. In contrast to most available C/C++ vulnerability datasets, the
FormAI dataset [29] 1 has high labeling accuracy as it is labeled by an
unbounded model checker ESBMC [24], 2 contains compilable programs, 3 evenly
distributes vulnerable and neutral programs, and 4 is generated by LLM trained
on real-world open source software, thus, mimicking the prominent developer
errors and making it a highly suitable dataset for training a vulnerability
detection model. The original contributions of our work are summarized as
follows:

  * •

We introduce SecureFalcon, a lightweight and innovative LLM model with only
$121$ million parameters, built on the foundational 40B-parameter FalconLLM
architecture. This model offers significant enhancements and optimizations
specifically tailored for security analysis. SecureFalcon underwent fine-
tuning with the introduction of the FormAI dataset, a specialized collection
designed to accurately classify vulnerabilities within C/C++ code samples.
This process was supported by using the Efficient SMT-based Context-Bounded
Model Checker (ESBMC) tool, enhancing the model’s detection capabilities.

  * •

Since the formal verification tools cannot detect all Common Weakness
Enumerations (CWEs), such as CWE-78, we created an aggregated dataset called
FalconVulnDB, incorporating the SySeVR framework, Draper VDISC, Bigvul,
Diversevul, SARD Juliet, and ReVeal datasets, to enrich SecureFalcon’s
training by leveraging an extensive compilation of public datasets. These
resources collectively cover examples of the top $25$ most critical software
weaknesses identified by the Common Weakness Enumeration (CWE), including but
not limited to CWE-119, CWE-120, CWE-476, CWE-122, CWE-190, CWE-121, CWE-78,
CWE-787, CWE-20, and CWE-762. The FalconVulnDB dataset was used to compensate
for the lack of real project data in the FormAI dataset.

  * •

In terms of performance, SecureFalcon showcases exceptional proficiency in
binary classification, achieving an accuracy rate of $94$% in identifying
vulnerabilities in C/C++ code. Moreover, the model maintains a robust accuracy
rate of $92$% across diverse code samples in multi-classification,
underscoring its effectiveness and reliability in vulnerability detection.
With these results, we outperformed traditional ML algorithms like KNN, LR,
NB, SVM, RRF, DT, and LDA by 11% (with RF achieving 81%), and existing LLM
models like BERT, CodeBERT, and RoBERTa by 4% (with CodeBERT achieving 88%).
This advancement promises to push the boundaries of software vulnerability
detection and instant code completion frameworks.

The rest of this paper is structured as follows. Section II outlines the main
motivation behind our research. Section III overviews the research literature
relevant to software vulnerability detection. Section IV discusses the
methodology and approach employed to create SecureFalcon. Section VI presents
the experimental setup and the evaluation of SecureFalcon’s performance.
Finally, we conclude with Section VII summarizing the key concepts, findings,
and contributions with their corresponding implications.

##  II Motivation

As software development accelerates, so does the complexity of codebases,
making identifying vulnerabilities a paramount concern. A tool that
expeditiously pinpoints vulnerable code offers a proactive defense against
potential exploits, minimizing the window of susceptibility and enhancing
overall software security [30]. Rapid vulnerability detection not only
safeguards against cyber threats but also instills confidence in software
reliability, ensuring the delivery of secure and trustworthy applications
within tight development schedules. Bounded Model Checking (BMC) is a formal
verification technique used in computer science and software engineering to
verify the correctness of critical hardware and software components within a
finite number of steps. The BMC technique extracts the program code, the basis
for generating a control-flow graph (CFG) [31]. In this CFG, each node
represents either a deterministic or non-deterministic assignment or a
conditional statement. The next step involves converting the CFG into a Static
Single Assignment (SSA) form and transforming it into a State Transition
System (STS). The resultant STS can subsequently be converted into an SMT
(Satisfiability Modulo Theories) formula that can be understood by an SMT
solver, such as CVC5 [32], Bitwuzla [33] or Z3 [34]. SMT solver tools can
ascertain whether a counterexample exists for certain properties within a
specified bound $k$. Formally written, given a program $\mathcal{P}$, consider
its finite state transition system, $\mathcal{TS}=\left(S,R,I\right)$. Here,
$S$ is the set of states, $R\subseteq S\times S$ represents the set of
transitions, and $(s_{n},\cdots,s_{m})\in I\subseteq S$ represents the set of
initial states. A state $s\in S$ includes the program counter value, pc, and
program variables. The initial state $s_{1}$ assigns the starting program
location, and each transition $T=(s_{i},s_{i+1})\in R$ has a logical formula
describing the constraints between states. In BMC, we define properties with
logical formulas: $\phi(s)$ for safety/security properties and $\psi(s)$ for
program termination. Notably, termination and error are exclusive:
$\phi(s)\wedge\psi(s)$ is always unsatisfiable. A state is a deadlock if
$T(s_{i},s_{i+1})\vee\phi(s)$ is unsatisfiable. The BMC problem, $\Delta_{k}$
can be expressed as:

$\Delta_{k}=I(s_{1})\wedge\bigwedge^{k-1}_{i=1}T(s_{i},s_{i+1})\wedge\bigvee^{k}_{i=1}\neg\phi(s_{i}).$
(1)

where $I$ is the initial states set, and $T(s_{i},s_{i+1})$ the transition
relation of $\mathcal{TS}$. This formula captures $\mathcal{TS}$ executions of
length $k$, and if it is satisfied, a state violates $\phi$ within the $k$
limit. A counterexample, or trace, for a violated $\phi$ is a sequence of
states $s_{1},\ldots,s_{k}$. If Equation (1) is unsatisfiable, no error state
exists within $k$ steps, indicating no vulnerabilities in the program up to
the $k$ bound. Checking property violations using BMC techniques can be time-
consuming even for relatively small programs due to lengthy loops that require
unwinding or intricate function calls [24]. Consider Listing 1 where an
arithmetic overflow occurs due to the nature of the nested loops and the
accumulation of values in the sum variable. The code consists of two nested
loops iterating from $0$ to $999,999$ (i and j both range from $0$ to
$99,999$). Within each iteration, the product of i * j is added to the sum
variable. Since the sum variable accumulates these products (sum += i * j;),
it is possible for the sum to exceed the maximum value represented by an int.
When this happens, it causes arithmetic overflow, which means the result is
beyond the range represented by the data type, resulting in an incorrect value
being stored in the sum variable.

Arithemtic overflow example ⬇ 1#include <stdio.h> 2int main() { 3 int i, j; 4
int sum = 0; 5 for (i = 0; i < 1000000; ++i) { 6 for (j = 0; j < 1000000; ++j)
{ 7 sum += i * j; 8 }} 9 printf("Sum:%ld\n", sum); 10 return 0; 11} Listing 1:
Arithmetic overflow on line number 7.

Verifying this program with BMC can take hours due to nested loops requiring
careful unwinding. For example, applying the Efficient SMT-based Context-
Bounded Model Checker (ESBMC) took more than seven hours using $k$-induction.
In contrast, a suitably trained ML algorithm, such as a Large Language Model
(LLM), can quickly pinpoint such issues. LLMs have several advantages over
traditional formal methods like BMC: they can learn from vast amounts of code
and vulnerability patterns, enabling them to generalize and identify errors
efficiently. LLMs are also capable of handling diverse codebases and detecting
vulnerabilities without the extensive manual setup required for BMC. This
example underscores the necessity for a compact model that can swiftly
identify common errors in C programs, enabling quicker detection across
various scenarios. Additionally, LLMs can be integrated into code completion
frameworks with near-instant inference time, providing real-time feedback to
developers and significantly accelerating the development process. This makes
LLMs a superior choice over BMC for many practical applications in software
detection and vulnerability analysis.

##  III Related Work

In recent research, LLMs have been employed for source code summarization [35,
36], which can aid in vulnerability detection. Further, contrastive learning
techniques have been applied to LLMs to improve vulnerability detection
accuracy [37]. Similarly, transfer learning has been widely used in
vulnerability detection and repair with LLMs [38, 39]. Researchers have
significantly improved vulnerability detection performance by pre-training
models on large code corpora and fine-tuning them on vulnerability-specific
datasets. Neural machine translation techniques employed to translate code
snippets into natural language aid in vulnerability detection [40, 41]. By
translating code into human-readable descriptions, models can help developers
understand code snippets’ behavior and potential risks. SySeVR [42] uses DL to
detect slice-level vulnerability by preserving semantic and syntactic
knowledge about the vulnerabilities. Similarly, VulDeePecker [7] also extracts
program slices to detect vulnerabilities. However, as these models are trained
on semi-synthetic datasets, they fail to detect real-world vulnerabilities
[11]. Devign [43] uses a Graph Neural Network (GNN) trained on manually
labeled datasets for vulnerability identification. The Devigen dataset is
constructed from the Linux kernel, QEMU, Wireshark, and FFmpeg, which generate
around 58,000 graphs. However, the dataset only contains non-compilable
functions. Several works have also used transformers’ vulnerability detection
due to their remarkable capabilities in understanding and processing natural
language and code structures [44, 45, 10]. Their attention mechanisms enable
them to capture complex relationships and patterns within text and programming
languages. LLMs such as GPT-3[46] have been explored for code security
analysis and vulnerability detection. Researchers have used GPT to generate
vulnerable code snippets and identify potential security flaws. CodeBERT [44],
a pre-trained language model, has been applied to vulnerability detection in
source code. By fine-tuning the model on labeled vulnerability data,
researchers have achieved promising results in identifying vulnerabilities
such as SQL injection, cross-site scripting (XSS), and buffer overflow [47,
48]. Transformer-based models, like BERT [49] and RoBERTa [45], have also been
utilized for vulnerability detection in various software artifacts. Despite a
recent surge in the application of DL for vulnerability detection [50, 7, 51,
42], a comprehensive solution with high confidence remains elusive [11, 52].
Most DL approaches suffer from four major issues: 1 inadequate model, 2
learning irrelevant features, 3 data duplication, 4 data imbalance [11].

To address these challenges, we employed a modern transformer model, the 40B
parameter FalconLLM, which aids in comprehending semantic dependencies through
extensive training (addressing problem 1). Falcon’s architecture has
demonstrated superior performance to GPT-3, achieving impressive results while
utilizing only a portion of the training compute budget and requiring less
computation at inference time. We fine-tuned the transformer model, leveraging
the obtained understanding of natural language and learning directly from the
source code (addressing problem 2). Further, we carefully pre-process the data
to ensure no duplications or irrelevant features and minimize the class
imbalance (addressing problems 3 and 4). We utilize only a configured portion
of the Falcon-40B model for a light and compact model that fits the assigned
task. Such a design choice stems from language models [53] and thorough
experimentation, pushing us to take a modest approach to the scale of the
model to combat overfitting concerns. We fine-tune the model on C/C++ code
samples to be able to differentiate between vulnerable and non-vulnerable
samples. The final model, which we named SecureFalcon, consists of only 121
million parameters.

##  IV Model Architecture

###  IV-A FalconLLM Model

The FalconLLM40B [54] is one of the best performing open-source
models333https://huggingface.co/spaces/HuggingFaceH4/open_llm_leaderboard - 10
July 2023 that underwent an extensive training procedure on 384 GPUs (A100
40GB). The model’s training procedure incorporated a 3D parallelism strategy
that involved tensor parallelism of 8 (TP=8), pipeline parallelism of 4
(PP=4), and data parallelism of 12 (DP=12). This approach was used in
conjunction with ZeRO (Zero Redundancy Optimizer) to enhance the efficiency of
the training procedure.

The training hyperparameters used for FalconLLM40B were specifically selected
to optimize the model’s learning process. The precision of the model was set
to bfloat16 to balance computational efficiency and numerical precision. The
AdamW![55] optimizer was chosen for its proven ability to achieve good results
in less time. The learning rate was set at 1.85e-4 during the warm-up phase
involving 4 billion tokens, followed by a cosine decay to 1.85e-5, which
allows the model to converge more efficiently. The weight decay was set at
1e-1 to prevent overfitting, while Z-loss was set at 1e-4 to minimize the
discrepancy between the model’s predictions and the true values. Finally, the
batch size was fixed at 1152 with a 100 billion token ramp-up to maximize
computational throughput and stabilize the learning process.

###  IV-B SecureFalcon Model Architecture

The SecureFalcon model, derived from the 40B parameter FalconLLM, includes
components shown in Fig. 2, featuring out_features=12 for multi-classification
and out_features=2 for binary classification.

Figure 2: SecureFalcon model architecture.

The architecture comprises four primary components: Word Embeddings, Encoder
Layers, Final Layer Normalization, and the Scoring Layer.

####  IV-B1 Word Embeddings

Word Embeddings serve as the initial transformation layer in the language
model. This layer transforms discrete words into dense, continuous vectors,
which encapsulate semantic and syntactic information of the words [56]. Their
dimension is $768$, and the model is trained with a vocabulary size $65024$.

Let’s denote the $i$-th word in an input sequence as $input[i]$. The
corresponding word embedding, $e_{i}$, is a row vector obtained from the
embedding matrix $E$, which can be expressed as:

$e_{i}=E(input)[i,:]$ (2)

Here, $E$ represents the embedding matrix with dimensions vocabulary size
$\times$ embedding dimension, which in this case is $65024\times 768$. Each
row in $E$ corresponds to the vector representation of a word in the
vocabulary.

Therefore, an input sequence $input$ of length $n$ is transformed into a
sequence of word vectors $e$ of dimension $n\times 768$. This transformation
can be depicted as:

$e=[e_{1},e_{2},\ldots,e_{n}],\text{where}\,e_{i}=E(input)[i,:]$ (3)

These word embeddings, $e_{i}$, are fed into subsequent layers in the model.
They encapsulate rich information about the semantics and syntactic roles of
the words and their context, providing a dense representation that assists in
better understanding and generating language.

####  IV-B2 Decoder Layers

These constitute the main portion of the language model and comprise four
stacked transformer layers [57]. Each layer includes the following components:

  * •

Layer Normalization: This regularization technique standardizes the inputs
across the feature dimension, making the model more stable and faster to train
[58]. The parameters for this layer are 768-dimensional vectors. It’s computed
using the formula:

$\hat{x}=\frac{x-\mu}{\sigma}$ (4)

where $x$ is the input, $\mu$ is the mean, $\sigma$ is the standard deviation,
and $\hat{x}$ is the normalized output. This operation is applied to each
feature independently.

  * •

Self-Attention with Rotary Position Embedding (RoPE): Recent advancements in
position encoding have shown its effectiveness within the Transformer
architecture, offering valuable supervision for dependency modeling between
elements at different sequence positions. In the pursuit of integrating
positional information into the learning process of Transformer-based language
models, a novel method, termed Rotary Position Embedding (RoPE), has been
proposed by Su et al. [59]. RoPE uniquely encodes the absolute position using
a rotation matrix while incorporating explicit relative position dependency in
the self-attention formulation. RoPE’s implementation involves applying the
rotation to the query (Q) and key (K) vectors:

$Q^{\prime},K^{\prime}=\text{{rotate}}(Q,K,\text{{RoPE}})$ (5)

Where rotate is a function that applies RoPE to the vectors. The self-
attention function is subsequently defined as:

$\text{{Att}}(Q^{\prime},K^{\prime},V)=\text{{softmax}}\left(\frac{Q^{\prime}K^{\prime
T}}{\sqrt{d_{k}}}\right)V$ (6)

Where $d_{k}$ denotes the dimension of the key vectors. The softmax function
ensures that the aggregate weight of different values equals 1. Division by
$\sqrt{d_{k}}$ is a scaling factor to maintain gradient stability during
optimization. RoPE exhibits several beneficial properties, such as sequence
length flexibility, a decay in inter-token dependency with increasing relative
distances, and the capability of endowing linear self-attention with relative
position encoding.

  * •

MLP (Multilayer Perceptron): The MLP is a type of neural network that
comprises a minimum of three layers of nodes: an input layer, one or more
hidden layers, and an output layer [60]. Each layer is fully connected to the
subsequent layer, signifying that every node in one layer is connected with
every node in the following layer. In this case, the MLP includes an input
layer. This hidden layer uses a Gaussian Error Linear Unit (GELU) activation
function [61] to introduce non-linearity and an output layer. This non-
linearity allows the model to capture and learn complex patterns in the data.
The MLP can be represented as:

$MLP(x)=Lin_{\text{out}}(GELU(Lin_{\text{hidden}}(x)))$ (7)

In this equation, $Lin_{\text{hidden}}$ is the linear transformation
corresponding to the hidden layer, $GELU$ represents the Gaussian Error Linear
Unit activation function, and $Lin_{\text{out}}$ denotes the linear
transformation of the output layer. The variable $x$ represents the input to
the MLP.

Each of the above components is essential to the functionality of the decoder
layer. The layer normalization stabilizes the inputs to the self-attention and
MLP components, the self-attention module allows the model to consider
different parts of the input when generating each word, and the MLP provides
the additional representative capacity to the model.

####  IV-B3 Final Layer Normalization

The output from the last decoder layer undergoes an additional layer
normalization operation to standardize the outputs before the final linear
transformation and softmax operation. This operation follows the same
mathematical principles as the layer normalization in the decoder layers. The
parameters for this layer are also 768-dimensional vectors. This layer
maintains a consistent distribution of activations and gradients across the
network, improving model performance. In the context of language models, this
helps preserve the quality of the generated text. The operation of the final
layer normalization can be represented as:

$\hat{y}=\frac{y-\mu}{\sigma}$ (8)

Where $y$ is the input to the final layer normalization, $\mu$ is the mean,
$\sigma$ is the standard deviation, and $\hat{y}$ is the normalized output.
Similar to the layer normalization in the decoder layers, this operation is
applied to each feature independently. After the final layer normalization,
the 768-dimensional vectors are passed into the final linear layer and softmax
function to generate the output probabilities for each word in the vocabulary.

####  IV-B4 Scoring layer

The scoring stage involves a linear layer that generates vulnerability scores
for the input software code [62]. This layer is engineered to transform the
normalized decoder output of 768 dimensions into a 2-dimensional vector,
aligning with the vulnerability classes ("vulnerable" and "not vulnerable").
Similarly, the output features are expanded to 12 dimensions for multiclass
classification.

Let’s represent the decoder output, which has a dimension of 768, as $d$. In a
binary classification scenario, we denote the weight matrix as $W$ with
dimensions 768x2, and for multiclass classification, as $W$ with dimensions
768x12. Additionally, we denote the bias vector as $b$. Then, the score can be
computed with the linear transformation as:

$\text{{Score}}=W^{T}d+b$ (9)

Where $W^{T}d$ represents the matrix multiplication of the transpose of the
weight matrix $W$ and the decoder output vector $d$. The score vector is then
passed through a sigmoid function to convert the scores into probabilities.
The sigmoid function can be defined as:

$P(\text{{class}}_{i})=\frac{1}{1+e^{-\text{{Score}}_{i}}}$ (10)

Where $P(\text{{class}}_{i})$ is the probability of the i-th class, and
$\text{{Score}}_{i}$ is the score for the i-th class. The final output
represents the model’s prediction of the vulnerability status of the input
code.

The model outputs a score for each category of vulnerabilities. The class with
the highest score is considered the model’s prediction. Being fine-tuned from
the FalconLLM model, this architecture has proven effective for software
vulnerability detection by capturing the complex syntax and semantics of
programming languages, which will be demonstrated in the Experimental
Evaluation Section.

##  V Datasets for Fine-tuning SecureFalcon

To develop a robust model, the choice of dataset is essential. During the
training phase, we utilized two datasets: the FormAI dataset [29] and
FalconVulnDB, an aggregated dataset we created for fine-tuning SecureFalcon,
compiled from all relevant datasets found in the literature.

####  V-1 FormAI dataset

SecureFalcon uses the FormAI dataset444https://ieee-
dataport.org/documents/formai-dataset-large-collection-ai-generated-c-
programs-and-their-vulnerability[29] for fine-tuning the model. The FormAI
dataset includes $112,000$ compilable C code snippets created using the
GPT-3.5-turbo model through a dynamic zero-shot prompting method. Since this
GPT model from OpenAI555https://openai.com/ is trained using real-world open-
source software repositories, the code it generates closely mimics real-world
code behavior. The produced C samples are subsequently verified using the
Efficient SMT-based Context-Bounded Model Checker (ESBMC) [gadelha2018esbmc].
ESBMC is set with a verification timeout of 30 seconds per sample. According
to the 2023 SV-COMP results666https://sv-comp.sosy-
lab.org/2023/results/results-verified/quantilePlot-Overall.svg, this verifier
has successfully addressed the most significant number of verification tasks.
The generated C samples are classified into three categories: verification
successful, verification unknown, and verification failed. The verification
failed class is further divided into specific vulnerability types: arithmetic
overflow, buffer overflow, array bounds violation, NULL pointer dereference,
division by zero, and others. The dataset provides insights into the
distribution of vulnerabilities and serves as a valuable resource for
vulnerability analysis and testing.

In the FormAI dataset, the classification of C programs based on vulnerability
reveals that out of a total of $112,000$ programs, the verification process
was performed on $106,139$ programs. Among these, $57,389$ unique programs
were classified as vulnerable, resulting in $197,800$ vulnerabilities
(vulnerable functions). Table I provides an overview of the number of samples
of the FormAI dataset in two classes, ‘NOT VULNERABLE’ (Class 0) and
‘VULNERABLE’ (Class 1), before and after a data pre-processing stage.

TABLE I: Data Distribution FormAI dataset.

Class | Samples | Before pre-processing | After pre-processing
---|---|---|---
Training | Testing | Training | Testing
0 | 45275 | 40747 | 4528 | 40745 | 4528
1 | 197800 | 178020 | 19780 | 55374 | 15533

0: NOT VULNERABLE, 1: VULNERABLE

Initially, the ‘NOT VULNERABLE’ class had 40,747 training and $4,528$ testing
samples, out of a total of $45,275$, with the figures remaining almost the
same post-pre-processing. The ‘VULNERABLE’ class starts with significantly
more samples, $178,020$ in training, and $19,780$ in testing out of $197,800$.
However, training samples reduce to $55,374$ after pre-processing, and testing
samples decrease to $15,533$. Table II presents the key statistical
measurements of the FormAI dataset. The dataset comprises $243,075$
observations in total. The average or mean value of these observations is
$271.69$, with a standard deviation (Std) of 162.25, indicating the spread or
variability of the dataset. The dataset’s minimum (Min) value is $9$, while
the maximum (Max) value observed is $2,059$. The dataset’s quartile
distribution is also presented, with the 25th percentile ($25$%) at $160$, the
median or the 50th percentile ($50$%) at $235$, and the 75th percentile
($75$%) at $343$. These figures help describe the dataset’s central tendency,
dispersion, and distribution shape.

TABLE II: Statistics of FormAI dataset’s distribution. Statistic | Value
---|---
Count | 243,075
Mean | 271.69
Std | 162.25
Min | 9
25% | 160
50% | 235
75% | 343
Max | 2,059

In addition, the vulnerabilities in the dataset are associated with registered
Common Weakness Enumeration (CWE) identifiers, where each vulnerability class
may map to multiple CWEs. The dataset comprises nine categories that address
the most common vulnerabilities across 42 unique CWEs, including an "others"
category containing various other instances with fewer occurrences.

  1. \scriptsize\arabicenumi⃝

Arithmetic overflow

  2. \scriptsize\arabicenumi⃝

Buffer overflow on scanf()/fscanf()

  3. \scriptsize\arabicenumi⃝

Array bounds violated

  4. \scriptsize\arabicenumi⃝

Dereference failure: NULL pointer

  5. \scriptsize\arabicenumi⃝

Dereference failure: forgotten memory

  6. \scriptsize\arabicenumi⃝

Dereference failure: invalid pointer

  7. \scriptsize\arabicenumi⃝

Dereference failure: array bounds violated

  8. \scriptsize\arabicenumi⃝

Division by zero

  9. \scriptsize\arabicenumi⃝

Other vulnerabilities

Each category is associated with specific CWE numbers that capture the
weaknesses leading to those vulnerabilities. For example, arithmetic overflow
is associated with CWE-190, CWE-191, CWE-754, CWE-680, and CWE-681. The
dictionary of the CWE-IDs associated with vulnerability types is maintained by
the MITRE Corporation777https://cwe.mitre.org/.

The pre-processing steps performed on the FormAI dataset are crucial for
preparing the data before feeding it into a FalconLLM model. The pre-
processing includes removing header information and cleaning the text by
removing HTML tags, links, and email addresses. These steps help standardize
the text data and eliminate noise or irrelevant information hindering the
subsequent analysis. In addition, we calculate the number of words in each
text entry and add a new column for the word count. This new column calculates
the maximum length of an input sequence that the tokenizer will accept. We
convert the categorical ‘label’ column to a numerical representation using
label encoding. Generally, this pre-processing stage guarantees that the
dataset is sanitized, standardized, and prepared for the fine-tuning process
of FalconLLM using the FormAI dataset. Figure 3 presents the top 10 most
frequent vulnerability categories in the FormAI dataset after the pre-
processing. Specifically, we find that ’buffer overflow on scanf’ is the most
prevalent vulnerability, recorded 29,843 times. This is followed by
’dereference failure: array bounds violated’ and ’dereference failure: NULL
pointer’ with 6,187 and 5,436 instances, respectively. Other notable
vulnerabilities include ’dereference failure: invalid pointer’ and several
types of ’arithmetic overflow’ errors, such as on ’sub’, ’add’, ’floating-
point ieee_mul’, ’floating-point ieee_div’, and ’mul’, with counts ranging
from 2,959 to 580. ’Buffer overflow on fscanf’ also emerges as a significant
vulnerability with 625 instances.

BOSDFADFNDFIAOSAOAAOFAODBOFAOM$0$$0.5$$1$$1.5$$2$$2.5$$3$$\cdot
10^{4}$$29{,}843$$6{,}187$$5{,}436$$2{,}959$$2{,}500$$2{,}000$$1{,}000$$900$$625$$580$Vulnerability
typeFrequencyBOS - Buffer overflow on scanf()DFA - Dereference failure: array
bounds violatedDFN - Dereference failure: NULL pointerDFI - Dereference
failure: invalid pointerAOS - Arithmetic overflow on subAOA - Arithmetic
overflow on addAOF - Arithmetic overflow on F-P mulAOD - Arithmetic overflow
on F-P divBOF - Buffer overflow on (f)scanf()AOM - Arithmetic overflow on mul
Figure 3: Top 10 most frequent vulnerabilities categories in the FormAI
dataset.

####  V-2 FalconVulnDB Dataset

We also fine-tuned SecureFalcon using datasets cited in the literature,
specifically: the SySeVR framework [42], Draper VDISC [16], Bigvul [15],
Diversevul [17], SARD Juliet [13], andReVeal [11]. Each dataset consisted of
varying elements: the first included 1,591 programs, the second held 1.27
million functions, the third contained over 264,000 functions, the fourth had
more than 348,000 functions, the fifth comprised over 64,000 test cases, and
the sixth featured more than 22,000 functions. Except for data from Juliet,
the data is scraped from open-source projects. Test cases in Juliet are
vulnerable by design and have their associated patch with them. Furthermore,
we obfuscate the function and variable names as they were explicit and would
affect the model’s training. As for other datasets, limited pre-processing was
done on them, such as function extraction, dealing with line breaks, removing
comments, CWE mapping, and unifying their features. While several datasets
have CWE mapping, some are missing CWE and have a CVE instead. In the case of
ReVeal, it has no CWEs and is just labeled as vulnerable or not. At the same
time, the Draper dataset is the only multi-labeled dataset.

TABLE III: Data Distribution of FalconVulnDB.

Class | Samples | Before pre-processing | After pre-processing
---|---|---|---
Training | Testing | Training | Testing
0 | 1,611,613 | 1,289,217 | 322,396 | 497,116 | 124,679
1 | 139,616 | 111,766 | 27,850 | 116,404 | 28,702

0: NOT VULNERABLE, 1: VULNERABLE

The amalgamation of the dataset resulted in the outcome presented in Table
III. The dataset initially contained 1.7 million samples. However, there is an
overlap between the different datasets, which we remove after the pre-
processing. We employ more than 750,000 samples to train the model, with $20$%
being a test set. The following CWEs
888https://cwe.mitre.org/top25/archive/2023/2023_kev_list.html are included in
FalconVulnDB.

• CWE-20: Improper Input Validation \- Occurs when software does not validate
or improperly validates input, affecting a program’s control or data flow.
This can lead to unauthorized access, denial of service, or privilege
escalation. • CWE-78: OS Command Injection \- An application allows the
execution of arbitrary OS commands due to inadequate input validation, which
can result in a complete system takeover. • CWE-119: Improper Restriction of
Operations within the Bounds of a Memory Buffer \- A buffer overflow occurs
when a program operates on more data than the size of its memory buffer. It
can allow arbitrary code execution, control flow alteration, or system crash.
• CWE-120: Buffer Copy without Checking Size of Input (’Classic Buffer
Overflow’) \- A specific instance of buffer overflow caused by buffer copy
operations without adequate size checks of the input. • CWE-121: Stack-based
Buffer Overflow \- Occurs in stack memory, potentially leading to arbitrary
code execution or manipulation of program execution flow by overwriting
critical data. • CWE-122: Heap-based Buffer Overflow Similar to stack-based
but occurs in heap memory, leading to data corruption or unexpected behavior
through manipulated pointers. • CWE-190: Integer Overflow or Wraparound \-
Happens when an integer operation produces a value too large to be held by the
integer type, causing the value to wrap and create unintended values, leading
to errors or vulnerabilities. • CWE-476: NULL Pointer Dereference \- It occurs
when a program dereferences a pointer, which it expects to be valid but is
NULL, leading to crashes or code execution. • CWE-762: Mismatched Memory
Management Routines \- Arises when memory is allocated and deallocated with
different routines, potentially leading to heap corruption or crashes. •
CWE-787: Out-of-bounds Write \- It happens when software writes data outside
the intended buffer boundaries, leading to data corruption, crashes, or code
execution vulnerabilities.

The most common vulnerability categories in FalconVulnDB are displayed in
Figure 4.

otherother1191204761221901217878720762762$0$$1$$2$$3$$4$$5$$6$$7$$\cdot
10^{4}$$66{,}761$$25{,}011$$22{,}213$$11{,}499$$3{,}509$$3{,}307$$3{,}041$$2{,}872$$2{,}621$$2{,}200$$2{,}072$Common
Weakness EnumerationFrequencyCWE-119: Improper Restriction CWE-120: Buffer
CopyCWE-476: NULL Pointer Dereference CWE-122: Heap-based Buffer
OverflowCWE-190 : Integer Overflow or WraparoundCWE-121 : Stack-based Buffer
Overflow CWE-78 : OS Command InjectionCWE-787 : Out-of-bounds Write CWE-20 :
Improper Input Validation CWE-762 : Mismatched Memory Management Figure 4: Top
11 most frequent vulnerability categories in FalconVulnDB.

##  VI Performance Evaluation

Figure 5: Performance evaluation steps of SecureFalcon model.

Performance evaluation of SecureFalcon model for software vulnerability
detection involves a series of steps, as presented in Fig. 5. First, we
collect a large and diverse dataset of software code from the FormAI and the
aggregated datasets (FalconVulnDB), where instances of vulnerable and non-
vulnerable code are correctly labeled. Once we have the datasets, we pre-
process them by transforming the raw source code into a format suitable for
the SecureFalcon model, tokenizing the code into appropriate separate sub-
strings. Next, we initiate the SecureFalcon model with the desired
architecture using the Transformers library. Then, we define the training and
evaluation settings, which involve setting various hyperparameters like
learning rate, batch size, and number of epochs. We start the fine-tuning
process, where the model will learn from the labeled dataset to differentiate
between vulnerable and non-vulnerable code. We evaluate the model regularly
during training to track its progress and adjust hyperparameters when
necessary. After training the model, we test it on separate data amalgamated
from the different datasets to verify its effectiveness. Lastly, after fine-
tuning, the resulting model should be able to predict whether a given piece of
code is vulnerable or not.

###  VI-A Experimental Setup

TABLE IV outlines the experimental setup and parameters used for fine-tuning
SecureFalcon for software security.

TABLE IV: Configuration of SecureFalcon. Parameter | Value
---|---
Pretrained model ID | FalconLLM 40B
Number of parameters | 121M
Hidden size | 768
Number of hidden layers | 12
Number of attention heads | 12
Intermediate-size | 3072
Maximum position embeddings | 514
Number of labels | 2/12
Tokenizer padding side | Left
Padding token ID | 11
BOS token ID | 11
EOS token ID | 11
Maximum length of tokens | 2048
Tokenizer truncation | True
Tokenizer padding | True
Return tensor format | PyTorch tensors (’pt’)
Return token type IDs | False
Return attention mask | True
Batch size | 256
GPU | 32 A100 40GB
Optimizer | AdamW
AdamW Learning Rate (LR) | 2e-2 and 2e-5
AdamW Epsilon | 1e-8
Number of training epochs | 10
Early stopping | Enabled (patience=3)
Random seed value | 42
Maximum gradient norm | 1.0
Loss computation | Cross-entropy loss
Hidden activation function | "gelu"
Initializer range | 0.02
Layer norm epsilon | 1e-5
Attention probs dropout prob | 0.1
Hidden dropout prob | 0.1
Torch_dtype | float32
Transformers_version | 4.30.2
SMDDP_version | 2.1.0
Pytorch_version | 2.1.0
Python_version | 3.10

The SecureFalcon model features 121 million parameters, a hidden size of 768,
twelve hidden layers, and twelve attention heads. This model employs an
intermediate size of 3072 and supports up to 514 position embeddings.
Tokenization was performed using a left-padding approach, with a padding token
ID, BOS (beginning of sentence) token ID, and EOS (end of sentence) token ID
all set to 11. The tokenizer settings enforced truncation and padding,
producing PyTorch tensor outputs and including an attention mask, while token
type IDs were not returned. We set the maximum token length to 2048. For
training, batch sizes were set to 256, utilizing 32 Nvidia A100 40GB GPUs to
ensure efficient processing. We employed the AdamW optimizer with learning
rates set at 2e-2 and 2e-5 and an epsilon value of 1e-8. The training was
carried out over ten epochs to prevent overfitting, with early stopping
enabled after three epochs without improvement. For loss computation, we
utilized cross-entropy loss. The model was evaluated based on accuracy,
precision, recall, and the F1 score, with metrics averaged using the ’micro’
method to reflect the contribution of each instance to the overall metric. The
additional configuration included setting the hidden activation function to
GELU, an initializer range of 0.02, and a layer norm epsilon of 1e-5. The
dropout probabilities for attention and hidden layers were set to $0.1$. The
models were run under a float32 torch data type setting, ensuring
compatibility and optimal performance on the specified transformer library
version 4.30.2.

###  VI-B Experimental Results

Tables V and VI present the classification report of SecureFalcon-121M with LR
= 2e-5 and LR = 2e-2. With an LR of 2e-5, the model yields the highest
accuracy of $0.94$, supported by a high precision, recall, and F1-score for
both classes (0.89, 0.84, 0.86 for ‘NOT VULNERABLE’ and 0.95, 0.97, 0.96 for
‘VULNERABLE’) (see Tables V)

TABLE V: Classification report of SecureFalcon 121M with LR = 2e-5 using
FormAI dataset.

| Precision | Recall | F1-Score | Support
---|---|---|---|---
0 | 0.89 | 0.84 | 0.86 | 4528
1 | 0.95 | 0.97 | 0.96 | 15533
Accuracy | 0.94
Macro avg | 0.92 | 0.90 | 0.91 | 20061
Weighted avg | 0.94 | 0.94 | 0.94 | 20061

0: NOT VULNERABLE, 1: VULNERABLE

TABLE VI: Classification report of SecureFalcon 121M with LR = 2e-2 using
FormAI dataset.

| Precision | Recall | F1-Score | Support
---|---|---|---|---
0 | 0.67 | 0.80 | 0.73 | 4528
1 | 0.94 | 0.88 | 0.91 | 15533
Accuracy | 0.87
Macro avg | 0.80 | 0.84 | 0.82 | 20061
Weighted avg | 0.88 | 0.87 | 0.87 | 20061

0: NOT VULNERABLE, 1: VULNERABLE

This performance considerably drops when the learning rate is increased to
2e-2. Although the precision for ‘VULNERABLE’ remains high ($0.94$), the ‘NOT
VULNERABLE’ metrics take a substantial hit, decreasing overall accuracy to
$0.87$.

Tables VII, VIII, IX present the training and validation accuracy and loss
over several epochs for SecureFalcon model with differing configurations. With
a Learning Rate (LR) of 2e-5 (Table VII), accuracy consistently increases, and
loss decreases over the epochs for both training and validation. However, with
an LR of 2e-2 (Table VIII), lower accuracy and higher loss indicate that a
larger learning rate could lead to sub-optimal learning.

TABLE VII: Training and Validation Accuracy and Loss Across Epochs of SecureFalcon 121M with LR = 2e-5 using FormAI dataset. | Training | Validation
---|---|---
Epoch | Accuracy | Loss | Accuracy | Loss
1 | 0.82 | 0.39 | 0.88 | 0.27
2 | 0.87 | 0.29 | 0.89 | 0.25
3 | 0.89 | 0.25 | 0.90 | 0.23
4 | 0.91 | 0.21 | 0.91 | 0.21
5 | 0.93 | 0.17 | 0.93 | 0.19
6 | 0.95 | 0.12 | 0.93 | 0.19
7 | 0.97 | 0.09 | 0.94 | 0.19
TABLE VIII: Training and Validation Accuracy and Loss Across Epochs of SecureFalcon 121M with LR= 2e-2 using FormAI dataset. | Training | Validation
---|---|---
Epoch | Accuracy | Loss | Accuracy | Loss
1 | 0.70 | 0.61 | 0.82 | 0.43
2 | 0.78 | 0.48 | 0.80 | 0.42
3 | 0.80 | 0.44 | 0.85 | 0.34
4 | 0.83 | 0.38 | 0.81 | 0.41
5 | 0.82 | 0.40 | 0.86 | 0.31
6 | 0.84 | 0.36 | 0.86 | 0.30
7 | 0.85 | 0.34 | 0.86 | 0.30
8 | 0.85 | 0.34 | 0.87 | 0.30
TABLE IX: Training and Validation Accuracy and Loss Across Epochs of SecureFalcon 121M with LR = 2e-5 using FalconVulnDB dataset | Training | Validation
---|---|---
Epoch | Accuracy | Loss | Accuracy | Loss
1 | 0.91 | 0.30 | 0.91 | 0.31
2 | 0.92 | 0.26 | 0.91 | 0.32

Figure 6 illustrates the confusion matrix for the binary classification
performed by SecureFalcon. From the provided confusion matrices, we can make
some observations regarding the performance of the SecureFalcon models with
different configurations. A decrease in performance is observed when the
learning rate is raised to 2e-2. The number of false negatives drastically
increased from $483$ to $1805$, with false positives rising from $740$ to
$895$. Correspondingly, the true positives and negatives decreased from
$15050$ to $13728$ and from $3788$ to $3633$, respectively. This shows that a
larger learning rate, in this case, led to more misclassifications, indicating
an over-optimistic learning process that possibly led to overfitting or
instability during training. This is due to the high learning rate
contributing to more drastic changes in weight, leading to instability or
overfitting.

(a) SecureFalcon with LR = 2e-5

(b) SecureFalcon with LR = 2e-2

0: NOT VULNERABLE, 1: VULNERABLE

Figure 6: Confusion matrix of SecureFalcon 121M/44M classification using
FormAI dataset.

The multi-classification report of the SecureFalcon model, as presented in
Table X, exhibits a comprehensive evaluation of the model’s performance across
various Common Weakness Enumerations (CWEs) on FalconVulnDB. We conducted
several experiments to determine the model’s rationale for the classification.
One of the interpretability tools999https://github.com/cdpierse/transformers-
interpret (accessed 9 May 2024) used was a library highlighting the
distribution of attention, indicating some discrepancies in our model results.
To enhance the knowledge of the model of the syntactic and lexical nature of
the programming language, we embed the tokens shown in Table XI. The tokens
are keywords, punctuation, and API calls defined in the C/C++ manual and its
extended libraries101010https://www.gnu.org/software/libc/manual/pdf/libc.pdf
(accessed 15 May 2024)111111https://learn.microsoft.com/en-us/cpp/cpp/cpp-
language-reference (accessed 15 May 2024),

an approach similar to work [10]. Testing with the new tokens included in the
fine-tuning, in turn, updating the embedding layer has yielded higher
precision and recall. This is due to maintaining the syntax of the pre-defined
tokens rather than going through the subword tokenization process. As such,
the meaning of these essential pre-defined tokens in the source code is
preserved.

TABLE X: Classification report of SecureFalcon 121M with LR = 2e-5 using FalconVulnDB dataset. | Precision | Recall | F1-Score | Support
---|---|---|---|---
Not-Vulnerable | 0.93 | 0.97 | 0.95 | 124355
CWE-20 | 0.46 | 0.14 | 0.22 | 440
CWE-78 | 1.00 | 0.98 | 0.99 | 574
CWE-119 | 0.75 | 0.75 | 0.75 | 5002
CWE-120 | 0.63 | 0.84 | 0.72 | 4443
CWE-121 | 0.99 | 0.99 | 0.99 | 608
CWE-122 | 1.00 | 0.99 | 0.99 | 702
CWE-190 | 0.97 | 0.78 | 0.87 | 662
CWE-476 | 0.64 | 0.45 | 0.53 | 2300
CWE-762 | 1.00 | 1.00 | 1.00 | 414
CWE-787 | 0.27 | 0.26 | 0.26 | 524
Other | 0.89 | 0.54 | 0.67 | 13352
Accuracy | 0.92
Macro Avg | 0.79 | 0.72 | 0.74 | 153376
Weighted Avg | 0.91 | 0.91 | 0.90 | 153376

The model demonstrates high precision and recall for most categories,
particularly excelling in identifying non-vulnerable instances with a
precision of $0.93$, recall of $0.97$, and an F1-score of $0.95$, indicating
robustness in distinguishing non-vulnerable cases. Remarkably, it achieves
perfect or near-perfect performance in identifying CWE-78, CWE-121, CWE-122,
and CWE-762 vulnerabilities, showcasing its effectiveness in detecting
specific types of vulnerabilities with high accuracy. However, the model shows
limitations in recognizing certain vulnerabilities, notably CWE-20 and
CWE-787, with notably lower precision and recall values, suggesting areas for
improvement in future iterations. The low F1-score for CWE-20 ($0.22$) and
CWE-787 ($0.26$) highlights the model’s challenge in accurately classifying
these vulnerabilities, possibly due to the complexity of the patterns
associated with these CWEs or a limited representation in the training data.

The aggregated accuracy of $0.92$ and the weighted average precision, recall,
and F1 score reflect the model’s high competence in vulnerability
classification across diverse vulnerabilities. However, the varying
performance across different CWEs underscores the importance of continued
model refinement and targeted training to enhance the model’s sensitivity and
specificity, particularly for those vulnerabilities where it currently
underperforms. The confusion matrix for multiclass classification on the
FalconVulnDB Dataset is shown in Figure 7.

Figure 7: Confusion Matrix of SecureFalcon 121M Multi-classification using FalconVulnDB Dataset. TABLE XI: List of special tokens added in the Falcon40b tokenizer Tokens | Count |  Examples |
---|---|---|---
Punctuation | 72 |  !=, ++, = |
Keywords | 123 |  char, const, continue |
API calls | 394 |  malloc, strncpy, atoi |

###  VI-C Comparison of SecureFalcon

Table XII compares various machine learning (ML) models and their accuracy in
performing multiclass and binary classification tasks on the FormAI and
FalconVulnDB datasets. Large Language Models (LLMs) such as RoBERTa, BERT,
CodeBERT, and SecureFalcon show a notable performance difference compared to
traditional ML models for multiclass classification. SecureFalcon, in
particular, stands out with the highest accuracy of 0.92 on both datasets,
significantly outperforming other LLM models like RoBERTa and BERT, which
achieve accuracies of around 0.70-0.85. Among the traditional ML models,
Random Forest (RF) performs the best with accuracies of 0.77 on the FormAI
dataset and 0.81 on the FalconVulnDB dataset, although it still lags behind
the LLM models.

The trend remains similar in binary classification, with SecureFalcon leading
with an accuracy of 0.94 on the FormAI dataset and 0.92 on the FalconVulnDB
dataset. Other LLM models, such as RoBERTa, BERT, and CodeBERT, also perform
well, achieving accuracies between 0.81 and 0.89 across both datasets.
Traditional ML models show competitive results in this task, with Random
Forest achieving an accuracy of 0.91 on the FormAI dataset and 0.89 on the
FalconVulnDB dataset, which is relatively close to the performance of some
LLMs. However, the consistently superior performance of SecureFalcon
highlights the advantages of fine-tuning large models specifically for
software vulnerability detection tasks, making it a robust choice for both
multiclass and binary classification in cybersecurity contexts.

TABLE XII: Comparison of SecureFalcon with LLM models and traditional machine
learning using the FormAI dataset and FalconVulnDB dataset.

Task | ML type | Model | Accuracy
---|---|---|---
FormAI dataset | FalconVulnDB dataset
Multiclass Classification | LLM models | RoBERTa | 0.70 | 0.85
BERT | 0.70 | 0.85
CodeBERT | 0.71 | 0.88
SecureFalcon | 0.92 | 0.92
Traditional ML models | KNN | 0.76 | 0.80
LR | 0.73 | 0.77
NB | 0.64 | 0.68
SVM | 0.73 | 0.77
RF | 0.77 | 0.81
DT | 0.72 | 0.60
LDA | 0.73 | 0.77
Binary Classification | LLM models | RoBERTa | 0.82 | 0.86
BERT | 0.81 | 0.87
CodeBERT | 0.83 | 0.89
SecureFalcon | 0.94 | 0.92
Traditional ML models | KNN | 0.76 | 0.86
LR | 0.86 | 0.86
NB | 0.76 | 0.81
SVM | 0.86 | 0.89
RF | 0.91 | 0.89
DT | 0.87 | 0.86
LDA | 0.86 | 0.85

ML: Machine learning, KNN: k-Nearest Neighbors, LR: Logistic Regression, NB:
Naive Bayes, SVM: Support Vector Machine, RF: Random Forest, DT: Decision
Tree, and LDA: Linear Discriminant Analysis.

###  VI-D Future Works

As future work, SecureFalcon, a fine-tuned Large Language Model (LLM) for
software vulnerability detection, aims to enhance its capabilities by
providing comprehensive explanations to developers. These enhancements include
generating detailed reports describing detected vulnerabilities, highlighting
the affected code snippets, and analyzing the potential impact. Furthermore,
SecureFalcon will outline steps to reproduce the issues, including environment
setup, input data, and execution steps, and offer remediation guidance with
fix recommendations and secure coding practices. By integrating these features
with development tools, SecureFalcon will ensure real-time feedback and
automated code reviews, significantly aiding developers in understanding,
reproducing, and resolving security issues effectively.

##  VII Conclusion

Our study highlights the significant potential of LLMs in detecting software
vulnerabilities, especially in cybersecurity. By fine-tuning FalconLLM, we
developed SecureFalcon, a novel model capable of distinguishing between
vulnerable and non-vulnerable C/C++ code samples. Tested on different datasets
from the literature, our model achieved a remarkable $94$% accuracy rate in
binary classification and $92$% in multiclassification, highlighting its
efficacy. Furthermore, we accomplish these results by utilizing a relatively
small set of parameters, totaling $121$ million, within the SecureFalcon
model. We believe further advancements will enhance such models’ capabilities,
expand with distinct vulnerability types, and extend to other programming
languages to strengthen software system security and foster a more secure
digital realm. A promising extension of this work would include an automated
self-healing system that identifies and remedies the vulnerabilities. Such a
system could make software more resilient against potential threats, thus
enhancing overall cybersecurity. A fast inference time model like SecureFalcon
has the potential to be highly effective in automated software completion
frameworks. We plan to continue our research in this direction.

## References

  * [1] D. J. Solove, _The digital person: Technology and privacy in the information age_. NyU Press, 2004, vol. 1.
  * [2] M. A. Hlatshwayo, “Cybersecurity in the digital space.”
  * [3] M. Abdel-Rahman _et al._ , “Advanced cybersecurity measures in it service operations and their crucial role in safeguarding enterprise data in a connected world,” _Eigenpub Review of Science and Technology_ , vol. 7, no. 1, pp. 138–158, 2023.
  * [4] Z. Li, Z. Liu, W. K. Wong, P. Ma, and S. Wang, “Evaluating c/c++ vulnerability detectability of query-based static application security testing tools,” _IEEE Transactions on Dependable and Secure Computing_ , 2024.
  * [5] Y. Sun, D. Wu, Y. Xue, H. Liu, W. Ma, L. Zhang, M. Shi, and Y. Liu, “Llm4vuln: A unified evaluation framework for decoupling and enhancing llms’ vulnerability reasoning,” _arXiv preprint arXiv:2401.16185_ , 2024.
  * [6] R. Jain, N. Gervasoni, M. Ndhlovu, and S. Rawat, “A code centric evaluation of c/c++ vulnerability datasets for deep learning based vulnerability detection techniques,” in _Proceedings of the 16th Innovations in Software Engineering Conference_ , 2023, pp. 1–10.
  * [7] Z. Li, D. Zou, S. Xu, X. Ou, H. Jin, S. Wang, Z. Deng, and Y. Zhong, “Vuldeepecker: A deep learning-based system for vulnerability detection,” _CoRR_ , vol. abs/1801.01681, 2018. [Online]. Available: http://arxiv.org/abs/1801.01681
  * [8] N. Ziems and S. Wu, “Security vulnerability detection using deep learning natural language processing,” in _IEEE INFOCOM 2021 - IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS)_ , 2021, pp. 1–6.
  * [9] X. Duan, J. Wu, S. Ji, Z. Rui, T. Luo, M. Yang, and Y. Wu, “Vulsniper: Focus your attention to shoot fine-grained vulnerabilities.”
  * [10] H. Hanif and S. Maffeis, “Vulberta: Simplified source code pre-training for vulnerability detection,” in _2022 International joint conference on neural networks (IJCNN)_. IEEE, 2022, pp. 1–8.
  * [11] S. Chakraborty, R. Krishna, Y. Ding, and B. Ray, “Deep learning based vulnerability detection: Are we there yet,” _IEEE Transactions on Software Engineering_ , 2021.
  * [12] P. E. Black, “A Software Assurance Reference Dataset: Thousands of Programs With Known Bugs,” _Journal of Research of the National Institute of Standards and Technology_ , vol. 123, pp. 1–3, Apr. 2018. [Online]. Available: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7339570/
  * [13] F. E. B. Jr and P. E. Black, “The Juliet 1.1 C/C++ and Java Test Suite,” _NIST_ , vol. 45, no. 10, pp. 88–90, Oct. 2012, last Modified: 2021-10-12T11:10-04:00 Publisher: Frederick E. Boland Jr., Paul E. Black. [Online]. Available: https://www.nist.gov/publications/juliet-11-cc-and-java-test-suite
  * [14] Y. Zhou, S. Liu, J. Siow, X. Du, and Y. Liu, _Devign: Effective Vulnerability Identification by Learning Comprehensive Program Semantics via Graph Neural Networks_. Red Hook, NY, USA: Curran Associates Inc., 2019, pp. 10 197–10 207.
  * [15] J. Fan, Y. Li, S. Wang, and T. N. Nguyen, “A C/C++ Code Vulnerability Dataset with Code Changes and CVE Summaries,” in _Proceedings of the 17th International Conference on Mining Software Repositories_ , ser. MSR ’20. New York, NY, USA: Association for Computing Machinery, Sep. 2020, pp. 508–512. [Online]. Available: https://doi.org/10.1145/3379597.3387501
  * [16] L. Kim and R. Russell, “Draper VDISC Dataset - Vulnerability Detection in Source Code,” 2018, publisher: OSF. [Online]. Available: https://osf.io/d45bw/
  * [17] Y. Chen, Z. Ding, X. Chen, and D. Wagner, “DiverseVul: A New Vulnerable Source Code Dataset for Deep Learning Based Vulnerability Detection,” Apr. 2023. [Online]. Available: http://arxiv.org/abs/2304.00409
  * [18] A. Habib and M. Pradel, “How many of all bugs do we find? a study of static bug detectors,” in _Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering_ , 2018, pp. 317–328.
  * [19] J. Park, I. Lim, and S. Ryu, “Battles with false positives in static analysis of javascript web applications in the wild,” in _Proceedings of the 38th International Conference on Software Engineering Companion_ , 2016, pp. 61–70.
  * [20] V. Hartonas-Garmhausen, S. V. A. Campos, A. Cimatti, E. M. Clarke, and F. Giunchiglia, “Verification of a safety-critical railway interlocking system with real-time constraints,” _Sci. Comput. Program._ , vol. 36, no. 1, pp. 53–64, 2000. [Online]. Available: https://doi.org/10.1016/S0167-6423(99)00016-7
  * [21] C. Heitmeyer, J. Kirby, B. Labaw, M. Archer, and R. Bharadwaj, “Using abstraction and model checking to detect safety violations in requirements specifications,” _IEEE Transactions on software engineering_ , vol. 24, no. 11, pp. 927–948, 1998.
  * [22] J. Lahtinen, J. Valkonen, K. Björkman, J. Frits, I. Niemelä, and K. Heljanko, “Model checking of safety-critical software in the nuclear engineering domain,” _Reliability Engineering & System Safety_, vol. 105, pp. 104–113, 2012.
  * [23] A. Biere, A. Cimatti, E. M. Clarke, O. Strichman, and Y. Zhu, “Bounded model checking.” _Handbook of satisfiability_ , vol. 185, no. 99, pp. 457–481, 2009.
  * [24] R. S. Menezes, M. Aldughaim, B. Farias, X. Li, E. Manino, F. Shmarov, K. Song, F. Brauße, M. R. Gadelha, N. Tihanyi, K. Korovin, and L. C. Cordeiro, “ESBMC v7.4: Harnessing the power of intervals - (competition contribution),” in _Tools and Algorithms for the Construction and Analysis of Systems (TACAS)_ , ser. LNCS, vol. 14572. Springer, 2024, pp. 376–380.
  * [25] N. Nehorai, “Analyzing common vulnerabilities introduced by code-generative ai | hackernoon,” 2024. [Online]. Available: https://hackernoon.com/analyzing-common-vulnerabilities-introduced-by-code-generative-ai
  * [26] E. M. Clarke, T. A. Henzinger, H. Veith, and R. Bloem, Eds., _Handbook of Model Checking_. Springer, 2018.
  * [27] A. M. Turing, “On computable numbers, with an application to the entscheidungsproblem,” _Proceedings of the London Mathematical Society_ , vol. s2-42, no. 1, pp. 230–265, 1936.
  * [28] M. Sipser, _Introduction to the Theory of Computation_. Cengage Learning, 2012.
  * [29] N. Tihanyi, T. Bisztray, R. Jain, M. A. Ferrag, L. C. Cordeiro, and V. Mavroeidis, “The formai dataset: Generative ai in software security through the lens of formal verification,” in _Proceedings of the 19th International Conference on Predictive Models and Data Analytics in Software Engineering_ , 2023, pp. 33–43.
  * [30] H. Hanif, M. H. N. M. Nasir, M. F. Ab Razak, A. Firdaus, and N. B. Anuar, “The rise of software vulnerability: Taxonomy of software vulnerabilities detection and machine learning approaches,” _Journal of Network and Computer Applications_ , vol. 179, p. 103009, 2021.
  * [31] A. V. Aho, M. S. Lam, R. Sethi, and J. D. Ullman, _Compilers: Principles, Techniques, And Tools_ , 2nd ed. Addison-Wesley Longman Publishing Co., Inc., 2006.
  * [32] H. Barbosa, C. W. Barrett, M. Brain, G. Kremer, H. Lachnitt, M. Mann, A. Mohamed, M. Mohamed, A. Niemetz, A. Nötzli, A. Ozdemir, M. Preiner, A. Reynolds, Y. Sheng, C. Tinelli, and Y. Zohar, “cvc5: A versatile and industrial-strength SMT solver,” in _Tools and Algorithms for the Construction and Analysis of Systems - 28th International Conference, TACAS 2022, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2022, Munich, Germany, April 2-7, 2022, Proceedings, Part I_ , ser. Lecture Notes in Computer Science, D. Fisman and G. Rosu, Eds., vol. 13243. Springer, 2022, pp. 415–442. [Online]. Available: https://doi.org/10.1007/978-3-030-99524-9_24
  * [33] A. Niemetz and M. Preiner, “Bitwuzla,” in _Computer Aided Verification - 35th International Conference, CAV 2023, Paris, France, July 17-22, 2023, Proceedings, Part II_ , ser. Lecture Notes in Computer Science, C. Enea and A. Lal, Eds., vol. 13965. Springer, 2023, pp. 3–17. [Online]. Available: https://doi.org/10.1007/978-3-031-37703-7_1
  * [34] L. de Moura and N. Bjørner, “Z3: An efficient smt solver,” in _Tools and Algorithms for the Construction and Analysis of Systems_ , C. R. Ramakrishnan and J. Rehof, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2008, pp. 337–340.
  * [35] T. Ahmed and P. Devanbu, “Few-shot training llms for project-specific code-summarization,” in _Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering_ , 2022, pp. 1–5.
  * [36] A. Tarassow, “The potential of llms for coding with low-resource and domain-specific programming languages,” _arXiv preprint arXiv:2307.13018_ , 2023.
  * [37] X. Cheng, G. Zhang, H. Wang, and Y. Sui, “Path-sensitive code embedding via contrastive learning for software vulnerability detection,” in _Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis_ , 2022, pp. 519–531.
  * [38] Z. Chen, S. Kommrusch, and M. Monperrus, “Neural transfer learning for repairing security vulnerabilities in c code,” _IEEE Transactions on Software Engineering_ , vol. 49, no. 1, pp. 147–165, 2022.
  * [39] J. Yin, M. Tang, J. Cao, and H. Wang, “Apply transfer learning to cybersecurity: Predicting exploitability of vulnerabilities by description,” _Knowledge-Based Systems_ , vol. 210, p. 106529, 2020.
  * [40] P. Mahbub, O. Shuvo, and M. M. Rahman, “Explaining software bugs leveraging code structures in neural machine translation,” in _2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE)_. IEEE, 2023, pp. 640–652.
  * [41] N. Ito, M. Hashimoto, and A. Otsuka, “Feature extraction methods for binary code similarity detection using neural machine translation models,” _IEEE Access_ , 2023.
  * [42] Z. Li, D. Zou, S. Xu, H. Jin, Y. Zhu, and Z. Chen, “Sysevr: A framework for using deep learning to detect software vulnerabilities,” _IEEE Transactions on Dependable and Secure Computing_ , vol. 19, no. 4, pp. 2244–2258, 2021.
  * [43] Y. Zhou, S. Liu, J. Siow, X. Du, and Y. Liu, _Devign: Effective Vulnerability Identification by Learning Comprehensive Program Semantics via Graph Neural Networks_. Red Hook, NY, USA: Curran Associates Inc., 2019.
  * [44] Z. Feng, D. Guo, D. Tang, N. Duan, X. Feng, M. Gong, L. Shou, B. Qin, T. Liu, D. Jiang _et al._ , “Codebert: A pre-trained model for programming and natural languages,” _arXiv preprint arXiv:2002.08155_ , 2020.
  * [45] Y. Liu, M. Ott, N. Goyal, J. Du, M. Joshi, D. Chen, O. Levy, M. Lewis, L. Zettlemoyer, and V. Stoyanov, “Roberta: A robustly optimized bert pretraining approach,” _arXiv preprint arXiv:1907.11692_ , 2019.
  * [46] T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell _et al._ , “Language models are few-shot learners,” _Advances in neural information processing systems_ , vol. 33, pp. 1877–1901, 2020.
  * [47] J. Zhou, M. Pacheco, Z. Wan, X. Xia, D. Lo, Y. Wang, and A. E. Hassan, “Finding a needle in a haystack: Automated mining of silent vulnerability fixes,” in _2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE)_. IEEE, 2021, pp. 705–716.
  * [48] K. Singh, S. S. Grover, and R. K. Kumar, “Cyber security vulnerability detection using natural language processing,” in _2022 IEEE World AI IoT Congress (AIIoT)_. IEEE, 2022, pp. 174–178.
  * [49] J. Devlin, M.-W. Chang, K. Lee, and K. Toutanova, “Bert: Pre-training of deep bidirectional transformers for language understanding,” _arXiv preprint arXiv:1810.04805_ , 2018.
  * [50] S. Kim, S. Woo, H. Lee, and H. Oh, “Vuddy: A scalable approach for vulnerable code clone discovery,” in _2017 IEEE Symposium on Security and Privacy (SP)_ , 2017, pp. 595–614.
  * [51] Z. Li, D. Zou, S. Xu, H. Jin, H. Qi, and J. Hu, “Vulpecker: An automated vulnerability detection system based on code similarity analysis,” in _Proceedings of the 32nd Annual Conference on Computer Security Applications_ , ser. ACSAC ’16. New York, NY, USA: Association for Computing Machinery, 2016, p. 201–213. [Online]. Available: https://doi.org/10.1145/2991079.2991102
  * [52] P. Zeng, G. Lin, L. Pan, Y. Tai, and J. Zhang, “Software vulnerability analysis and discovery using deep learning techniques: A survey,” _IEEE Access_ , vol. 8, pp. 197 158–197 172, 2020.
  * [53] J. Kaplan, S. McCandlish, T. Henighan, T. B. Brown, B. Chess, R. Child, S. Gray, A. Radford, J. Wu, and D. Amodei, “Scaling laws for neural language models,” _arXiv preprint arXiv:2001.08361_ , 2020.
  * [54] E. Almazrouei, H. Alobeidli, A. Alshamsi, A. Cappelli, R. Cojocaru, M. Debbah, E. Goffinet, D. Heslow, J. Launay, Q. Malartic, B. Noune, B. Pannier, and G. Penedo, “Falcon-40B: an open large language model with state-of-the-art performance,” 2023.
  * [55] I. Loshchilov and F. Hutter, “Decoupled weight decay regularization,” _arXiv preprint arXiv:1711.05101_ , 2017.
  * [56] T. Mikolov, I. Sutskever, K. Chen, G. S. Corrado, and J. Dean, “Distributed representations of words and phrases and their compositionality,” _Advances in neural information processing systems_ , vol. 26, 2013.
  * [57] A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, Ł. Kaiser, and I. Polosukhin, “Attention is all you need,” _Advances in neural information processing systems_ , vol. 30, 2017.
  * [58] J. L. Ba, J. R. Kiros, and G. E. Hinton, “Layer normalization,” _arXiv preprint arXiv:1607.06450_ , 2016.
  * [59] J. Su, Y. Lu, S. Pan, A. Murtadha, B. Wen, and Y. Liu, “Roformer: Enhanced transformer with rotary position embedding,” _arXiv preprint arXiv:2104.09864_ , 2021.
  * [60] D. E. Rumelhart, G. E. Hinton, and R. J. Williams, “Learning representations by back-propagating errors,” _nature_ , vol. 323, no. 6088, pp. 533–536, 1986.
  * [61] D. Hendrycks and K. Gimpel, “Gaussian error linear units (gelus),” _arXiv preprint arXiv:1606.08415_ , 2016.
  * [62] C. M. Bishop and N. M. Nasrabadi, _Pattern recognition and machine learning_. Springer, 2006, vol. 4, no. 4.