William Enck

Md Atiqur Rahman, Yasemin Acar, Michel Cucker et al.

Today's digital ecosystem relies heavily on software supply chains, which enable developers to reuse code and ship software at scale. However, a single vulnerable component can jeopardize the entire supply chain. In recent years, cyberattacks in software supply chains have become increasingly common. These attacks can disrupt critical systems and put organizations, including major software companies, government agencies, and open-source contributors, at risk. This growing threat has led to increased attention from both the software industry and the U.S. government toward strengthening software supply chain security. On September 15, 2025, three researchers from the NSF-backed Secure Software Supply Chain Center (S3C2) convened a Secure Software Supply Chain Summit, bringing together 10 practitioners from 8 organizations across diverse domains. The goals of the Summit were threefold: (1) to facilitate cross-industry sharing of practical experiences and challenges in securing software supply chains; (2) to foster new collaborations among participants; and (3) to identify pressing challenges to guide future research directions. The Summit featured discussions on six central topics: vulnerable dependencies, component and container choice, malicious commits, build infrastructure, culture, and the role of LLMs in the supply chain. For each topic, participants engaged with a curated set of discussion questions designed to gather insights and pain points. This report summarizes the key takeaways from these discussions. Each section highlights which topics continued from previous summits and which ideas emerged for the first time in this summit; the full list of initial discussion prompts is provided in the appendix.

Sivana Hamer, Pat Morrison, William Enck et al.

Software supply chains, while providing immense economic and software development value, are only as strong as their weakest link. Over the past several years, there has been an exponential increase in cyberattacks specifically targeting vulnerable links in critical software supply chains. The attacks disrupt day-to-day functioning and threaten the security of nearly everyone on the internet, from billion-dollar companies and government agencies to hobbyist open-source developers. The evolving threat of software supply chain attacks has garnered interest from both the software industry and governments worldwide in improving software supply chain security. On Thursday, July 9th, 2025, 3 researchers from the NSF-backed Secure Software Supply Chain Center (S3C2) conducted a Secure Software Supply Chain Summit with a diverse set of 12 participants from 6 US government agencies. The goals of the Summit were: (1) to enable sharing between participants from different industries regarding practical experiences and challenges with software supply chain security; (2) to help form new collaborations; and (3) to learn about the challenges facing participants to inform our future research directions. The summit consisted of discussions of six topics relevant to the government agencies represented, including software bill of materials (SBOMs); compliance; malicious commits; build infrastructure; culture; and large language models (LLMs) and security. For each topic of discussion, we presented participants with a list of questions to spark conversation and an overview of the discussions of two industry summit held in the past year. In this report, we provide a summary of the summit. The initial discussion questions for each topic are provided in the appendi

Sohom Datta, Alex Nahapetyan, William Enck et al.

Large language models (LLMs) are increasingly being integrated into web browsers to create agentic browsing systems that execute actions on behalf of the user. Prior work considering the security of agentic browsers focuses exclusively on indirect prompt-injection attacks. However, by failing to consider traditional web attacks, previous agentic browser threat models have a blind spot to web social engineering attacks originally designed to trick humans. In this paper, we propose the first web-focused threat model for agentic browsers and use it to derive a taxonomy of 20 attacks across both the web and LLM space, and implement 18 of the attacks. Our threat model extends the original See$\rightarrow$Act browser agent model to account for all components of a browser, and frames the agent as a confused deputy unable to distinguish task steps from traditional web attacks. We show that 10 web threats can reemerge often in amplified forms once an agent can be influenced by untrusted page content. We further conduct a generalizability study on 14 of the 20 attacks, showing that our attacks reproduce across 4 major LLM models spanning multiple vendors. We show that agentic browsers exhibit five major failure modes when facing traditional and LLM web threats, demonstrating the need to rearchitect agentic browsers before they are ready for the current web.

Imranur Rahman, Jill Marley, William Enck et al.

Developers consistently use version constraints to specify acceptable versions of the dependencies for their project. \emph{Pinning} dependencies can reduce the likelihood of breaking changes, but comes with a cost of manually managing the replacement of outdated and vulnerable dependencies. On the other hand, \emph{floating} can be used to automatically get bug fixes and security fixes, but comes with the risk of breaking changes. Security practitioners advocate \emph{pinning} dependencies to prevent against software supply chain attacks, e.g., malicious package updates. However, since \emph{pinning} is the tightest version constraint, \emph{pinning} is the most likely to result in outdated dependencies. Nevertheless, how the likelihood of becoming outdated or vulnerable dependencies changes across version constraint types is unknown. The goal of this study is to aid developers in making an informed dependency version constraint choice by empirically evaluating the likelihood of dependencies becoming outdated or vulnerable across version constraint types at scale. In this study, we first identify the trends in dependency version constraint usage and the patterns of version constraint type changes made by developers in the npm, PyPI, and Cargo ecosystems. We then modeled the dependency state transitions using survival analysis and estimated how the likelihood of becoming outdated or vulnerable changes when using \emph{pinning} as opposed to the rest of the version constraint types. We observe that among outdated and vulnerable dependencies, the most commonly used version constraint type is \emph{floating-minor}, with \emph{pinning} being the next most common. We also find that \emph{floating-major} is the least likely to result in outdated and \emph{floating-minor} is the least likely to result in vulnerable dependencies.

Yu-Tsung Lee, William Enck, Haining Chen et al.

Android filesystem access control provides a foundation for Android system integrity. Android utilizes a combination of mandatory (e.g., SEAndroid) and discretionary (e.g., UNIX permissions) access control, both to protect the Android platform from Android/OEM services and to protect Android/OEM services from third-party apps. However, OEMs often create vulnerabilities when they introduce market-differentiating features because they err when re-configuring this complex combination of Android policies. In this paper, we propose the PolyScope tool to triage the combination of Android filesystem access control policies to vet releases for vulnerabilities. The PolyScope approach leverages two main insights: (1) adversaries may exploit the coarse granularity of mandatory policies and the flexibility of discretionary policies to increase the permissions available to launch attacks, which we call permission expansion, and (2) system configurations may limit the ways adversaries may use their permissions to launch attacks, motivating computation of attack operations. We apply PolyScope to three Google and five OEM Android releases to compute the attack operations accurately to vet these releases for vulnerabilities, finding that permission expansion increases the permissions available to launch attacks, sometimes by more than 10X, but a significant fraction of these permissions (about 15-20%) are not convertible into attack operations. Using PolyScope, we find two previously unknown vulnerabilities, showing how PolyScope helps OEMs triage the complex combination of access control policies down to attack operations worthy of testing.

Iffat Anjum, Mu Zhu, Isaac Polinsky et al.

Historically, enterprise network reconnaissance is an active process, often involving port scanning. However, as routers and switches become more complex, they also become more susceptible to compromise. From this vantage point, an attacker can passively identify high-value hosts such as the workstations of IT administrators, C-suite executives, and finance personnel. The goal of this paper is to develop a technique to deceive and dissuade such adversaries. We propose HoneyRoles, which uses honey connections to build metaphorical haystacks around the network traffic of client hosts belonging to high-value organizational roles. The honey connections also act as network canaries to signal network compromise, thereby dissuading the adversary from acting on information observed in network flows. We design a prototype implementation of HoneyRoles using an OpenFlow SDN controller and evaluate its security using the PRISM probabilistic model checker. Our performance evaluation shows that HoneyRoles has a small effect on network request completion time and our security analysis demonstrates that once an alert is raised, HoneyRoles can quickly identify the compromised switch with high probability. In doing so, we show that a role-based network deception is a promising approach for defending against adversaries that have compromised network devices.

Richard Mitev, Anna Pazii, Markus Miettinen et al.

Manufacturers of smart home Internet of Things (IoT) devices are increasingly adding voice assistant and audio monitoring features to a wide range of devices including smart speakers, televisions, thermostats, security systems, and doorbells. Consequently, many of these devices are equipped with microphones, raising significant privacy concerns: users may not always be aware of when audio recordings are sent to the cloud, or who may gain access to the recordings. In this paper, we present the LeakyPick architecture that enables the detection of the smart home devices that stream recorded audio to the Internet without the user's consent. Our proof-of-concept is a LeakyPick device that is placed in a user's smart home and periodically "probes" other devices in its environment and monitors the subsequent network traffic for statistical patterns that indicate audio transmission. Our prototype is built on a Raspberry Pi for less than USD40 and has a measurement accuracy of 94% in detecting audio transmissions for a collection of 8 devices with voice assistant capabilities. Furthermore, we used LeakyPick to identify 89 words that an Amazon Echo Dot misinterprets as its wake-word, resulting in unexpected audio transmission. LeakyPick provides a cost effective approach for regular consumers to monitor their homes for unexpected audio transmissions to the cloud.

Iffat Anjum, Mohammad Sujan Miah, Mu Zhu et al.

Enterprises are increasingly concerned about adversaries that slowly and deliberately exploit resources over the course of months or even years. A key step in this kill chain is network reconnaissance, which has historically been active (e.g., network scans) and therefore detectable. However, new networking technology increases the possibility of passive network reconnaissance, which will be largely undetectable by defenders. In this paper, we propose Snaz, a technique that uses deceptively crafted honey traffic to confound the knowledge gained through passive network reconnaissance. We present a two-player non-zero-sum Stackelberg game model that characterizes how a defender should deploy honey traffic in the presence of an adversary who is aware of Snaz. In doing so, we demonstrate the existence of optimal defender strategies that will either dissuade an adversary from acting on the existence of real vulnerabilities observed within network traffic, or reveal the adversary's presence when it attempts to unknowingly attack an intrusion detection node.

Isaac Polinsky, Kyle Martin, William Enck et al.

Web servers are a popular target for adversaries as they are publicly accessible and often vulnerable to compromise. Compromises can go unnoticed for months, if not years, and recovery often involves a complete system rebuild. In this paper, we propose n-m-Variant Systems, an adversarial-resistant software rejuvenation framework for cloud-based web applications. We improve the state-of-the-art by introducing a variable m that provides a knob for administrators to tune an environment to balance resource usage, performance overhead, and security guarantees. Using m, security guarantees can be tuned for seconds, minutes, days, or complete resistance. We design and implement an n-m-Variant System prototype to protect a Mediawiki PHP application serving dynamic content from an external SQL persistent storage. Our performance evaluation shows a throughput reduction of 65% for 108 seconds of resistance and 83% for 12 days of resistance to sophisticated adversaries, given appropriate resource allocation. Furthermore, we use theoretical analysis and simulation to characterize the impact of system parameters on resilience to adversaries. Through these efforts, our work demonstrates how properties of cloud-based servers can enhance the integrity of Web servers.

Sigmund Albert Gorski, Benjamin Andow, Adwait Nadkarni et al.

Billions of users rely on the security of the Android platform to protect phones, tablets, and many different types of consumer electronics. While Android's permission model is well studied, the enforcement of the protection policy has received relatively little attention. Much of this enforcement is spread across system services, taking the form of hard-coded checks within their implementations. In this paper, we propose Authorization Check Miner (ACMiner), a framework for evaluating the correctness of Android's access control enforcement through consistency analysis of authorization checks. ACMiner combines program and text analysis techniques to generate a rich set of authorization checks, mines the corresponding protection policy for each service entry point, and uses association rule mining at a service granularity to identify inconsistencies that may correspond to vulnerabilities. We used ACMiner to study the AOSP version of Android 7.1.1 to identify 28 vulnerabilities relating to missing authorization checks. In doing so, we demonstrate ACMiner's ability to help domain experts process thousands of authorization checks scattered across millions of lines of code.

Adwait Nadkarni, William Enck, Somesh Jha et al.

Policy specification for personal user data is a hard problem, as it depends on many factors that cannot be predetermined by system developers. Simultaneously, systems are increasingly relying on users to make security decisions. In this paper, we propose the approach of Policy by Example (PyBE) for specifying user-specific security policies. PyBE brings the benefits of the successful approach of programming by example (PBE) for program synthesis to the policy specification domain. In PyBE, users provide policy examples that specify if actions should be allowed or denied in certain scenarios. PyBE then predicts policy decisions for new scenarios. A key aspect of PyBE is its use of active learning to enable users to correct potential errors in their policy specification. To evaluate PyBE's effectiveness, we perform a feasibility study with expert users. Our study demonstrates that PyBE correctly predicts policies with 76% accuracy across all users, a significant improvement over naive approaches. Finally, we investigate the causes of inaccurate predictions to motivate directions for future research in this promising new domain.

Răzvan Deaconescu, Luke Deshotels, Mihai Bucicoiu et al.

In order to limit the damage of malware on Mac OS X and iOS, Apple uses sandboxing, a kernel-level security layer that provides tight constraints for system calls. Particularly used for Apple iOS, sandboxing prevents apps from executing potentially dangerous actions, by defining rules in a sandbox profile. Investigating Apple's built-in sandbox profiles is difficult as they are compiled and stored in binary format. We present SandBlaster, a software bundle that is able to reverse/decompile Apple binary sandbox profiles to their original human readable SBPL (SandBox Profile Language) format. We use SandBlaster to reverse all built-in Apple iOS binary sandbox profiles for iOS 7, 8 and 9. Our tool is, to the best of our knowledge, the first to provide a full reversing of the Apple sandbox, shedding light into the inner workings of Apple sandbox profiles and providing essential support for security researchers and professionals interested in Apple security mechanisms.

Vasant Tendulkar, William Enck

Computing platforms such as smartphones frequently access Web content using many separate applications rather than a single Web browser application. These applications often deal with sensitive user information such as financial data or passwords, and use Secure Sockets Layer (SSL) to protect it from unauthorized eavesdropping. However, recent studies have confirmed a wide-spread misconfiguration of SSL verification in applications. This paper considers the difficulty faced by Android application developers when modifying SSL code for using common features like pinning or using a self-signed SSL certificate. For example, developing an application that accesses a test Web server with a self-signed certificate requires additional code to remove SSL verification; however, this code is not always removed in production versions of the application. To mitigate vulnerabilities introduced because of the complexity of customizing SSL code in Android applications, we propose that common SSL configuration should be specified in the application's package manifest. We provide two concrete suggestions: 1) linking the application's debug state to SSL verification, and 2) pinning certificates and CAs in the manifest. We evaluate the appropriateness of these two suggestions on over 13,000 applications from Google's Play Store, of which 3,302 use SSL in non-advertisement code, and find that 1,889 (57.20%) of these SSL applications would benefit.