The npm software package ecosystem is a notable target for adversarial actors, who seek to compromise software dependencies to exploit software developers and the end-users of their software. One especially dangerous form of attack involves the compromise of a package update. By sneaking malicious code into a package update, adversaries can trick package users into unknowingly installing malware. Detecting malicious package updates is an active research problem, as prospective solutions need to keep pace with the near-constant stream of new package updates, while also maintaining high detection accuracy. In this context, one potentially interesting and emergent approach involves utilizing large language models (LLMs) to identify malicious behaviors from the text of package code. However, practical use of LLMs also poses unique first-order challenges, as models are expensive to run and are known to struggle with task performance as input size increases. This work provides a critical exploration into the practicality and effectiveness of LLMs for detecting malicious package updates. We overcome the immediate challenges for LLM-based applications by preprocessing inputs for analysis and postprocessing outputs for malware classification. We find this approach to be practical at repository scale and effective at detecting historical malware incidents, with our best-performing model correctly flagging 209 out of 209 malicious samples across a collection of historical attacks, while only flagging 8 out of 2,000 benign samples across a dataset of typical package updates. With firstorder obstacles overcome, we then conduct a deeper investigation into the reasoning capabilities of LLMs-demonstrating specific mild code obfuscations that uniquely challenge tested LLMs and enable adaptive adversaries to subvert detection. Ultimately, our findings demonstrate nuanced potential for employing LLMs as a part of a larger security toolbelt for detecting package malware.

Attacks on the software supply chain have shed light on the fragility and importance of ensuring the security and integrity of this vital ecosystem. Addressing the technical and social challenges to building trustworthy software (including AI applications) requires innovative solutions and an interdisciplinary approach. The Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses (SCORED) is the leading venue for academics, industry practitioners, and policymakers to present and discuss security vulnerabilities, novel defenses against attacks, deployment experiences, adoption requirements and best practices in the software supply chain. The complete SCORED '25 workshop proceedings are available at: https://doi.org/10.1145/3733827

npm, a package manager for code written for Node.js, is a core component of the software supply chain, and a critical piece of software infrastructure. By selecting and importing code using npm, software developers can quickly build complex software products that would be extremely expensive to develop from scratch. However, "with great power comes great responsibility'', and the npm ecosystem is a frequent target for attacks, which aim at injecting malicious code in packages. In this paper, we take a look at an understudied internet-based attack surface in npm packages: URLs hardcoded within package code. The presence of such URLs---while often necessary---create risks as package behavior may dependend on data - and even code - retrieved from online endpoints. Unless care is taken to ensure such endpoints remain under control of the package authors, package functionality and security may at later point be compromised. Our analysis of the presence of URLs in the npm ecosystem reveals that problematic URL usage is a present threat, albeit one which is primarily localized within unpopular packages that are infrequently maintained.

Autonomous navigation systems present a unique attack surface: their sensors. This attack surface allows for sensor spoofing attacks, where an adversary gains control of an unmanned aerial vehicle (UAV) by manipulating one of its sensors to report incorrect data. Prior research has shown that many of the sensors, including those on UAVs, are vulnerable to sensor spoofing attacks. However, most of the work on sensor spoofing either focuses solely on the vulnerability of the sensor or considers only the Global Navigation Satellite System (GNSS) when attacking a UAV. The impact sensor spoofing has on UAVs and the extent of control an attacker can gain with different sensors is relatively unexplored. Concretely, we show that an adversary only needs to control one of the sensors a UAV uses for state estimation to control the UAV, even if the GNSS is faithful. We further characterize the extent of control an adversary can gain with each sensor and discuss why current defenses are insufficient to stop these attacks.

Reconnaissance is a critical phase in many cyber attacks. Vulnerability scanning, a key component of reconnaissance, has been shown to be a widespread phenomenon on the internet and commonly targets web application/server deployments. By increasing the costs for vulnerability scanning, many of these attacks may be deterred or even prevented, especially for large-scale, internet-wide campaigns.In this paper, we propose Web-Armour, a mitigation approach to adversarial reconnaissance. Operating as a delay injection mechanism to infrequently executed code portions of a web deployment, Web-Armour significantly increases the cost for attackers to perform automated reconnaissance and vulnerability scanning, while introducing minimal to negligible impact for benign users. We evaluated Web-Armour in a live environment, operated by real users, and in controlled (offline) scenarios. Using Web-Armour, our results show that automated scanning tools may require up to 396 times longer in an offline setting, and up to 357 times longer in a real-world operational deployment to complete compared to unprotected installations. In many instances, scanning tools fail to complete their tasks, due to request timeouts. Furthermore, the performance overhead incurred to benign users is minimal, and can be as low as a 0.6% increase over the baseline.

Millions of individuals in the United States without a computer or broadband at their residence must rely on public libraries for their Internet access. Drawing on a rich data set of interviews and participant observation at three public libraries, we explore how individuals navigate these complex settings and how they profoundly shape their digital lives and experiences, one we characterize as digital home-lessness. In this article, we identify three themes that characterize the relationship between library computer use and digital home-lessness: lifeline encompasses the diverse set of activities that require computer and broadband access; negotiating access focuses on usability, privacy, and security disadvantages among these users; and risky business concentrates on the multiplicities of insecure Internet and computing practices exacerbated by low technological capital. Our findings push forward literature on the digital divide by illuminating how the experience of digital home-lessness limits social inclusion and reproduces socioeconomic inequality.

Package confusion incidents--where a developer is misled into importing a package other than the intended one--are one of the most severe issues in supply chain security with significant security implications, especially when the wrong package has malicious functionality. While the prevalence of the issue is generally well-documented, little work has studied the range of mechanisms by which confusion in a package name could arise or be employed by an adversary. In our work, we present the first comprehensive categorization of the mechanisms used to induce confusion, and we show how this understanding can be used for detection. First, we use qualitative analysis to identify and rigorously define 13 categories of confusion mechanisms based on a dataset of 1200+ documented attacks. Results show that, while package confusion is thought to mostly exploit typing errors, in practice attackers use a variety of mechanisms, many of which work at semantic, rather than syntactic, level. Equipped with our categorization, we then define detectors for the discovered attack categories, and we evaluate them on the entire npm package set. Evaluation of a sample, performed through an online survey, identifies a subset of highly effective detection rules which (i) return high-quality matches (77% matches marked as potentially or highly confusing, and 18% highly confusing) and (ii) generate low warning overhead (1 warning per 100M+ package pairs). Comparison with state-of-the-art reveals that the large majority of such pairs are not flagged by existing tools. Thus, our work has the potential to concretely improve the identification of confusable package names in the wild.

Open source package repositories have become a crucial component of the modern software supply chain since they enable developers to easily and rapidly import code written by others. However, low quality, poorly vetted code residing in such repositories exposes developers and end-users to dangerous bugs and vulnerabilities at a large scale. Such issues have recently led to the creation of government-backed verification standards pertaining to packages, as well as a significant body of developer folklore regarding what constitutes a reliable package. However, there exists little academic research assessing the relationships between recommended development practices and known package issues in this domain. Motivated by this gap in understanding, we conduct a large-scale study that formally evaluates whether adherence to these guidelines meaningfully impacts reported issues and bug maintenance activity across the most widely utilized npm packages (encompassing 7,162 packages with over 100K weekly downloads each), which unveiled wide disparities across package-level metrics. We find that it is only recommendations pertaining to a broad notion of scrutiny that provide strong and reliable insights into the reporting and resolving of package issues. These findings pose significant implications for developers, who seek to identify well-maintained packages for use, as well as security researchers, who seek to identify suspicious packages for critical observation.

Autonomous systems, such as unmanned aerial vehicles (UAVs) and self driving cars, operate by reacting to physical phenomena captured by onboard sensors. Current UAVs rely on the Global Positioning System (GPS), or other global navigation satellite system, to determine their location on Earth. Consequently, the GPS receiver can be used as an implicit control channel for autonomous systems. We propose a software defense that uses observations from independent sensor systems to detect GPS spoofing. We modify an open source UAV control program to incorporate our defense and evaluate our defense on hobby-grade drone hardware using simulated GPS spoofing. In our field tests we demonstrate that built-in sensor fusion mechanisms were unable to detect GPS spoofing and that our method could detect subtle GPS spoofing using multiple different sensors.

This work presents findings and mitigations on an understudied issue, which we term shrinkwrapped clones, that is endemic to the npm software package ecosystem. A shrink-wrapped clone is a package which duplicates, or near-duplicates, the code of another package without any indication or reference to the original package. This phenomenon represents a challenge to the hygiene of package ecosystems, as a clone package may siphon interest from the package being cloned, or create hidden duplicates of vulnerable, insecure code which can fly under the radar of audit processes.

This work presents findings and mitigations on an understudied issue, which we term shrinkwrapped clones, that is endemic to the npm software package ecosystem. A shrinkwrapped clone is a package which duplicates, or near-duplicates, the code of another package without any indication or reference to the original package. This phenomenon represents a challenge to the hygiene of package ecosystems, as a clone package may siphon interest from the package being cloned, or create hidden duplicates of vulnerable, insecure code which can fly under the radar of audit processes. Motivated by these considerations, we propose unwrapper, a mechanism to programmatically detect shrinkwrapped clones and match them to their source package. unwrapper uses a package difference metric based on directory tree similarity, augmented with a prefilter which quickly weeds out packages unlikely to be clones of a target. Overall, our prototype can compare a given package within the entire npm ecosystem (1,716,061 packages with 20,190,452 different versions) in 72.85 seconds, and it is thus practical for live deployment. Using our tool, we performed an analysis of a subset of npm packages, which resulted in finding up to 6,292 previously unknown shrinkwrapped clones, of which up to 207 carried vulnerabilities from the original package that had already been fixed in the original package. None of such vulnerabilities were discoverable via the standard npm audit process.

The npm software ecosystem allows developers to easily import code written by others. However, manual vetting of every individual installed component is made difficult in many cases by the number of transitive dependencies brought in by installing popular packages. This has enabled attackers to propagate malicious code by hiding it deep into the dependency chains of popular packages. A particularly dangerous form of attack comes from malicious code embedded into package install scripts. We tackle the problem of preventing undesirable install-time behavior by proposing LATCH, a system for mediating install-time capabilities of npm packages. LATCH generates permission manifests summarizing each package's install-time behavior and checks them against user-defined policies to ensure compliance. Policies in LATCH are expressed in a rich formal policy language that covers a broad range of use cases. Our key insight is that expressive LATCH policies empower users to define and enforce their own individualized security needs. Evaluation of practical LATCH policies on all publicly available npm packages and on a number of real-world attack packages demonstrates that our approach is effective in identifying and stopping unwanted behavior while minimizing disruption due to undesired alerts.

Pseudorandom function (PRF) services are utilized to cryptographically harden password hashes against offline brute-force attacks. State-of-the-art implementations of PRF services can additionally offer benefits such as detection of online attacks and practical key rotation, but the cost of doing so in a publicly distributed setting is requiring clients to trust a third party service. These third party services are not incentivized to behave honestly and pose as a single point of failure for Denial of Service (DoS) attacks. A successful DoS attack mounted against a deployed PRF service would prevent its clients from authenticating their users' passwords, thus making it impossible for users to log in to those clients' services. To address these issues, we design and implement Parcae, the first blockchain-based publicly distributed PRF service. Parcae offers all of the additional benefits provided by state-of-the-art PRF services while also providing DoS attack resilience and service auditing capabilities through use of a permissioned blockchain. Performance analysis shows that our implementation of Parcae is practical and can scale to meet the needs of a dynamically growing client base in a publicly distributed setting.

DNS CNAME redirections, which can “steer” browser requests towards a domain different than the one in the request’s URI, are a simple and oftentimes effective means to obscure the source of a web object behind an alias. These redirections can be used to make third-party content appear as first-party content. The practice of evading browser security mechanisms through misuse of CNAMEs, referred to as CNAME cloaking, has been recently growing in popularity among advertisers/trackers to bypass blocklists and privacy policies. While CNAME cloaking has been reported in past measurement studies, its impact on browser cookie policies has not been analyzed. We close this gap by presenting an in-depth characterization of how CNAME redirections affect cookie propagation. Our analysis uses two distinct data collection samples (June and December 2020). Beyond confirming that CNAME cloaking continues to be popular, our analysis identifies a number of websites transmitting sensitive cookies to cloaked third-parties, thus breaking browser cookie policies. Manual review of such cases identifies exfiltration of authentication cookies to advertising/tracking domains, which raises serious security concerns.

Package managers for software repositories based on a single programming language are very common. Examples include npm (JavaScript), and PyPI (Python). These tools encourage code reuse, making it trivial for developers to import external packages. Unfortunately, repositories' size and the ease with which packages can be published facilitates the practice of typosquatting: the uploading of a package with name similar to that of a highly popular package, typically with the aim of capturing some of the popular package's installs. Typosquatting has serious negative implications, resulting in developers importing malicious packages, or -- as we show -- code clones which do not incorporate recent security updates. In order to tackle this problem, we present SpellBound, a tool for identifying and reporting potentially erroneous imports to developers. SpellBound implements a novel typosquatting detection technique, based on an in-depth analysis of npm and PyPI. Our technique leverages a model of lexical similarity between names, and further incorporates the notion of package popularity. This approach flags cases where unknown/scarcely used packages would be installed in place of popular ones with similar names, before installation occurs. We evaluated SpellBound on both npm and PyPI, with encouraging results: SpellBound flags typosquatting cases while generating limited warnings (0.5% of total package installs), and low overhead (only 2.5% of package install time). Furthermore, SpellBound allowed us to confirm known cases of typosquatting and discover one high-profile, unknown case of typosquatting that resulted in a package takedown by the npm security team.

Service meshes have emerged as an attractive DevOps solution for collecting, managing, and coordinating microservice deployments. However, current service meshes leave fundamental security mechanisms missing or incomplete. The security burden means service meshes may actually cause additional workload and overhead for administrators over traditional monolithic systems. By assessing the effectiveness and practicality of service mesh tools, this work provides necessary insights into the available security of service meshes. We evaluate service meshes from two perspectives: skilled system administrators (who deploy optimal configurations of available security mechanisms) and default configurations. Under these two models, we consider a comprehensive set of adversarial scenarios and uncover important design flaws with contradicting goals, as well as the limitations and challenges encountered in employing service mesh tools for operational environments.

In this work, we evaluate the security of heuristicand machine learning-based classifiers for the detection of malicious JavaScript code. Due to the prevalence of web attacks directed though JavaScript injected into webpages, such defense mechanisms serve as a last-line of defense by classifying individual scripts as either benign or malicious. State-of-the-art classifiers work well at distinguishing currently-known malicious scripts from existing legitimate functionality, often by employing training sets of known benign or malicious samples. However, we observe that real-world attackers can be adaptive, and tailor their attacks to the benign content of the page and the defense mechanisms being used to defend the page. In this work, we consider a variety of techniques that an adaptive adversary may use to overcome JavaScript classifiers. We introduce a variety of new threat models that consider various types of adaptive adversaries, with varying knowledge of the classifier and dataset being used to detect malicious scripts. We show that while no heuristic defense mechanism is a silver bullet against an adaptive adversary, some techniques are far more effective than others. Thus, our work points to which techniques should be considered best practices in classifying malicious content, and a call to arms for more advanced classification.

Service meshes have emerged as an attractive DevOps solution for collecting, managing, and coordinating microservice deployments. However, current service meshes leave fundamental security mechanisms missing or incomplete. The security burden means service meshes may actually cause additional workload and overhead for administrators over traditional monolithic systems. By assessing the effectiveness and practicality of service mesh tools, this work provides necessary insights into the available security of service meshes. We evaluate service meshes under skilled administrators (who deploy optimal configurations of available security mechanisms) and default configurations. We consider a comprehensive set of adversarial scenarios, uncover design flaws contradicting system goals, and present limitations and challenges encountered in employing service mesh tools for operational environments.