Laurie Williams’s research while affiliated with North Carolina State University and other places

In 2023, Sonatype reported a 200\% increase in software supply chain attacks, including major build infrastructure attacks. To secure the software supply chain, practitioners can follow security framework guidance like the Supply-chain Levels for Software Artifacts (SLSA). However, recent surveys and industry summits have shown that despite growing interest, the adoption of SLSA is not widespread. To understand adoption challenges, \textit{the goal of this study is to aid framework authors and practitioners in improving the adoption and development of Supply-Chain Levels for Software Artifacts (SLSA) through a qualitative study of SLSA-related issues on GitHub}. We analyzed 1,523 SLSA-related issues extracted from 233 GitHub repositories. We conducted a topic-guided thematic analysis, leveraging the Latent Dirichlet Allocation (LDA) unsupervised machine learning algorithm, to explore the challenges of adopting SLSA and the strategies for overcoming these challenges. We identified four significant challenges and five suggested adoption strategies. The two main challenges reported are complex implementation and unclear communication, highlighting the difficulties in implementing and understanding the SLSA process across diverse ecosystems. The suggested strategies include streamlining provenance generation processes, improving the SLSA verification process, and providing specific and detailed documentation. Our findings indicate that some strategies can help mitigate multiple challenges, and some challenges need future research and tool enhancement.

Cyber attacks leveraging or targeting the software supply chain, such as the SolarWinds and the Log4j incidents, affected thousands of businesses and their customers, drawing attention from both industry and government stakeholders. To foster open dialogue, facilitate mutual sharing, and discuss shared challenges encountered by stakeholders in securing their software supply chain, researchers from the NSF-supported Secure Software Supply Chain Center (S3C2) organize Secure Supply Chain Summits with stakeholders. This paper summarizes the Industry Secure Supply Chain Summit held on November 16, 2023, which consisted of \panels{} panel discussions with a diverse set of \participants{} practitioners from the industry. The individual panels were framed with open-ended questions and included the topics of Software Bills of Materials (SBOMs), vulnerable dependencies, malicious commits, build and deploy infrastructure, reducing entire classes of vulnerabilities at scale, and supporting a company culture conductive to securing the software supply chain. The goal of this summit was to enable open discussions, mutual sharing, and shedding light on common challenges that industry practitioners with practical experience face when securing their software supply chain.

Software development teams need to produce and assess secure software products so that they can perform critical functionality. Because no software product can ever be "perfectly secure," development teams need to decide when a software product is "secure enough" to be released, that is, to make a decision on the product's release readiness. The goal of this paper is to aid software practitioners in predicting whether a software product is "secure enough" to be released through the evolution and evaluation of software security growth models (SSGM). In this paper, we adapt and evolve software reliability growth models (SSGMs) for the purpose of SSGM using empirical software vulnerability analysis. We quantitatively compare the quality of agile software versions by comparing the security correction and detection process over testing time and software testing cost. The framework is generic to incorporate software vulnerability data into different time frames and multiple agile software versions. We evaluated our SSGM using data from Google Chromium, which uses an agile process with releases every 50 days.

Security sensitive APIs provide access to security-sensitive resources, e.g., the filesystem or network resources. Including such API calls -- directly or through dependencies -- increases the application's attack surface. An example of such a phenomenon is Log4Shell, which rendered many applications vulnerable due to network-related capabilities (JNDI lookup) in log4j package. Before the Log4Shell incident, alternate logging libraries to log4j were available that do not make JNDI lookup calls. The impact of such an incident would be minimal if information about network-related API calls by logging libraries were available to the developers. And so the lack of visibility into the calls to these security sensitive APIs by functionally similar open-source packages makes it difficult for developers to use them as a dependency selection criterion. The goal of this study is to aid developers in selecting their dependency by understanding security sensitive APIs in their dependency through call graph analysis. We conducted a mixed-methods study with 45 Java packages and defined a list of 219 security sensitive APIs. We then used call graph analysis to analyze the prevalence of these APIs in our selected package versions, with and without their dependencies. Finally, we conducted a survey with open-source developers (110 respondents) showing the comparison of functionally similar packages w.r.t. Security sensitive API calls to understand the usefulness of this API information in the dependency selection process. The number of Security sensitive API calls of functionally similar packages can vary from 0 to 368 in one API category and 0 to 429 in total. Our survey results show that 73% developers agree that information about the number and type of security-sensitive API calls of functionally similar packages would have been useful in their dependency selection.

Feature toggles and configuration options are techniques to include or exclude functionality in software. The research contributions to these two techniques have most often been focused on either one of them. However, focusing on the similarities of these two techniques and the use of a common terminology may enable a combined family of research on software configuration (a term we use to encompass both techniques) and prevent duplication of effort. The goal of this study is to aid researchers in conducting a family of research on software configuration by extending an existing model of software configuration that provides a common terminology for feature toggles and configuration options in research studies. We started with Siegmund et al.’s Model of Software Configuration (MSC), which was developed based on configuration option-related resources. We extend the MSC by qualitative analysis of feature toggle-related resources. From our analysis, we proposed MSCv2 and evaluated it through its application on publications and an industrial system. Our results indicate researchers studying the same system may provide different definitions of software configuration in publications, similar research questions may be answered repeatedly because of a lack of a clear definition of software configuration, and having a model of software configuration may enable generalized research on this family of research.

Developers rely on open-source packages and must review dependencies to safeguard against vulnerable or malicious upstream code. A careful review of all dependencies changes often does not occur in practice. Therefore, developers need signals to inform of dependency changes that require additional examination. The goal of this study is to help developers prioritize dependency review efforts by analyzing contributor reputation measures as a signal. We use network centrality measures to proxy contributor reputation using collaboration activity. We employ a mixed method methodology from the top 1,644 packages in the Rust ecosystem to build a network of 6,949 developers, survey 285 developers, and model 5 centrality measures. We find that only 24% of respondents often review dependencies before adding or updating a package, mentioning difficulties in the review process. Additionally, 51% of respondents often consider contributor reputation when reviewing dependencies. The closeness centrality measure is a significant factor in explaining how developers review dependencies. Yet, centrality measures alone do not account for how developers choose to review dependencies. We recommend that ecosystems like GitHub, Rust, and npm implement a contributor reputation badge based on our modeled coefficients to aid developers in dependency reviews.

Knowing the exploitability and severity of software vulnerabilities helps practitioners prioritize vulnerability mitigation efforts. Researchers have proposed and evaluated many different exploitability assessment methods. The goal of this research is to assist practitioners and researchers in understanding existing methods for assessing vulnerability exploitability through a survey of exploitability assessment literature. We identify three exploitability assessment approaches: assessments based on original, manual CVSS, automated Deterministic assessments, and automated Probabilistic assessments. Other than the original CVSS, the two most common subcategories are Deterministic, Program-State-Based, and Probabilistic Learning Model (LM) Assessments.