<p dir="ltr">Software Package Registries are an integral part of the Software Supply Chain, acting as collaborative platforms that unite contributors, users, and packages, and streamline package management processes. Much of the engineering work around reusing packages from these platforms deals with the issue of synthesis, combining multiple packages into a new package or downstream project. Recently, researchers have examined registries that specialize in providing Pre-Trained Models (PTMs), to explore the nuances of the PTM Supply Chain. These works suggest that the main engineering challenge of PTM reuse is not synthesis but selection. However, these findings have been primarily qualitative and lacking quantitative evidence of the observed differences. I therefore evaluate the following hypothesis:</p><p dir="ltr"><i>The prioritization of selection over synthesis in Pre-Trained Model reuse means that the evolution and reuse of Pre-Trained Models differs compared to traditional software. </i><i>The evolution of models will be more linear, and the reuse of models will be more centralized.</i></p>

Free and Open-Source Software (FOSS) has become an integral part of the software supply chain in the past decade. Various entities (automated tools and humans) are involved at different stages of the software supply chain. Some actions that occur in the chain may result in vulnerabilities or malicious code injected in a published artifact distributed in a package repository. At the end of the software supply chain, developers or end-users may consume the resulting artifacts altered in transit, including benign and malicious injection. This dissertation starts from the first link in the software supply chain, ‘developers’. Since many developers do not update their vulnerable software libraries, thus exposing the user of their code to security risks. To understand how they choose, manage and update the libraries, packages, and other Open-Source Software (OSS) that become the building blocks of companies’ completed products consumed by end-users, twenty-five semi-structured interviews were conducted with developers of both large and small-medium enterprises in nine countries. All interviews were transcribed, coded, and analyzed according to applied thematic analysis. Although there are many observations about developers’ attitudes on selecting dependencies for their projects, additional quantitative work is needed to validate whether behavior matches or whether there is a gap. Therefore, we provide an extensive empirical analysis of twelve quality and popularity factors that should explain the corresponding popularity (adoption) of PyPI packages was conducted using our tool called py2src. At the end of the software supply chain, software libraries (or packages) are usually downloaded directly from the package registries via package dependency management systems under the comfortable assumption that no discrepancies are introduced in the last mile between the source code and their respective packages. However, such discrepancies might be introduced by manual or automated build tools (e.g., metadata, Python bytecode files) or for evil purposes (malicious code injects). To identify differences between the published Python packages in PyPI and the source code stored on Github, we developed a new approach called LastPyMile . Our approach has been shown to be promising to integrate within the current package dependency management systems or company workflow for vetting packages at a minimal cost. With the ever-increasing numbers of software bugs and security vulnerabilities, the burden of secure software supply chain management on developers and project owners increases. Although automated program repair approaches promise to reduce the burden of bug-fixing tasks by suggesting likely correct patches for software bugs, little is known about the practical aspects of using APR tools, such as how long one should wait for a tool to generate a bug fix. To provide a realistic evaluation of five state-of-the-art APR tools, 221 bugs from 44 open-source Java projects were run within a reasonable developers’ time and effort.

<p dir="ltr">Modern software relies heavily on third-party dependencies (often distributed via public package registries), making software supply chain attacks a growing threat. Prior work investigated attacks and defenses, but only taxonomized attacks or proposed defensive techniques, did not consistently define software supply chain attacks, and did not provide properties to assess the security of software supply chains. We do not have a unified definition of software supply chain attacks nor a set of properties that a secure software supply chain should follow.</p><p dir="ltr">Guaranteeing authorship in a software supply chain is also a challenge. Package maintainers can guarantee package authorship through software signing. However, it is unclear how common this practice is or if existing signatures are created properly. Prior work provided raw data on registry signing practices, but only measured single platforms, did not consider quality, did not consider time, and did not assess factors that may influence signing. We do not have up-to-date measurements of signing practices nor do we know the quality of existing signatures. Furthermore, we lack a comprehensive understanding of factors that influence signing adoption.</p><p dir="ltr">This thesis addresses these gaps. First, we systematize existing knowledge into: (1) a four-stage supply chain attack pattern; and (2) a set of properties for secure supply chains (transparency, validity, and separation). Next, we measure current signing quantity and quality across three kinds of package registries: traditional software (Maven Central, PyPI), container images (Docker Hub), and machine learning models (Hugging Face). Then, we examine longitudinal trends in signing practices. Finally, we use a quasi-experiment to estimate the effect that various factors had on software signing practices.</p><p dir="ltr">To summarize the findings of our quasi-experiment: (1) mandating signature adoption improves the quantity of signatures; (2) providing dedicated tooling improves the quality of signing; (3) getting started is the hard part — once a maintainer begins to sign, they tend to continue doing so; and (4) although many supply chain attacks are mitigable via signing, signing adoption is primarily affected by registry policy rather than by public knowledge of attacks, new engineering standards, etc. These findings highlight the importance of software package registry managers and signing infrastructure.</p>

Background. Recent trends indicates that attackers are shifting focus to more vulnerable targets; the software supply chain, which has consequently resulted in one of the top security challenges faced by organizations. One specific aspect of the software supply chain that has garnered significant attention is the use of third-party libraries and the high degree of impact exploited vulnerabilities have in relation to third-party libraries, such as Log4Shell. Objectives. The objective of this thesis is to determine the impact of removing unused Java third-party library classes in terms of security vulnerabilities and business value. Methods. A Gradle plugin was developed consisting of three coupled tasks to be used in the experiment where the primary objective is identifying and removing unused third-party classes. The experiment was conducted on 11 production-grade projects. For each of the 11 projects, approximately 12 versions were tested. The plugin was executed on each of the versions and a manual analysis of the result was conducted. The manual analysis consisted of finding the vulnerabilities connected to the respective vulnerable class. Subsequently, the result was analyzed and calculated. Results. The results from the tested projects showed a low overall impact on the number of vulnerabilities before and after the removal of unused classes. However, the vulnerability results differed greatly among the projects. A pattern between all projects was that the vulnerabilities increased in earlier versions. In the projects where there was an effect of removing unused classes, the average CVSS score increased which represents the severity of the vulnerabilities. This suggests that low-severity vulnerabilities were more prevalent in the set of removed vulnerabilities. Over all projects, there was a 40-50% decrease in the total number of classes before and after removing classes which from a security perspective lowers the project’s overall attack surface. On average 85% of the vulnerabilities were found after the release of the project versions. Conclusions. Based on the results we can see that the removal of unused third-party library classes does not have a significant impact on the number of vulnerabilities in the analyzed Java applications. However, this may not reflect all Java projects as we could see a greater impact on certain projects. The removal of vulnerabilities post-release date of a Java component was seen to have minimal to no business value for the analyzed projects. In contrast, a pilot study on a different project from another team within the same company demonstrated a higher level of business value. The reduction of the attack surface was assessed to 40-50% on all conducted projects, which would indicate a significant business value. Before incorporating such a solution, each project would need to be evaluated to determine the balance between security and complexity. / Bakgrund. De senaste trenderna tyder på att attackerare flyttar fokus till mer sårbara mål; mjukvaruförsörjningskedjan, vilket har blivit en av de största säkerhetsutmaningarna som organisationer står inför. En specifik aspekt av mjukvaruförsörjningskedjan som har fått stor uppmärksamhet är användningen av tredjepartsbibliotek och den höga graden av påverkan som exploaterade sårbarheter har i förhållande till tredjepartsbibliotek, såsom Log4Shell. Syfte. Syftet med denna studie är att fastställa effekten av att ta bort oanvända Java-klasser från tredjepartsbibliotek ur en sårbarhet och företagsvärde -perspektiv. Metod. Ett Gradle-plugin utvecklades bestående av tre beroende uppgifter som ska användas i experimentet där det primära målet är att identifiera och ta bort oanvända tredjepartsklasser. Experimentet genomfördes på 11 projekt av produktionskvalitet. För vart och ett av dessa 11 projekt testades cirka 12 versioner. Gradle-pluginet kördes på var och en av versionerna samt en manuell analys av resultatet utfördes. Den manuella analysen bestod i att hitta sårbarheterna kopplade till respektive sårbar klass. Därefter analyserades och beräknades resultatet. Resultat. Resultatet av de testade projekten visade en låg total inverkan på antalet sårbarheter före och efter borttagningen av oanvända klasser. Dessa resultat skilde sig dock mycket mellan projekten. Ett specifikt mönster mellan alla projekt var att sårbarheterna ökade i tidigare versioner. I de projekt där borttagning av klasser gjorde en inverkan, ökade genomsnittet av CVSS-poängen vilket representerar allvarlighetsgraden av sårbarheterna. Detta tyder på att svagheter med låga poäng var vanligare i uppsättningen av borttagna sårbarheter. Över alla projekt så togs 40-50% av det totala antalet klasser bort, vilket ur ett säkerhetsperspektiv sänker projektets totala attackyta. I genomsnitt hittades 85% av sårbarheterna efter lanseringen av projektversionerna. Slutsatser. Baserat på resultaten kan vi se att borttagningen av oanvända klasser från tredjepartsbibliotek inte har någon betydande påverkan på antalet sårbarheter i de analyserade Java-applikationerna. Men detta kanske inte speglar alla Java-projekt då vi kunde se en större påverkan på vissa projekt. Borttagning av sårbarheter efter releasedatum för ett Java-projekt visade sig ha minimalt till noll företagsvärde för de analyserade projekten. En pilotstudie på ett projekt som hanteras av ett annat team i samma företag, resulterade i ett större företagsvärde. Reduceringen av attackytan uppskattas till 40-50% för alla genomförda projekt, vilket innebär ett större företagsvärde. Innan man integrerar en sådan lösning, bör varje projekt utvärderas för att fastställa balansen mellan säkerhet och komplexitet.

The software supply chain constitutes all the resources needed to produce a software product. A large part of this is the use of open-source software packages.Although the use of open-source software makes it easier for vast numbers of developers to create new products, they all become susceptible to the same bugs or malicious code introduced in components outside of their control.Ethereum is a vast open-source blockchain network that aims to replace several functionalities provided by centralized institutions.Several software clients are independently developed in different programming languages to maintain the stability and security of this decentralized model.In this report, the software supply chains of the most popular Ethereum clients are cataloged and analyzed.The dependency graphs of Ethereum clients developed in Go, Rust, and Java, are studied. These client are Geth, Prysm, OpenEthereum, Lighthouse, Besu, and Teku.To do so, their dependency graphs are transformed into a unified format.Quantitative metrics are used to depict the software supply chain of the blockchain.The results show a clear difference in the size of the software supply chain required for the execution layer and consensus layer of Ethereum.Varying degrees of software diversity are present in the studied ecosystem. For the Go clients, 97% of Geth dependencies also in the supply chain of Prysm.The Java clients Besu and Teku share 69% and 60% of their dependencies respectively.The Rust clients showing a much more notable amount of diversity, with only 43% and 35% of OpenEthereum and Lighthouse respective dependencies being shared. / Mjukvaruleverantörskedjan sammanfattar
all resurser som behövs för att producera en mjukvaruprodukt.
En stor del av detta är användningen av öppen källkod. Trots att
användningen av öppen källkod tillåter snabb produktion av nya
produkter, utsätter sig alla som använder den för potentiella bug-
gar samt attacker som kan tillföras utanför deras kontroll. Ethere-
um är ett stort blockkedje nätverk baserad på öppen källkod som
försöker konkurrera med tjänster som tidigare endast erbjudits
av centraliserade institutioner. Det finns flera implementationer
av mjukvaran som implementerar Ethereum som alla utvecklas
oberoende av varandra i olika programmerings språk för att öka
stabiliteten och säkerheten av den decentraliserade modellen. I
denna rapport studeras mjukvaruleverantörskedjorna av de mest
populära klienterna som implementerar Ethereum. Dessa utveck-
las i programmeringsspråken Go, Rust, och Java. Dom studerade
klienterna är Geth, Prysm, OpenEthereum, Lighthouse, Besu, och
Teku. För att genomföra studien transformeras klienternas mjuk-
varuleverantörskedjor till ett standardiserat format. Kvantitiva
mått används för att beskriva dessa leverantörskedjor. Resultaten
visar en stor skillnad i storlek av leverantörskedjor för olika
lager i Ethereum. Det visas att det finns en varierande mångfald
av mjukvara baserat på de språk som klienter är utvecklade med.
Leverantörskedjorna av Go klienter sammanfaller i princip fullt,
medan de av Java klienter sammanfaller med en stor majoritet,
och de av Rust klienter visar på mest mångfald i mjukvarupaket. / Kandidatexjobb i elektroteknik 2022, KTH, Stockholm

Background: Recent trends indicates that attackers are shifting focus to more vulnerable targets; the software supply chain, which has consequently resulted in one of the top security challenges faced by organizations. One specific aspect of the software supply chain that has garnered significant attention is the use of third-party libraries and the high degree of impact exploited vulnerabilities have in relation to third-party libraries, such as Log4Shell. Objectives: The objective of this thesis is to determine the impact of removing unused Java third-party library classes in terms of security vulnerabilities and business value. Methods: A Gradle plugin was developed consisting of three coupled tasks to be used in the experiment where the primary objective is identifying and removing unused third-party classes. The experiment was conducted on 11 production-grade projects. For each of the 11 projects, approximately 12 versions were tested. The plugin was executed on each of the versions and a manual analysis of the result was conducted. The manual analysis consisted of finding the vulnerabilities connected to the respective vulnerable class. Subsequently, the result was analyzed and calculated. Results: The results from the tested projects showed a low overall impact on the number of vulnerabilities before and after the removal of unused classes. However, the vulnerability results differed greatly among the projects. A pattern between all projects was that the vulnerabilities increased in earlier versions. In the projects where there was an effect of removing unused classes, the average CVSS score increased which represents the severity of the vulnerabilities. This suggests that low severity vulnerabilities were more prevalent in the set of removed vulnerabilities. Over all projects, there was a 40-50% decrease in the total number of classes before and after removing classes which from a security perspective lowers the project’s overall attack surface. On average 85% of the vulnerabilities were found after the release of the project versions. Conclusions: Based on the results we can see that the removal of unused third-party library classes does not have a significant impact on the number of vulnerabilities in the analyzed Java applications. However, this may not reflect all Java projects as we could see a greater impact on certain projects. The removal of vulnerabilities post release date of a Java component was seen to have minimal to no business value for the analyzed projects. In contrast, a pilot study on a different project from another team within the same company demonstrated a higher level of business value. The reduction of the attack surface was assessed to 40-50% on all conducted projects, which would indicate a significant business value. Before incorporating such a solution, each project would need to be evaluated to determine the balance between security and complexity. / Bakgrund: De senaste trenderna tyder på att attackerare flyttar fokus till mer sårbara mål; mjukvaruförsörjningskedjan, vilket har blivit en av de största säkerhetsutmaningarna som organisationer står inför. En specifik aspekt av mjukvaruförsörjningskedjan som har fått stor uppmärksamhet är användningen av tredjepartsbibliotek och den höga graden av påverkan som exploaterade sårbarheter har i förhållande till tredjepartsbibliotek, såsom Log4Shell. Syfte: Syftet med denna studie är att fastställa effekten av att ta bort oanvända Java-klasser från tredjepartsbibliotek ur en sårbarhet och företagsvärde -perspektiv. Metod: Ett Gradle-plugin utvecklades bestående av tre beroende uppgifter som ska användas i experimentet där det primära målet är att identifiera och ta bort oanvända tredjepartsklasser. Experimentet genomfördes på 11 projekt av produktionskvalitet. För vart och ett av dessa 11 projekt testades cirka 12 versioner. Gradle-pluginet kördes på var och en av versionerna samt en manuell analys av resultatet utfördes. Den manuella analysen bestod i att hitta sårbarheterna kopplade till respektive sårbar klass. Därefter analyserades och beräknades resultatet. Resultat: Resultatet av de testade projekten visade en låg total inverkan på antalet sårbarheter före och efter borttagningen av oanvända klasser. Dessa resultat skilde sig dock mycket mellan projekten. Ett specifikt mönster mellan alla projekt var att sårbarheterna ökade i tidigare versioner. I de projekt där borttagning av klasser gjorde en inverkan, ökade genomsnittet av CVSS-poängen vilket representerar allvarlighetsgraden av sårbarheterna. Detta tyder på att svagheter med låga poäng var vanligare i uppsättningen av borttagna sårbarheter. Över alla projekt så togs 40-50% av det totala antalet klasser bort, vilket ur ett säkerhetsperspektiv sänker projektets totala attackyta. I genomsnitt hittades 85% av sårbarheterna efter lanseringen av projektversionerna. Slutsatser: Baserat på resultaten kan vi se att borttagningen av oanvända klasser från tredjepartsbibliotek inte har någon betydande påverkan på antalet sårbarheter i de analyserade Java-applikationerna. Men detta kanske inte speglar alla Java-projekt då vi kunde se en större påverkan på vissa projekt. Borttagning av sårbarheter efter releasedatum för ett Java-projekt visade sig ha minimalt till noll företagsvärde för de analyserade projekten. En pilotstudie på ett projekt som hanteras av ett annat team i samma företag, resulterade i ett större företagsvärde. Reduceringen av attackytan uppskattas till 40-50% för alla genomförda projekt, vilket innebär ett större företagsvärde. Innan man integrerar en sådan lösning, bör varje projekt utvärderas för att fastställa balansen mellan säkerhet och komplexitet.