Organizations in highly regulated industries have an increasing need to protect their intellectual assets, because Advanced Persistent Threat (APT) entities are capable of using supply chain attacks to bypass traditional defenses. This work investigates the feasibility of preventing supply chain attacks by isolating the build environment of the software using hardware isolation. Specifically, this work analyzes the extent to which the Intel SGX can guarantee the integrity and authenticity of software produced in Highly Regulated Environments. A theoretical evaluation using assurance cases shows that a hardware isolation approach has the potential to guarantee the integrity and authenticity of the produced software. Security weaknesses in Intel SGX significantly limit the confidence in its ability to secure the build environment. Directions for future work to secure a build environment with a hardware isolation approach are suggested. Most importantly, the guarantees from hardware isolation should be improved, suggestively by choosing a more secure hardware isolation solution, and a proof-of-concept of the approach should be implemented. / Organisationer i mycket reglerade industrier har ett ökat behov av att skydda sina intellektuella tillgångar, eftersom avancerade långvariga hot (APT) har förmågan att använda sig av distributionskedjeattacker för att ta sig förbi existerande skydd. Det här arbetet undersöker möjligheten att skydda sig mot distributionskedjeattacker genom att isolera mjukvarans byggmiljö med hjälp av hårdvaruisolering. Specifikt analyseras till vilken grad Intel SGX kan garantera integriteten och autenticiteten av mjukvara som produceras i mycket reglerade miljöer. En teoretisk evaluering genom assurans visar att hårdvaruisolering har möjligheten att garantera integriteten och autenticiteten hos den producerade mjukvaran. Säkerhetsbrister i Intel SGX begränsar i hög grad förtroendet för dess förmåga att säkra byggmiljön. För vidare forskning föreslås att garantierna från hårdvaruisolering förbättras, förslagsvis genom att välja säkrare hårdvaruisoleringslösningar, samt att en prototyp av lösningen implementeras.

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.