Advancements in Large Language Models (LLMs) allow solving many challenging tasks related to software security in an automatic manner, e.g., the generation of test cases. An important aspect concerns the deobfuscation of source code, especially for improving its readability or preventing the elusion of signature-based countermeasures. Although LLMs are increasingly deployed to reveal the presence of malicious payloads within obfuscated software components, a comprehensive understanding of their potential and limitations is still missing. In this work, we evaluate the effectiveness of deobfuscating JavaScript code through an LLM-based pipeline. In more detail, we investigate whether LLMs can preserve structural properties of the software, especially to enhance the identification of weaknesses. Compared to two standard tools (i.e., JSNice and js-deobfuscator ), our approach provides a more readable JavaScript prose according to several metrics, while retaining information on the Common Weaknesses Enumeration plaguing the software. To support the process of explaining issues within code, we performed tests on the use of two general-purpose LLMs, i.e., ChatGPT and Google Gemini. Results indicate that advancing the security of JavaScript through LLMs requires facing several challenges, which can be largely addressed via ad-hoc models.

The integrity of software builds is fundamental to the security of the software supply chain. While Thompson first raised the potential for attacks on build infrastructure in 1984, limited attention has been given to build integrity in the past 40 years, enabling recent attacks on SolarWinds, event-stream, and xz. The best-known defense against build system attacks is creating reproducible builds; however, achieving them can be complex for both technical and social reasons and thus is often viewed as impractical to obtain. In this paper, we analyze reproducibility of builds in a novel context: reusable components distributed as packages in six popular software ecosystems (npm, Maven, PyPI, Go, RubyGems, and Cargo). Our quantitative study on a representative sample of 4000 packages in each ecosystem raises concerns: Rates of reproducible builds vary widely between ecosystems, with some ecosystems having all packages reproducible whereas others have reproducibility issues in nearly every package. However, upon deeper investigation, we identified that with relatively straightforward infrastructure configuration and patching of build tools, we can achieve very high rates of reproducible builds in all studied ecosystems. We conclude that if the ecosystems adopt our suggestions, the build process of published packages can be independently confirmed for nearly all packages without individual developer actions, and doing so will prevent significant future software supply chain attacks.

Due to the increasing use of advanced offensive techniques, the mitigation of Android malware is an urgent need.An emerging attack trend exploits steganography to conceal malicious payloads within applications to make attacks stealthier.Even if works on "stegomalware" are starting to emerge, they primarily focus on the multimedia part of the attack chain, i.e., on how to detect hidden data in images or videos.Therefore, this work aims at understanding whether the loading stage required for the extraction of cloaked information can generate detection signatures.To this aim, we develop a proofof-concept implementation, which has been repacked within a real Android application and tested against several malware detection engines provided by VirusTotal.To anticipate possible offensive campaigns, we also performed tests by considering threat actors able to obfuscate the bytecode of the loader or the entire APK.Results indicate that standard tools are not ready to face stegomalware targeting Android applications.Therefore, we provide indications on how to improve forensics and attribution phases for Android malware endowed with information hiding capabilities.

Reusable software libraries, frameworks, and components, such as those provided by open source ecosystems and third-party suppliers, accelerate digital innovation. However, recent years have shown almost exponential growth in attackers leveraging these software artifacts to launch software supply chain attacks. Past well-known software supply chain attacks include the SolarWinds, log4j, and xz utils incidents. Supply chain attacks are considered to have three major attack vectors: through vulnerabilities and malware accidentally or intentionally injected into open source and third-party dependencies/components/containers ; by infiltrating the build infrastructure during the build and deployment processes; and through targeted techniques aimed at the humans involved in software development, such as through social engineering. Plummeting trust in the software supply chain could decelerate digital innovation if the software industry reduces its use of open source and third-party artifacts to reduce risks. This article contains perspectives and knowledge obtained from intentional outreach with practitioners to understand their practical challenges and from extensive research efforts. We then provide an overview of current research efforts to secure the software supply chain. Finally, we propose a future research agenda to close software supply chain attack vectors and support the software industry.

Software Bills of Material (SBOMs), which improve transparency by listing the components constituting software, are a key countermeasure to the mounting problem of Software Supply Chain attacks. SBOM generation tools take project source files and provide an SBOM as output, interacting with the software ecosystem. While SBOMs are a substantial improvement for security practitioners, providing a complete and correct SBOM is still an open problem. This paper investigates the causes of the issues affecting SBOM completeness and correctness, focusing on the PyPI ecosystem. We analyze four popular SBOM generation tools using the CycloneDX standard. Our analysis highlights issues related to dependency versions, metadata files, remote dependencies, and optional dependencies. Additionally, we identified a systematic issue with the lack of standards for metadata in the PyPI ecosystem. This includes inconsistencies in the presence of metadata files as well as variations in how their content is formatted.