V ul L ib G en: Generating Names of Vulnerability-Affected Packages via a Large Language Model (2024)

Abstract: Security practitioners maintain vulnerability reports (e.g., GitHub Advisory) to help developers mitigate security risks. An important task for these databases is automatically extracting structured information mentioned in the report, e.g., the affected software packages, to accelerate the defense of the vulnerability ecosystem.However, it is challenging for existing work on affected package identification to achieve high precision. One reason is that all existing work focuses on relatively smaller models, thus they cannot harness the knowledge and semantic capabilities of large language models.To address this limitation, we propose VulLibGen, the first method to use LLM for affected package identification. In contrast to existing work, VulLibGen proposes the novel idea to directly generate the affected package. To improve the precision, VulLibGen employs supervised fine-tuning (SFT), retrieval augmented generation (RAG) and a local search algorithm. The local search algorithm is a novel post-processing algorithm we introduce for reducing the hallucination of the generated packages. Our evaluation results show that VulLibGen has an average precision of 0.806 for identifying vulnerable packages in the four most popular ecosystems in GitHub Advisory (Java, JS, Python, Go) while the best average precision in previous work is 0.721. Additionally, VulLibGen has high value to security practice: we submitted 60 <vulnerability, affected package> pairs to GitHub Advisory (covers four ecosystems) and 34 of them have been accepted and merged.

## introduction with the increasing usage of third-party software packages, their security vulnerabilities pose great figure 1 : github advisory report for cve-2020-2318 challenges to software and network systems. a recent study @xcite shows that 84% third-party packages contain security vulnerabilities and 60% of them are high-risk ones. to mitigate the security risks, security practitioners maintain databases (e.g., nvd and github advisory) for each unique vulnerability (i.e., common weakness enumeration or cve). these databases provides metadata including the vulnerability description, affected packages, and affected versions. for example, figure 1 shows the report of cve-2020-2318. by providing the affected package names and versions, developers can be aware of the vulnerable packages and quickly apply patches/fixes; the affected packages also help with security knowledge management and task prioritization. in recent years, automatically identifying package names and versions given the cve report has become a popular task @xcite @xcite @xcite due to the high cost of maintaining such information. github advisory and other databases rely on the community to first submit the package names, the database maintainers then validate the submitted information before merging them to the database @xcite . nevertheless, github users sometimes submit incorrect information @xcite , while the maintainers' reviewing process takes a long time @xcite . several existing works have studied automatic affected package identification @xcite @xcite @xcite , however, it is challenging for them to achieve high precision due to the limited model size they employ. existing works typically rank/retrieve the package name from a list of pre-defined packages by computing the similarity between the vulnerability description and the package description. since the time complexity of retrieval is linear to the size of the list (e.g., 435k java packages), the cost of each model inference has to be kept quite low and only smaller models have been used, e.g., bert and linear regression @xcite @xcite . to leverage the extensive knowledge and semantic capabilities of llms for this task, we propose a different strategy: we directly generate the affected package names using llms, rather than retrieving them. our framework, vullibgen, is the first framework to directly generate the mentioned package name given the vulnerability description. since generation requires the llm inference to be invoked only once, our approach can easily scale to larger language models such as llama-13b and vicuna-13b on a single gpu server. our initial investigation shows that the raw outputs of llms suffer from several types of errors including hallucination. motivated by an empirical study of these errors, we propose the following techniques for improving vullibgen. first, we leverage supervised fine-tuning (sft), in-context learning, and retrieval-augmented generation (rag) to enhance the domain knowledge of a llm. second, we propose a novel local search technique to post-process the raw output for reducing hallucination, i.e., ensuring that the generated package name actually exists. our local search algorithm matches the raw output with the closest existing package name based on the edit distance. since the sub-level package information (e.g., mailcommander in figure 1 ) is often more directly mentioned than the top-level package information (e.g., org.jenkins-ci.plugins), our local search algorithm first matches the suffix before the prefix. we evaluate vullibgen on four vulnerability ecosystems: java, js, python, and go. our evaluation attains three main findings. first, we observe that the precision of vullibgen (0.806) significantly outperforms existing ranking approaches using smaller models @xcite @xcite (0.721) and the computational time costs are comparable. second, our ablation studies show that sft, rag, and local search all help improve the precision of vullibgen and sft contributes to the most improvement. in particular, the fine-tuned open-source vicuna-13b outperforms the unfinetuned commercial chatgpt and gpt-4 models. our local search algorithm can significantly reduce the hallucination in the original llm output, and it is especially helpful for longer package names such as java and go. third, vullibgen provides high value to security practice: at the time of the writing, we have submitted 60 pairs @xmath0, affected @xmath1, 14 js, 11 python, 10 go) and 34 of them have been accepted and merged. ## existing work on vulnerable package identification this section summarizes existing work on affected package identification and analyze the scalability challenge. ## two challenges with llm generation in contrast to existing work, we propose the first work, vullibgen, that leverages llms for affected package identification. due to the scalability challenge of the retrieval approach, our approach directly generates rather than retrieves the affected package. vullibgen thus only need to invoke the llm inference once for each vulnerability q. nevertheless, there exist two challenges with the generative approach. challenge 1: lack of domain knowledge. the first challenge is that there may exist a knowledge gap for the llm to generate the correct package. this is because the description may not contain the full information about the affected package name. for example, cve-2020-2167 in to understand whether post-processing is promising for solving challenge 2 and to study how to design the post-processing algorithm, we conduct an empirical study on chatgpt's incorrect response, the study result can be seen in ## vullibgen framework to address the two challenges in llm generation, we employ the following techniques: first, we use supervised fine-tuning and in-context learning to enhance the domain knowledge in llm; second, we further employ the retrieval-augmented framework (rag) to enhance the knowledge when sft is not easy; third, we design a local search technique which alleviates the non-existing package name problem. the vullibgen framework can be found in figure 2 3 . ## conclusion in this paper, we have proposed vullibgen, the first framework for identifying vulnerable packages using llm generation. vullibgen conducts retrieval-augmented generation, supervised finetuning, and a local search technique to improve the generation. vullibgen is highly effective, achieving an average precision of 0.806 while the best sota approaches achieve only 0.721. vullibgen has shown high value to security practice. we have submitted 60 pairs @xmath2, affected pack-@xmath3.