A composed technical debt identification methodology to predict software vulnerabilities
Yazılım zafiyetlerini tahmin etmek için kapsamlı bir teknik borç tanımlama yöntemi
- Tez No: 860799
- Danışmanlar: DOÇ. DR. AYŞE TOSUN KÜHN
- Tez Türü: Doktora
- Konular: Bilgisayar Mühendisliği Bilimleri-Bilgisayar ve Kontrol, Computer Engineering and Computer Science and Control
- Anahtar Kelimeler: Belirtilmemiş.
- Yıl: 2024
- Dil: İngilizce
- Üniversite: İstanbul Teknik Üniversitesi
- Enstitü: Lisansüstü Eğitim Enstitüsü
- Ana Bilim Dalı: Bilgisayar Mühendisliği Ana Bilim Dalı
- Bilim Dalı: Bilgisayar Mühendisliği Bilim Dalı
- Sayfa Sayısı: 169
Özet
Yazılım gelis ̧tirme, hızla deg ̆is ̧en teknoloji ve artan müs ̧teri gereksinimleriyle birlikte sürekli bir yatırım haline gelmis ̧tir ve yazılım gelis ̧tirme teknolojileri harcamalarının gelecek bes ̧ yıl içinde önemli ölçüde artması beklenmektedir. Yazılım pazarı büyük ölçüde büyüdüg ̆ü için yazılım gelis ̧tirme daha dinamik ve kapsamlı bir süreç haline gelmis ̧tir. Büyük ve karmas ̧ık yazılım projelerinin gelis ̧tirilmesi, müs ̧teri gereksinimleri ve ihtiyaçları, deg ̆is ̧en teknoloji, rekabet ve piyasa kos ̧ulları gibi birçok faktörü içermektedir. Yazılım sistemleri, hızla gelis ̧en bilis ̧im teknolojileri ortamında deg ̆is ̧en müs ̧teri gereksinimlerini ve teknolojik ilerlemeleri kars ̧ılamak için gelis ̧tirilebilir ve bakımı yapılabilir olmalıdır. Bu sürecin karmas ̧ıklıg ̆ı ile birlikte, yazılım deg ̆is ̧iklik yönetimi ve bakımı, gelis ̧tirme yas ̧am döngüsünün önemli faaliyetleri haline gelmis ̧tir. Proje ekipleri, takvim, kaynaklar ve bütçeyle sınırlı olmaları nedeniyle müs ̧teri beklentilerini kars ̧ılamak için borca girmekte, ancak daha sonra bakım süreci boyunca ek maliyetlerle kars ̧ılas ̧maktadır. Yazılım kalitesi, müs ̧teri deg ̆eri yaratmak için gereksinimleri tanımlayabilen ve uygulayabilen yazılım sistemlerinin belirli ölçütler dahilinde ne kadar iyi yapıldıg ̆ını ve performansını ifade eder. Bu ölçütler, yazılım gelis ̧tirme sürecinin her as ̧amasında dikkatlice deg ̆erlendirilmesi ve yönetilmesi gereken yazılımın dog ̆rulug ̆u, güvenilirlig ̆i, verimlilig ̆i, kullanılabilirlig ̆i, bakımı kolaylıg ̆ı ve güvenlig ̆i gibi faktörleri içerir. Yazılım gelis ̧tirme yas ̧am döngüsü hatalara açık oldug ̆unda, yazılımın nitelig ̆i eksik veya yanlıs ̧ yorumlanmıs ̧ gereksinimler, tasarım hataları, eksik fonksiyonel mantık, geçerlilik yoklug ̆u ve kodlama hataları açısından yetersiz olabilir. Bu bag ̆lamda, yazılım kalitesi iki boyutta ele alınmaktadır. ̇Ilk olarak, yazılım sisteminde hata veya güvenlik açıg ̆ı olmaması gerektig ̆i gerçeg ̆idir. ̇Ikincisi ise sistemde, alınan teknik borç çes ̧itli kalite özelliklerine uygun olarak yönetilebilmelidir. Kalitenin sag ̆lanması, ürün standartları ve prosedürler ile uyuma ve kalite deg ̆erlendirmesine sistematik bir yaklas ̧ıma dayanmaktadır. Teknik borç, aceleye getirilen tasarım kararları, kod uygulamaları ve yetersiz testlerin sonucu olarak kısa vadeli hedefler için uzun vadeli yazılım kalitesinden ödün veren birikmis ̧ maliyeti ifade eder. Teknik borç görünmez kaldıg ̆ında ve yönetilemedig ̆inde, zamanla birikir ve mali borca benzer s ̧ekilde, ekstra çaba olan faiz ödemelerine sahip olabilir. Birikmis ̧ borç, yazılımın sürdürülebilirlig ̆ini ve gelis ̧tirilebilirlig ̆ini zorlas ̧tırarak yazılım kalitesini kötü etkiler ve potansiyel olarak güvenlik risklerine yol açar. Teknik borç yönetimi, sürekli bir süreçtir ve bu nedenle bu sürecin genel yazılım gelis ̧tirme sürecine entegre edilmesi önemlidir. Dolayısıyla, teknik borcun yazılımın yas ̧am döngüsü boyunca etkin bir s ̧ekilde yönetilmesi, yazılım sürdürülebilirlig ̆i, gelis ̧tirilebilirlig ̆i ve güvenlig ̆i açısından son derece önemlidir. Yazılım güvenlig ̆i bir kalite özellig ̆idir ve güvenli yazılımlar olus ̧turarak sistemlerin ve ag ̆ların güvenlik açıklarına ve istismarlara kars ̧ı korunmasını ifade eder. Yazılım gelis ̧tirme yas ̧am döngüsü boyunca en iyi güvenlik uygulamalarının entegre edilmesiyle, güvenlik açıklarıyla ilis ̧kili riskler azaltılabilir. Ancak, bir sistemin güvenlik açıg ̆ı olasılıg ̆ını azaltmak için, güvenlik odaklı düs ̧ünceyi sistemlere dahil etmek daha iyi bir stratejidir. Çünkü genel yas ̧am döngüsü boyunca is ̧levsel ve güvenli gelis ̧imin bir arada sag ̆lanması, yazılımın tüm katmanlarında koruma sag ̆layacaktır. Ayrıca kodlama ve tasarım kusurları, güvenlik açıklarına önemli ölçüde katkıda bulunuyor ve güvenlik tehditlerini önleme aracı olarak teknik borcun ele alınmasının önemini vurguluyor. Bu tezin temel amacı, teknik borç ile yazılım güvenlig ̆i arasındaki ilis ̧kiyi aras ̧tırmak ve yazılım sistemlerindeki teknik paydas ̧lar ile is ̧ paydas ̧ları arasındaki iletis ̧im bos ̧lug ̆unu dolduracak bilgiler sag ̆lamaktır. Bu hedefe ulas ̧mak için çes ̧itli projelerin GitHub repolarından ve Ulusal Güvenlik Açıg ̆ı Veritabanı'ndan (ing. National Vulnerability Database) gerçek dünya verilerini topladık ve analiz ettik. Güvenlik açıg ̆ı verilerini, ilgili kod deg ̆is ̧iklikleriyle ilis ̧kilendirmek için V-SZZ algoritması kullandık ve güvenlik açıklarına neden olan commitleri belirledik. Ayrıca, kod kalitesi sorunlarının yazılım güvenlig ̆i üzerindeki etkisini aras ̧tırmak için PMD aracını kullanarak projelerdeki kod kokularını içeren veri seti hazırladık. Bu tezde, açık kaynaklı projelerden gerçek güvenlik açıg ̆ı verilerinin toplanması ve analizi yoluyla teknik borç ile yazılım güvenlig ̆i arasındaki ilis ̧kiye dair deg ̆erli bilgiler sunmaya odaklanıyoruz. Bu analiz, teknik borcun yazılım güvenlig ̆ini ve ilgili riskleri nasıl etkiledig ̆inin daha derinlemesine anlas ̧ılmasını sag ̆lar. ̇Ilk olarak, teknik borcun hafifletilmesinde yeniden kod düzenlemenin rolünün farkında olarak, kod kokuları ve kod hataları gibi teknik borç göstergeleri ile yeniden kod düzenleme faaliyetleri arasındaki ilis ̧kiyi aras ̧tırıyoruz. Bu nedenle, yeniden kod düzenleme etkisinin anlas ̧ılmasına derinlik katan ampirik bulgular sunuyoruz. Yeniden kod düzenleme faaliyetlerini ve bunların teknik borç üzerindeki etkisini analiz ederek, yeniden kod düzenlemenin kod kokularını ve/veya hatalarını ne ölçüde iyiles ̧tirebileceg ̆ini veya azaltabileceg ̆ini belirlemeyi hedefliyoruz. Ardından, yazılım güvenlig ̆i risklerini tahmin etmek için yazılım metrikleri, kod kokuları ve hatalar dahil olmak üzere teknik borç göstergelerinin kapsamlı bir analizini yapıyoruz. Çoklu teknik borç göstergelerini inceleyerek, teknik borç ile kırılganlıklar arasındaki ilis ̧kiye dair bütünsel bir bakıs ̧ sunmayı amaçlıyoruz. Bu analiz, yazılım güvenlig ̆i risklerini güvenilir bir s ̧ekilde tahmin edebilecek belirli göstergelerin belirlenmesine yardımcı olacak ve böylece proaktif risk azaltma çabalarına olanak sag ̆layacaktır. ̇Iki tür aras ̧tırma yöntemi yürütüyoruz; kes ̧fedici aras ̧tırma ve açıklayıcı aras ̧tırma. Bu yöntemlerin her biri farklı bir amaca hizmet eder ve yazılım gelis ̧tirmenin çes ̧itli yönlerini aras ̧tırmak için kullanılır. Hem kes ̧fedici hem de açıklayıcı çalıs ̧malar yazılım mühendislig ̆i aras ̧tırmalarında önemli rol oynar. Kes ̧ifsel çalıs ̧malar yeni veya yeterince anlas ̧ılmamıs ̧ olguları kes ̧fetmemizi sag ̆larken, açıklayıcı çalıs ̧malar deg ̆is ̧kenler arasındaki neden-sonuç ilis ̧kilerini aras ̧tırmamıza olanak sag ̆lar. Bu aras ̧tırma yöntemlerini kullanarak yazılım gelis ̧tirme sürecine ilis ̧kin deg ̆erli bilgiler edinebilir ve bir bütün olarak yazılım mühendislig ̆i anlayıs ̧ımızı gelis ̧tirebiliriz. Tezin ilk as ̧amalarında bir kes ̧if çalıs ̧ması yürüttük ve teknik borç göstergeleri ile teknik borcuhafifletme/geriödemeyöntemleriarasındakiilis ̧kiyiinceledik. Buas ̧amada kod kokuları, hatalar ve yeniden kod düzenleme yöntemlerinin nasıl ilis ̧kili oldug ̆unu daha iyi anlamayı hedefliyoruz. Ardından, teknik borç ile yazılım açıkları arasındaki neden-sonuç ilis ̧kilerini aras ̧tırmak için iki açıklayıcı çalıs ̧ma yürütüyoruz. Teknik borcun varlıg ̆ının potansiyel güvenlik açıklarının etkili bir göstergesi olup olmadıg ̆ını deg ̆erlendirmek amacıyla, makine ög ̆renmesi modelleri olus ̧turarak yazılım güvenlik açıklarını tahmin etmek amacıyla dog ̆rudan/dolaylı teknik borç göstergelerinden yararlandık. Teknik Borç veri seti ve SmartSHARK veri seti olmak üzere iki veri seti kullandık. Kes ̧if analizi yaparken Apache Software Foundation deposundaki 33 Java tabanlı projeden olus ̧an Teknik Borç veri setini kullandık. Bu projeler en az üç yıllık projelerdir ve her biri minimum 500 commit içerir. Ayrıca projelerin repolarındaki ek verileri de taradık. Bu veriler, deg ̆is ̧tirilen dosyaları, commitleri, kod kokularını ve commitlerle ilis ̧kili issue izleme sistemindeki bilgileri içeriyordu. Açıklayıcı analizlerde Apache Software Foundation reposundaki 77 projeyi içeren SmartSHARK veri setini kullandık. Yeniden kod düzenleme faaliyetleri, hata olus ̧turma ve hata düzeltme is ̧lemleri, kod kokuları ve yazılım ölçümleriyle ilgili belirli tablolar kullandık. Bu arada, yazılım güvenlik açıg ̆ı tahmini için bir veri hazırlama rehberini takip ettik. Böylece, Java projelerinin seçilmesini, çes ̧itli güvenlik açıg ̆ı türlerinin hedeflenmesini, commit ayrıntı düzeyinin seçilmesini ve karma proje tahmin yaklas ̧ımının benimsenmesini içeren veri gereksinimlerini belirledik. Verileri etiketlemek için Ulusal Güvenlik Açıg ̆ı Veritabanından elde edilen gerçek dünya güvenlik açıg ̆ı raporlarından yararlandık. Güvenlik açıklarının sisteme dahil oldug ̆u ve giderildig ̆i commitleri birbirleri ile manuel olarak ilis ̧kilendirdik. Bu, kapsamlı bir aras ̧tırma ve es ̧les ̧tirme çabası gerektirir. Ayrıca sınıf dengesizlig ̆ini gidermek ve ilis ̧kisiz, gürültülü ve yinelenen kodları ortadan kaldırmak için çes ̧itli veri temizleme adımları uyguladık. Ampirik çalıs ̧mamızdan elde ettig ̆imiz sonuçları sunmak ve önemli bulguları tartıs ̧mak için iki ana aras ̧tırma sorusunu ve bunların alt sorularını ele alıyoruz. Birinci aras ̧tırma sorusu ve onun alt sorularını yanıtlarken, teknik borç göstergeleri ile teknik borç azaltma yöntemleri arasındaki ilis ̧kiyi aras ̧tırmayı amaçlayan kes ̧fedici bir analiz yürütüyoruz. Aras ̧tırmanın bu ilk as ̧aması, teknik borç ög ̆eleri arasındaki istatistiksel ilis ̧kilere odaklanıyor. Bu amaçla, 29 yeniden kod düzenleme türünün farklı projeler arasındaki dag ̆ılımını ve bunların kod kokuları veya hatalarıyla olan ilis ̧kilerini analiz ediyoruz. En sık birlikte gerçekles ̧tirilen yeniden kod düzenleme türlerini ve yeniden kod düzenlemeyle gerçekles ̧tirilen dig ̆er aktiviteleri aras ̧tırıyoruz. Yeniden kod düzenleme faaliyetlerinin commitlerin yalnızca küçük bir kısmında, yaklas ̧ık %9'unda gerçekles ̧tirildig ̆ini rapor ediyoruz. Sonuçlar, bazı yeniden kod düzenleme türlerinin gelis ̧tiriciler tarafından daha yaygın olarak uygulandıg ̆ını göstermektedir. En sık gözlenen yeniden kod düzenleme etkinlig ̆i, toplam yeniden kod düzenleme aktivitelerinin %20,1'inde tespit edilen“ Move Class ”aktivitesidir. Rename Method“ ve ”Extract Method" yeniden kod düzenleme faaliyetleri de sırasıyla %14,3 ve %11,7 oranlarıyla sıklıkla uygulanmaktadır. Yeniden kod düzenleme faaliyetlerinin kod kokularının yog ̆unlug ̆u üzerindeki etkisini aras ̧tıran analizimiz,yenidendüzenlemeleringenelliklekodkokularınıortadankaldırdıg ̆ınıveya etkilemedig ̆ini göstermektedir ve bu, önceki çalıs ̧malarla çelis ̧mektedir. Sonuçlarımıza göre, yazılım sistemine kod kokuları dahil eden yeniden kod düzenlemelerin yüzdesi %7,6; yazılım sistemindeki kod kokularını ortadan kaldıran yeniden düzenlemelerin yüzdesi ise %40,1'dir. Ayrıca, yeniden kod düzenleme(ler)in gerçekles ̧tirildig ̆i commitler, yeniden kod düzenlemesi yapılmayanlara göre üç kat daha fazla hataya neden olur. Yeniden kod düzenleme faaliyetleri, kod kokuları ve yazılım gelis ̧tirmedeki hatalar, kaynak kodu temsillerine dayanmaktadır. Bu bulgular, güvenlik açıg ̆ına neden olan kod deg ̆is ̧ikliklerini tahmin etmek için makine ög ̆renmesi modelleri gelis ̧tirmeye yönelik iki açıklayıcı çalıs ̧maya zemin hazırladı. Açıklayıcı çalıs ̧malarda, yazılımdaki güvenlik açıklarını tahmin ederken makine ög ̆renmesi modellerini eg ̆itmek için yazılım metrig ̆i tabanlı, gömme tabanlı yaklas ̧ımlar, kod kokuları, yeniden kod düzenleme yöntemleri, kod hataları dahil olmak üzere çes ̧itli kaynak kodu temsillerinden yararlanıyoruz. ̇Ilk açıklayıcı çalıs ̧mada, yazılım metrig ̆i tabanlı yaklas ̧ım ile gömme tabanlı yaklas ̧ımın sonuçlarını kars ̧ılas ̧tırdık. ̇Ilk açıklayıcı çalıs ̧mamızın bulgularına göre, yazılım metriklerine dayalı kod temsili yöntemi, duyarlılık(%85,1), kesinlik(%3,9) ve F-Ölçütü(%7,2) açısından gömme tabanlı kod temsili yöntemine göre daha iyi sınıflandırma performansına sahiptir. Ancak, yanlıs ̧ pozitif oranı yüksek oldug ̆u için daha detaylı analizlerle ikinci açıklayıcı çalıs ̧mayı gerçekles ̧tirdik. ̇Ikinci açıklayıcı çalıs ̧mada, farklı öznitelik setlerini kullandık ve bir güvenlik açıg ̆ı sisteme girdikten sonra giderilene kadar bulundug ̆u tüm commitleri güvenlik açıg ̆ı var s ̧eklinde etiketledik. Bu çalıs ̧mada, yazılımdaki güvenlik açıklarını tahmin etmek için yazılım ölçümleri, kod kokuları ve hatalar dahil olmak üzere dog ̆rudan/dolaylı teknik borç göstergelerinin yanı sıra yeniden kod düzenleme faaliyetleri gibi teknik borç azaltma tekniklerinin kullanımına dog ̆rudan odaklanıyoruz. Bu amaçla, yazılım güvenlik açıklarına yönelik tahmin modellerinin kapsamlı bir analizini gerçekles ̧tirdik ve bunların tahminler üzerindeki etkilerine ilis ̧kin bulgularımızı gelis ̧tirmek için çes ̧itli öznitelik seti kombinasyonlarının sonuçlarını kars ̧ılas ̧tırdık. Çalıs ̧mamız, yazılım güvenlik açıklarına yönelik tahmine dayalı modellemede öznitelik seçimi ve bunların kombinasyonunun önemini vurgulamaktadır. Aras ̧tırma metodolojimiz, hem dengeli (%50) hem de çes ̧itli oranlarda (%70, %80, %90) olus ̧turulan dengesiz test setlerini kullanarak güvenlik açıg ̆ı tahmin modelinin performansının kapsamlı bir deg ̆erlendirmesini içermektedir. Bu, yüksek derecede dengesiz veri kümeleri için modelin sag ̆lamlıg ̆ı ve genelles ̧tirilebilirlig ̆i konusunda deg ̆erli bilgiler sag ̆layabilir. Testsetioranı%50oldug ̆undaenyüksekduyarlılıkoranı%99,3oldu;budabumodelin tüm yazılım açıklarının %99,3'ünü dog ̆ru bir s ̧ekilde tespit edebildig ̆ini gösteriyor. En yüksek kesinlik oranına ise %96,9 ile ulas ̧ıldı. En yüksek F1-ölçütü oranı %97,3 ile elde edildi. Bu durum, en iyi modelin hem olumlu hem de olumsuz vakaları dog ̆ru bir s ̧ekilde tanımlama açısından yüksek bir performansa sahip oldug ̆unu gösteriyor. Sonuçlarımıza göre, yazılım gelis ̧tirme kapsamındaki yazılım metrikleri, kod kokuları, hatalar veya yeniden kod düzenleme faaliyetleri gibi dog ̆rudan/dolaylı teknik borç göstergeleri, yazılım projelerinde güvenlik açıklarının olus ̧masına katkıda bulunmaktadır. Ayrıca, yazılım metriklerini kod kokularıyla birles ̧tirmenin, yazılımdaki güvenlik açıklarını tahmin etmede yeniden kod düzenleme ve hatalara göre daha yüksek bas ̧arı oranları elde ettig ̆ini gözlemliyoruz. Bu tezin bulguları, teknik borç göstergelerinin, teknik borç hafifletme yöntemlerinin ve bunların yazılım güvenlig ̆i üzerindeki etkisinin anlas ̧ılmasına önemli ölçüde katkıda bulunmayı amaçlamaktadır. Yazılım projeleri, teknik borcu etkili bir s ̧ekilde tanımlayıp ele alarak sürdürülebilirlig ̆i, gelis ̧tirilebilirlig ̆i artırabilir ve güvenlik açıg ̆ı riskini azaltabilir. Ayrıca aras ̧tırmamız, teknik borç ile yazılım güvenlig ̆i arasında net bir bag ̆lantı kurmaya çalıs ̧arak yazılım gelis ̧tirme uygulayıcıları ve karar vericiler için eyleme geçirilebilir bilgiler sag ̆lar. Kurulus ̧lar, yazılım güvenlig ̆inin sag ̆lanmasında teknik borç yönetiminin öneminin farkına vararak, teknik borç azaltma çabalarına öncelik vermek ve yazılım sistemlerinin genel kalitesini ve güvenlig ̆ini artırmak için bilinçli kararlar alabilirler.
Özet (Çeviri)
Software systems must be evolvable and maintainable to meet evolving customer requirements and technology advancements in a rapidly changing IT landscape. Technical debt refers to the accumulated cost as a consequence of rushed design decisions and code implementations and inadequate testing, which compromises long-term software quality for short-term objectives. When technical debt remains invisible and cannot be managed, it accumulates over time and similar to financial debt, it can have interest payments that are the extra effort for future development. The accumulated debt complicates software maintainability and evolvability and potentially leads to security risks. Technical Debt Management is a continuous process, and hence, it is important to integrate this process into the overall software development process. Software security is a quality characteristic and refers to the protection of the systems and networks against vulnerabilities and exploits by building secure software. By integrating security best practices throughout the software development life cycle, the risks associated with security vulnerabilities can be mitigated. To reduce the possibility of a system's vulnerability, incorporating security-oriented thinking into the systems is a better strategy as providing functional and secure development together throughout the overall life cycle will offer protection at all layers of the software. Besides, coding and design flaws are significant contributors to vulnerabilities, highlighting the significance of addressing technical debt as a means to prevent security threats. The main objective of this thesis is to explore relationship between technical debt and software security and provide insights to bridge the gap between technical and business stakeholders. To accomplish this objective, we collected and analyzed real-world data from various projects' GitHub repositories and the National Vulnerability Database. The vulnerability data is linked to corresponding code changes, enabling the identification of vulnerability-inducing commits. Moreover, we prepared an additional dataset of code smells using the PMD tool to investigate the impact of code quality issues on software security. In this thesis, we focus on offering valuable insights into the relationship between technical debt and software security through the collection and analysis of real vulnerability data from open source projects. This analysis provides a deeper understanding of how technical debt impacts software security and the associated risks. First, we investigate the relationship between technical debt indicators such as code smells and code faults and refactoring activities, recognizing the role of refactoring in mitigating technical debt. Therefore, we provide empirical findings that add depth to the understanding of refactoring impact. By analyzing refactoring activities and their impact on technical debt, we aim to identify the extent to which refactoring can enhance or reduce code smells and/or faults. Then, we conduct a comprehensive analysis of technical debt indicators, including software metrics, code smells, and bugs, to predict software security risks. By examining multiple technical debt indicators, we aim to provide a holistic view of the relationship between technical debt and vulnerabilities. This analysis will assist in identifying specific indicators that can reliably predict software security risks, thereby enabling proactive mitigation efforts. We conduct two types of research methods: exploratory research and explanatory research. These methods are utilized to investigate various aspects of software development, each serving a distinct purpose. Both exploratory and explanatory studies play crucial roles in software engineering research. Exploratory studies enable us to explore new or poorly understood phenomena, while explanatory studies allow us to investigate cause-and-effect relationships between variables. By employing these research methods, we can gain valuable insights into the software development process and enhance our understanding of software engineering as a whole. During the early stages of thesis, we conducted an exploratory study and look into the relationship between technical debt indicators and mitigation methods. In this phase, we aim to gain a better understanding of how code smells, bugs and refactoring methods are related. Then, we conduct two explanatory studies to explore cause-and-effect relationships between technical debt and software vulnerabilities. To assess whether the presence of technical debt could be an effective indicator of potential vulnerabilities, we have utilized direct/indirect technical debt indicators to predict software vulnerabilities by creating ML models. We utilized two datasets, namely Technical Debt dataset and SmartSHARK dataset. When conducting exploratory analysis, we used Technical Debt Dataset that consists of 33 Java-based projects from the Apache Software Foundation repository. These projects are older than three years and have a minimum of 500 commits. Also, we crawled additional data from the projects' repositories. This included information about changed files, commit hashes, code smells, and issue IDs associated with commits. In explanatory analyses, we utilized SmartSHARK dataset that contains 77 projects from the Apache Software Foundation repository. We used specific collections related to refactoring activities, bug-inducing and bug-fixing commits, code smells, and software metrics. Meanwhile, we followed a data preparation pipeline for software vulnerability prediction. Thus, we determined the data requirements, which involved selecting Java projects, targeting various vulnerability types, choosing commit level granularity, and adopting a mixed-project prediction approach. To label the data, we utilized real-world vulnerability reports obtained from National Vulnerability Database. We manually linked vulnerabilities to fixing commits and inducing commits. This involved extensive investigation and mapping efforts. We also applied various data cleaning steps to address the class imbalance and eliminate irrelevant, noisy, and duplicated code. We address two main research questions and their subquestions to present the results obtained from our empirical study and discuss the major findings. When answering RQ1 and its subquestions, we conduct an exploratory analysis that aims to investigate the relationship between technical debt indicators and technical debt mitigation methods. This initial phase of the research focuses on statistical associations between those technical debt items. To this end, we analyze the distribution of 29 refactoring types among the different projects and their relation with code smells or faults. We explore the refactoring types that are most commonly performed together, and other activities performed with refactorings. We report that refactoring activities were performed in only a small portion of the commits, approximately 9%. Results show that some refactoring types are more commonly applied by developers. The most commonly observed refactoring activity is“Move Class,”detected in 20.1% of the refactoring activities.“Rename Method”and“Extract Method”are also frequently applied, with percentages of 14.3% and 11.7% respectively. Our analysis of investigating the impact of refactoring activities on the density of code smells indicates that refactorings usually remove or do not affect the code smells, and this contradicts the previous studies. According to our results, the percentage of refactorings categorized as introduced is 7.6%, while the percentage of refactorings categorized as removed is 40.1%. Also, the commits in which refactoring(s) is performed are three times more fault-inducing than those without refactoring. Those findings have set the stage for two explanatory studies, to develop ML models to predict vulnerability inducing code changes. Refactoring activities, code smells, and faults in software development are based on source code representations. In the first explanatory study, we utilize various source code representations, including software metric-based and embedding-based approaches, to train ML models when predicting software vulnerabilities. According to our first explanatory study's findings, software metrics based code representation method has a better classification performance than embedding based code representation method in terms of recall, precision and F-Measure. Thus, in the second explanatory study, we directly focus on the use of direct/indirect technical debt indicators, including software metrics, code smells, and bugs, as well as technical debt mitigation techniques, such as refactoring activities, to develop ML models to predict software vulnerabilities. To this end, we conducted a comprehensive analysis of predictive models for software vulnerabilities, exploring various feature set combinations to enhance our understanding of their impact on predictions. Our study highlights the significance of feature selection and combination in predictive modelling for software vulnerabilities. Our research methodology involves a comprehensive evaluation of the performance of the vulnerability prediction model using both balanced (50%) and unbalanced test sets created with various rates (70%,80%,90%). This can provide valuable insights into the robustness and generalizability of the model for highly imbalanced datasets. According to our results, direct/indirect technical debt indicators within software development, such as software metrics, code smells, bugs or refactoring activities, contribute to the occurrence of vulnerabilities in software projects. Moreover, we observe that combining software metrics with code smells achieves higher success rates in predicting software vulnerabilities than refactoring and bugs. The findings of this thesis aim to contribute significantly to the understanding of technical debt indicators, mitigation methods and their impact on software security. By effectively identifying and addressing technical debt, software projects can enhance maintainability, evolvability, and reduce the risk of vulnerabilities. Also, our research strives to establish a clear link between technical debt and software security, providing actionable insights for software development practitioners and decision-makers. By recognizing the importance of technical debt management in ensuring software security, organizations can make informed decisions to prioritize technical debt reduction efforts and enhance the overall quality and security of their software systems.
Benzer Tezler
- Sermaye piyasası etkinliği ve İMKB'de uygulaması
Capital market efficiency and a case study on the İstanbul Stock Exchange
ORAL ERDOĞAN
- Avrupa Para Birliği, Avrupa para biriminin hayata geçişi ve işleyişi, Türkiye üzerine etkileri
Başlık çevirisi yok
DİNA İŞLER
- Single monetary policy and economic imbalances in the Eurozone
Tek ortak para politikası ve Avro Bölgesi'ndeki iktisadi dengesizlikler
ROY DÜLGAR
Yüksek Lisans
İngilizce
2013
Ekonomiİstanbul Bilgi ÜniversitesiUluslararası Ekonomi Politikası Ana Bilim Dalı
DOÇ. DR. DURMUŞ ÖZDEMİR
- Gümrük Birliği sürecinin Türk sermaye piyasasına etkileri
The Effects of Customer Union course on Turkish capital market
ÖNDER HALİSDEMİR
Yüksek Lisans
Türkçe
1997
EkonomiMarmara ÜniversitesiSermaye Piyasası ve Borsa Ana Bilim Dalı
PROF. DR. İLHAN ULUDAĞ
- Türkiye'de yabancı sermayeli işletmelerin işçi ve işveren ilişkilerine etkileri
The Effects of foreign capital orginated companies in Turkey in the relationships between employee and employeer
AYTÜN KUĞU