Spelling suggestions: "subject:"tredjepartsbibliotek"" "subject:"tredjepartsbiblioteket""
1 |
Assessing the Effectiveness of Strict Java Third-Party Library Management in Software Supply Chain on Product Security : A software supply chain vulnerability challengeSandsjö, Carl, Manjusak, Medin January 2023 (has links)
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.
|
2 |
Assessing the Effectiveness of Strict Java Third-Party Library Management in Software Supply Chain on Product Security : A software supply chain vulnerability challengeSandsjö, Carl, Manjusak, Medin January 2023 (has links)
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.
|
Page generated in 0.0341 seconds