ABSTRACT A code summarization engine based on large language models (LLMs) can describe code functionality from different perspectives according to programmers' needs. However, these engines are at risk of black‐box backdoor attacks. We propose a simple yet practical method called Bad Prompt Attack (BPA), specifically designed to investigate such black‐box backdoor attacks. This innovative attack method aims to induce the code summarization engine to generate summarizations that conceal security vulnerabilities in source code. Consistent with most commercial code summarization engines, BPA only assumes black‐box query access to the target engine without requiring knowledge of its internal structure. This attack targets in‐context learning by injecting adversarial demonstrations into user input prompts. We validated our method on the SOTA black‐box commercial service, OpenAI API. In security‐critical test cases covering seven types of CWE, BPA significantly increased the likelihood that the code summarization engine would generate the attacker‐desired code summarization targets, achieving an average attack success rate (ASR) of 91.4%. This result underscores the potential threat of backdoor attacks on code summarization tasks while providing essential reference points for future defense research.

For blockchain software systems, framework developers may introduce technical debts that application developers are not aware of. Because these technical debts can have a negative impact on software projects, we need to investigate the issue of technical debt in blockchain software systems. We wanted to investigate what types of self-introduced technical debt exist in open-source blockchain software systems, and how these technical debts are distributed. We have selected six most popular blockchain software projects from GitHub. Then the code comments from these software projects were extracted and manually labelled. Finally, the code comments were statistically analysed. We propose a new type of technical debt, resource debt, which is explicitly identified by the framework developers and requires special attention in subsequent production systems. Six types of technical debt are prevalent and there is not any algorithm debt. In addition, we find that the code comments containing technical debt are not entirely determined by task tags. SATD is prevalent in blockchain projects. There is more significant variability between different application software projects for different technical debts. The results of the study imply that for detecting SATD, deep semantic discovery models should be used, such as pre-trained models.

Abstract Cross‐project defect prediction (CPDP) is needed when the target projects are new projects or the projects have less training data, since these projects do not have sufficient historical data to build high‐quality prediction models. The researchers have proposed many CPDP methods, and previous studies have conducted extensive comparisons on the performance of different CPDP methods. However, to the best of our knowledge, it remains unclear whether different CPDP methods can identify the same defective modules, and this issue has not been thoroughly explored. In this article, we select 12 state‐of‐the‐art CPDP methods, including eight supervised methods and four unsupervised methods. We first compare the performance of these methods in the same experiment settings on five widely used datasets (ie, NASA, SOFTLAB, PROMISE, AEEEM, and ReLink) and rank these methods via the Scott‐Knott test. Final results confirm the competitiveness of unsupervised methods. Then we perform diversity analysis on defective modules for these methods by using the McNemar test. Empirical results verify that different CPDP methods may lead to difference in the modules predicted as defective, especially when the comparison is performed between the supervised methods and unsupervised methods. Finally, we also find there exist a certain number of defective modules, which cannot be correctly identified by any of the CPDP methods or can be correctly identified by only one CPDP method. These findings can be utilized to design more effective methods to further improve the performance of CPDP.