Es ist bekannt, dass Applikationen eine Vielzahl sicherheitsrelevanter Schwachstellen haben können,
wenn nicht die richtigen Massnahmen zur Verhinderung dieser bereits während der Entwicklung durchgeführt werden. Um einige geeignete Massnahmen einzuleiten, habe ich in diesem Jahr für einen Auftraggeber ein Applikatiossicherheits-Projekt durchführen dürfen. Im Projekt wurde der Scope darauf gelegt, den Source Code mit geeigneten Mitteln auf Schwachstellen zu überprüfen. Einige der Ergebnisse und Analysen aus diesem Projekt möchte ich in meinem Blog in mehreren Teilen veröffentlichen. Sie sollen interessierten Lesern dienen, sich den Thematiken aus einer wissenschaftlichen Perspektive anzunähern.
Einleitend möchte ich über publizierte Literatur aufzeigen, zu welchen Ergebnissen vergangene Untersuchungen kamen in Bezug auf die Effektivität automatisierter sowie manueller Schwachstellenanalysen von Source Code. Nachfolgend werden Forschungsresultate sowie weiterführende Quellen verarbeitet, um Erkenntnisse über den aktuellen Stand der Forschung und Praxis zu gewinnen. Im zweiten Teil dieser Blog-Serie widme ich mich den Themen SCA, DAST und des manuellen Code Reviews.
Definition der Bezeichnungen Sicherheit, Bedrohungen, Schwächen und Schwachstellen
Um die Erläuterungen in den kommenden Abschnitten und Blog-Artikeln korrekt interpretieren zu können, werden vielverwendete Begriffe einleitend erläutert. Besonders die Bezeichnung «Schwachstelle» (engl. Vulnerability) findet in der Arbeit oft Verwendung. Es ergibt deshalb Sinn, bereits zu Beginn zu definieren, was mit einer Schwachstelle gemeint ist. Mit «Schwachstelle» wird der Bereich einer Applikationskomponente bezeichnet, welcher die Sicherheit des Systems oder seiner Daten potenziell beeinträchtigen kann.
In der Computer-Wissenschaft besteht Konsens, dass Sicherheit dann erreicht ist, wenn die Vertraulichkeit, Verfügbarkeit und Integrität (engl. Confidentiality, Availability und Integrity) eines Systems und seiner Daten gewährleistet sind [4]. Wann diese erfüllt sind, ist jedoch stark abhängig vom Kontext und den Bedürfnissen des entsprechenden Systems [5]. Bedrohungen (engl. Threats), können die Sicherheit von Systemen und ihrer Daten beeinträchtigen. Gemäss Shirey lassen sich Bedrohungen in die Bereiche Offenlegung (engl. Disclosure), also dem unbefugten Zugriff auf Informationen, Täuschung (Deception), also Akzeptanz falscher Daten, Störung (engl. Disruption), also der Störung des ordnungsgemässen Betriebs und Aneignung (engl. Usurpation), also der unbefugten Kontrolle über das System einteilen [6]. Eine Schwäche (engl. Weakness) in einem System, wiederrum, entsteht durch Fehler und Schwächen im Design, der Implementierung oder den internen Kontrollmechanismen in einem System [6], [7]. Sie beeinträchtigen, bei Vorhandensein einer Bedrohung, die Sicherheit eines Systems und seiner Daten. Es ist zu erwähnen, dass nicht jede vorhandene Schwäche auch durch einen Angreifer (engl. Threat Actor) ausnutzbar (engl. exploitable) ist und so zu einem Sicherheitsvorfall führen könnte. Eine Verarbeitung von Benutzer-Eingaben an einem API-Endpunkt beispielsweise, ohne diese vorher mittels Input Validation[1] zu validieren, führt nicht immer zu einer ausnutzbaren Schwachstelle, welche die Vertraulichkeit, Integrität oder Verfügbarkeit beeinträchtigen würde. Trotzdem handelt es sich in solchen Fällen um ein Nichtbeachten gängiger Sicherheitsempfehlungen im Bereich der sicheren Applikationsentwicklung[2]. Auch Schwächen sollen deshalb im Source Code gefunden werden, denn sie können zu einem späteren Zeitpunkt, wenn das System sich verändert, zu einer ausnutzbaren Schwachstelle führen. In diesem Artikel werden die zwei Begriffe, Schwäche und Schwachstelle, gemeinsam als «Schwachstelle» bezeichnet.
STAND DER FORSCHUNG
Static Application Security Testing
Static Analysis, oft auch Static Application Security Testing (SAST) genannt, ist die gängige Methode, um Schwachstellen automatisiert im Quellcode zu finden [8], [9]. Dabei wird Source Code über verschiedene Mechanismen auf Schwachstellen überprüft. Die Analysen reichen dabei von String-Pattern-Matching, in welchem eine Zeile Code oder ein Code-Block auf ein Pattern hin untersucht wird, bis hin zu komplexeren Analysen, bei welchem der Daten- und Programmfluss von Source to Sink analysiert wird [8], [10]–[12]. Sie soll Entwickler dabei unterstützen, Fehler in ihrem produzierten Code zu entdecken.
Effektivität von SAST-Werkzeugen
Es ist von Wichtigkeit, die Vollständigkeit von gefundenen Schwachstellen von SAST-Werkzeugen richtig einzuschätzen. Wird die Effektivität von solch einem Werkzeug falsch beurteilt, kann dies zu einer falschen Bewertung des verbleibenden Risikos noch vorhandener, jedoch unentdeckter Schwachstellen führen. Verschiedene Arbeiten zeigen, dass die Verwendung von SAST-Werkzeugen mit einer hohen Anzahl von FP (False Positives) [13] und FN (False Negatives) [14] einhergeht. Die nachfolgende Tabelle 2.1 dokumentiert die eben genannten Begriffe, um sie in den Kontext von SAST einzuordnen.
| Begriff | Bedeutung |
| False Positive (FP) | Es wird eine Schwachstelle durch das SAST-Werkzeug entdeckt, obwohl sie in Realität im Source Code nicht existiert. |
| False Negative (FN) | Eine Schwachstelle wird durch das SAST-Werkzeug nicht entdeckt, obwohl sie in Realität im Source Codeexistiert. |
| True Positive (TP) | Eine Schwachstelle wird durch das SAST-Werkzeug entdeckt und existiert tatsächlich auch im Source Code. |
| True Negative (TN) | Eine Schwachstelle wird durch das SAST-Werkzeug nicht im Source Code entdeckt und existiert tatsächlich auch nicht. |
Eine hohe Anzahl von FP und/oder FN kann für Entwicklerteams zeitaufwendig sein und das Vertrauen in ein Werkzeug schädigen, wie auch Reynolds et al. in ihrer Arbeit schreiben [15]. Zusatzaufwände für das Entwicklerteam für aufkommende FP sollen somit berücksichtigt werden. In einer Arbeit von Austin & Williams waren 74-98 % der gefundenen Schwachstellen FP und verursachten 18-40 Stunden an Arbeit, um die potenziellen Schwachstellen zu klassifizieren [16, pp. 100–101]. Andere Arbeiten zeigten ähnliche FP-Raten [17, pp. 276–278]. In einer allfälligen Evaluation eines Werkzeugs soll also die FP-Rate als Metrik mitbetrachtet werden.
Es wurden bereits verschiedene Studien zur Leistung von SAST-Werkzeugen durchgeführt. Antunes und Vieira beispielsweise halten in ihren Untersuchungen fest, dass sogar «state-of-the-art»-Werkzeuge eine tiefe Effektivität haben, was das Auffinden von Schwachstellen betrifft [17]. Ihre Arbeit gibt zudem Hinweise darauf, dass eine höhere prozentuelle Abdeckungsrate von TP wohl auch jeweils mit einer proportional höheren Anzahl von FP einhergehen. Dieser Umstand wurde in der Arbeit von Higuera bestätigt [9]. Es wird vermutet, dass dies bei der Entwicklung eines Source-Code–Scanners nicht so einfach zu vermeiden ist. Andere Studien kommen zum Schluss, dass wohl auch fehlende Kontextinformationen zu hohen FP beitragen [12, p. 18], [13]. Ein Grund dafür ist, dass Scanner den Source Codeim statischen Zustand analysieren, ohne ihn im laufenden Betrieb und in der eingebetteten Umgebung zu betrachten. Dies führt zu einer einseitigen Betrachtung der Applikation und dazu, dass nicht genügend analysiert werden kann, ob eine Schwachstelle im Programmfluss überhaupt erreicht werden kann. Auch dies kann zu verfälschten Resultaten führen.
SAST-Werkzeuge haben bei der Erkennung von Schwachstellen Stärken und Schwächen. Nicht jede Art von Schwachstelle wird gleich gut erkannt, wie Untersuchungen zeigen. Besonders Design-Schwächen, welche die Business-Logik der Applikation betreffen, werden schlecht erkannt, wie die Arbeiten von Higuera et al. [9] aufzeigt sowie von OWASP erwähnt wird [18]. Design-Schwächen in der Business-Logik könnten beispielweise fehlende Autorisierung auf einem API-Endpoint (CWE-285), Insecure Direct Object Reference (CWE-639) oder fehlende Authentisierung (CWE-287) sein. Alle drei Schwächen werden in den OWASP Top 10[4] vom Jahr 2017 gelistet. Dies bedeutet, dass sie im Jahr der OWASP-Analyse zu den zehn am häufigsten auftretenden Schwachstellen in Web-Applikationen gehörten. Der Umstand, dass sie mit automatisierten Werkzeugen schwierig zu erkennen sind, jedoch zu den am meisten vorkommenden Schwachstellen zählen, ist von Relevanz, um die Effektivität von SAST-Werkzeugen korrekt einzuschätzen.
In der Arbeit [9] wurde der OWASP Top 10 Benchmark[5] benutzt, dessen Ziel es ist, die Effektivität von SAST-Werkzeugen zu beurteilen. In der Untersuchung wurden 7 SAST-Werkzeuge auf ihre Effektivität in Bezug auf Vollständigkeit überprüft. Zur Betrachtung besonders relevant sind die darin aufgezeigten TP- und FP-Raten bei unterschiedlichen Schwachstellen-Typen, wie Tabelle 2.2 und die darauffolgende Abbildung 1 aufzeigen.
Die Tabelle 2.2 sowie die nachfolgende Abbildung 1 aus der Arbeit von Higuera et al. zeigen im Bereich Broken Authentication und Sensitive Data Exposure eine schlechte Erkennungsrate bei allen untersuchten Werkzeugen (bei Fragen zur Bedeutung dieser Schwachstellentypen wird [9, p. 1562] empfohlen). OWASP erwähnt, dass SAST-Werkzeuge Schwächen bei der Entdeckung von Access Control Schwachstellen haben [19]. In der Studie von [9] erreichten Broken-Access-Control-Schwachstellen hingegen durchschnittliche Resultate, verglichen mit den anderen Kategorien.
Die Abbildung 1 untermauert die eingangs erwähnten Hinweise aus der Arbeit von Antunes und Vieira, dass eine höhere TP-Rate jeweils auch relativ proportional zu einer höheren FP-Rate führt. Es ist jedoch zu erwähnen, dass, obschon die Arbeit von Higuera et al. bereits mehrere Werkzeuge untersuchte, sich ihre Ergebnisse nur begrenzt auf andere Applikationen anwenden lassen. Der Grund dafür wird in Absatz “Multi Language Support” behandelt.
Eine andere Arbeit von Austin & Williams analysiert die Vollständigkeit der Ergebnisse von vier verschiedenen Analysemethoden, von denen eine SAST ist [20, p. 97]. Dabei wurde festgestellt, dass keine der vier Methoden alle Schwachstellen auffinden konnte. Zudem wurde eine bestimmte Schwachstelle nur selten über mehrere Methoden gefunden. Diese Ergebnisse sind hilfreich, um aufzuzeigen, dass Schwachstellen mithilfe verschiedener Methodiken und nicht nur über SAST gesucht werden sollten.
Die untersuchten Arbeiten legen nahe, dass bei der Verwendung von SAST-Werkzeugen möglicherweise nicht alle potenziell vorhandenen Schwachstellen aufgefunden werden können und somit mit einem gewissen Anteil an FN gerechnet werden muss.
Um zudem hohen FP entgegenzuwirken, erachte ich es als wichtig, dass Möglichkeiten zur Verfügung stehen, um Analyse-Regelwerke auf den zu analysierenden Source Code anzupassen. So können gewissen Fehlinterpretationen durch Anreichern von zusätzlichem Kontext entgegengewirkt werden. Sofern Hersteller von SAST-Werkzeugen auch mit dem Faktor Wahrscheinlichkeit arbeiten, um Funde anzuzeigen, wäre es auch von Nutzen, den Schwellenwert der Wahrscheinlichkeit einzusehen und diesen festlegen zu können. Für die Evaluation des richtigen Werkzeuges sollte somit auch überprüft werden, ob es über die Wahrscheinlichkeit der Richtigkeit eines Alarms informiert. Mit solchen Informationen wäre es dem Benutzer möglich, situationsabhängig einen Schwellenwert einstellen zu können, um sich auf Schwachstellen mit hoher TP-Wahrscheinlichkeit konzentrieren zu können.
User Experience und Vertrauen in ein SAST-Werkzeug
Die Resultate eines SAST-Werkzeugs müssen, obwohl die Überprüfung des Source Codes automatisch durchführt wird, manuell durch einen Benutzer des Werkzeugs verwertet und verifiziert werden. Für die Evaluation einer geeigneten Lösung ist deshalb auch wichtig, den Endbenutzer miteinzubeziehen. Eine Arbeit aus dem Jahr 2015 analysierte die aufkommenden Fragen, welche Entwickler stellten, während sie mit den SAST-Ergebnissen arbeiteten [21]. Ihre Ergebnisse zeigten, dass Werkzeuge immer noch Interpretationsspielraum zulassen und die Erfahrung des Entwicklers die Schlussfolgerung eines Ergebnisses beeinflusste. Die Studie hob hervor, dass primär Werkzeuge von Nutzen für Entwickler sind, welche den Daten- und Kontrollfluss von Source to Sink[6] aufzeigen sowie beleuchten, welche Daten dabei benutzt werden.
In einer Evaluation soll somit die Metrik hinzugezogen, wie gut ein Werkzeug den Entwickler mit solchen Informationen unterstützt. Darüber hinaus erachte ich es als wichtig, den Entwicklern auch Informationen zu den möglichen Gefahren, Kritikalität und den darin involvierten CWE [7] zur Verfügung zu stellen. Des Weiteren sollte das Werkzeug Empfehlungen und weiterführende Quellen zur Verfügung stellen können, wie das gefundene Problem gelöst werden kann. So können fehlenden Erfahrungen entgegengewirkt und die Qualität gesteigert werden.
Multi Language Support
Im Online-Kurs zum Thema Static Analysis and Code Review[8] wird erwähnt, dass die unterschiedlichen Hersteller von SAST-Werkzeugen rasch den Support neuer Programmiersprachen ausbauen, um am Markt einen Vorteil gegenüber der Konkurrenz zu haben [22]. Gemäss dem Autor des Kurses seien die Algorithmen zur Entdeckung von Schwachstellen in einer Programmiersprache jedoch nicht ohne Weiteres auf eine andere anwendbar. Dies führe dazu, dass die Werkzeuge oft in einer Sprache besonders stark sind und in anderen schwächer. Um diese Aussage zu untersuchen, wurden Arbeiten auf Hinweise zur Bestätigung oder Nichtanerkennung dieser gesucht. Eine empirische Studie zur Untersuchung verschiedener SAST-Methodiken erwähnte Folgendes: «It is common knowledge that vulnerable code patterns are difficult to translate across programming languages» [23]. Daher ist anzunehmen, dass ein SAST-Werkzeug in unterschiedlichen Sprachen eine unterschiedliche Genauigkeit aufweisen könnte.
Die zu analysierende Applikation des Auftraggebers wurde in mehreren Programmiersprachen geschrieben. Das Bedürfnis, ein Werkzeug zu benutzen, um alle Teile des Source Codes zu analysieren, ist daher naheliegend. Optimalerweise würde ein zukünftiges Werkzeug alle im Source Code befindlichen Programmiersprachen mit derselben Qualität analysieren können. Wie einleitend erwähnt, führt OWASP mit dem OWASP Benchmark Project[5] ein Projekt, um verschiedene Arten von Application-Security-Testing-Werkzeugen auf ihre Genauigkeit zu überprüfen und die darin entwickelte Methodik scheint nützlich für den Vergleich von SAST-Werkzeugen zu sein [9]. Jedoch wird im OWASP Benchmark Projekt eine Java-Applikation überprüft. Über die Methodik von OWASP kann auch nicht untersucht werden, ob ein SAST-Werkzeug in unterschiedlichen Programmiersprachen dieselbe Genauigkeit aufweist.
Wie bereits einleitend beschrieben, erwähnen auch Shahriar & Zulkernine [12] in ihrer Arbeit, dass es zu erhöhten FP kommen kann, wenn durch fehlenden Kontext nicht genügend klar ist, ob eine Schwachstelle im Code überhaupt erreicht werden kann. Es kann so beispielsweise vorkommen, dass eine Schwachstelle in einer anderen Komponente der Applikation mitigiert wird als in der, in welcher sie auftritt. Erwähnenswert ist in diesem Bezug ein SLR (Systematic Literature Review), welcher 56 Arbeiten mit der Thematik multilingual source code analysis untersuchte und ihre Ergebnisse zusammenfasste [24]. In diesem wurden unterschiedliche Probleme hervorgehoben, wovon eines der fehlende Kontext zwischen den Programmteilen mit unterschiedlicher Programmiersprache ist. Gemäss [24] fokussieren sich Werkzeuge jeweils auf die isolierte Analyse von Programmartefakten einer Programmiersprache, statt sie in Kontext mit Artefakten von anderer Programmiersprache zu setzen.
Es wäre deshalb wichtig, die verschiedenen Programmteile der Applikation über alle involvierten Programmiersprachen hinweg als eine Gesamtapplikation analysieren zu können, um FP oder FN wegen fehlendem Kontext reduzieren zu können. Heute stehen jedoch keine SAST-Werkzeuge zur Verfügung welche dieses Bedürfnis befriedigend lösen.
Standardisierte Performance-Überprüfungen von SAST-Werkzeugen
Um SAST-Werkzeuge auf ihre Genauigkeit zu untersuchen, ergibt es Sinn, ein Vorgehen zur Verfügung zu haben, welches bewährt ist und bereits in der Forschung Verwendung findet. Vorangehend wurde hierzu das OWASP-Benchmark-Projekt erwähnt, welches in Studien bereits zur Anwendung kam [9]. Ein weiteres Projekt, welches meines Erachtens wertvoll ist, ist SAMATE[9] (Software Assurance Metrics And Tool Evaluation) von NIST[10] (National Institute of Standards and Technology). Das SAMATE-Projekt führt regelmässig Studien durch, an welchen Hersteller von SAST-Werkzeugen teilnehmen können, um ihre Analysefähigkeiten ausserhalb von einem wettbewerbsorientierten Rahmen untersuchen zu lassen [25]. Ein Hauptziel der Studie ist, den Herstellern eine Plattform zu bieten, um die Effizienz ihrer Werkzeuge zu steigern. An der letzten, veröffentlichten Studie namens SATE V (Static Analysis Tool Exposition V) haben 14 verschiedene Hersteller teilgenommen [25].
Eine weitere Initiative stammt vom MITRE[11] CWE-Projekt. Mit der CWE CCR (Common Weakness Enumeration Coverage Claims Representation) schafft MITRE ein Werkzeug, mit welchem Hersteller von Schwachstellen Scannern kommunizieren können, welche CWE-IDs sie in welcher Tiefe abdecken [26]. Dies würde erlauben, bereits in der Evaluation erkennen zu können, wo ein gewisses Werkzeug noch Schwächen haben könnte. Leider hat sich in meiner Arbeit jedoch gezeigt, dass CWE CCR noch gänzlich unbekannt ist bei verschiedenen grossen Herstellern.
Abschliessend
In folgendem Blog-Post wurden bestehende Forschungsergebnisse zur Thematik Static Application Security Testing (SAST) zusammengetragen, um eine erste Auslegeordnung zu schaffen. Sie soll interessierten Lesern dienen, sich den Thematiken von SAST aus einer wissenschaftlichen Perspektive anzunähern. Im nächsten Post werde ich auf Alternativen und Ergänzungen zu SAST eingehen und die Themen SCA, DAST, IAST sowie Security Code Reviews beleuchten.
Bei Fragen oder Anregungen freue ich mich auf jeden Kontakt.
Footer-Verzeichnis: (Links und Erklärungen zu Kurzbezeichnungen)
[1] https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
[2] https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/migrated_content
[4] OWASP Top 10: Die OWASP Top 10 ist eine Liste der 10 meist vorkommenden Schwachstellen in untersuchten Web-Applikationen. Sie wird vom Open Web Application Security Project herausgegeben.
[5] OWASP Top Ten Benchmark: Eine Testsuite, um die Genauigkeit, den Umfang und die Geschwindigkeit von SAST-Werkzeugen zu bewerten. https://owasp.org/www-project-benchmark
[6] https://web.archive.org/web/20190612230534/http://flylib.com/books/en/2.809.1.52/1/
[7] CWE: Common Weakness Enumeration ist ein Kategorisierungssystem von möglichen Schwächen in Software und Hardware. https://cwe.mitre.org
[8] https://www.appsecengineer.com/courses-collection/static-analysis-and-code-review-for-devsecops
[9] https://www.nist.gov/itl/ssd/software-quality-group/samate/introduction-samate
Literaturverzeichnis
[1] S. Planning, ‘The economic impacts of inadequate infrastructure for software testing’, Natl. Inst. Stand. Technol., 2002.
[2] SVV, ‘Grundlagenpapier des SVV zu Cyber-Risiken’. Feb. 22, 2018. Accessed: Apr. 01, 2022. [Online]. Available: https://www.svv.ch/sites/default/files/2018-04/Grundlagenpapier%20CyberRisiken_DE.pdf
[3] Microsoft, ‘SDL Process Guidance Version 5.2’. May 23, 2012.
[4] Z. G. Ruthberg, R. G. McKenzie, and others, ‘Audit and Evaluation of Computer Security’, Inst. Comput. Sci. Technol. NBS, 1977.
[5] M. Bishop, E. Sullivan, and M. Ruppel, Computer security: art and science, Second edition. Boston: Addison-Wesley, 2019.
[6] R. W. Shirey, ‘Internet Security Glossary, Version 2’, Internet Engineering Task Force, Request for Comments RFC 4949, Aug. 2007. doi: 10.17487/RFC4949.
[7] S. Berg, C. Lane, M. Whittaker, and others, ‘Glossary of Computer Security Terms, NCSC-TG-004-88’. National Computer Security Center, DoD USA, Oct. 21, 1988.
[8] F. Derek, Application Security Program Handbook. Manning Publications, 2021.
[9] J.-R. Higuera, J. Bermejo, J. A. Montalvo, J. Villalba, and J. Pez, ‘Benchmarking Approach to Compare Web Applications Static Analysis Tools Detecting OWASP Top Ten Security Vulnerabilities’, Comput. Mater. Contin., vol. 64, pp. 1555–1577, Jun. 2020, doi: 10.32604/cmc.2020.010885.
[10] N. Ayewah, D. Hovemeyer, J. Morgenthaler, J. Penix, and W. Pugh, ‘Using Static Analysis to Find Bugs’, Softw. IEEE, vol. 25, pp. 22–29, Oct. 2008, doi: 10.1109/MS.2008.130.
[11] B. Chess and G. McGraw, ‘Static analysis for security’, IEEE Secur. Priv. Mag., vol. 2, no. 6, pp. 76–79, Nov. 2004, doi: 10.1109/MSP.2004.111.
[12] H. Shahriar and M. Zulkernine, ‘Mitigating program security vulnerabilities: Approaches and challenges’, ACM Comput. Surv., vol. 44, no. 3, pp. 1–46, Jun. 2012, doi: 10.1145/2187671.2187673.
[13] M. Nadeem, B. J. Williams, and E. B. Allen, ‘High false positive detection of security vulnerabilities: a case study’, p. 2, Mar. 2012.
[14] T. T. Nguyen, P. Maleehuan, T. Aoki, T. Tomita, and I. Yamada, ‘Reducing False Positives of Static Analysis for SEI CERT C Coding Standard’, in 2019 IEEE/ACM Joint 7th International Workshop on Conducting Empirical Studies in Industry (CESI) and 6th International Workshop on Software Engineering Research and Industrial Practice (SER&IP), Montreal, QC, Canada, May 2019, pp. 41–48. doi: 10.1109/CESSER-IP.2019.00015.
[15] Z. P. Reynolds, A. B. Jayanth, U. Koc, A. A. Porter, R. R. Raje, and J. H. Hill, ‘Identifying and Documenting False Positive Patterns Generated by Static Code Analysis Tools’, in 2017 IEEE/ACM 4th International Workshop on Software Engineering Research and Industrial Practice (SER&IP), Buenos Aires, Argentina, May 2017, pp. 55–61. doi: 10.1109/SER-IP.2017..20.
[16] A. Austin and L. Williams, ‘One technique is not enough: A comparison of vulnerability discovery techniques’, presented at the 2011 5th International Symposium on Empirical Software Engineering and Measurement (ESEM), Banff, AB, Canada, 2011.
[17] N. Antunes and M. Vieira, ‘Assessing and Comparing Vulnerability Detection Tools for Web Services: Benchmarking Approach and Examples’, IEEE Trans. Serv. Comput., vol. 8, no. 2, pp. 269–283, Mar. 2015, doi: 10.1109/TSC.2014.2310221.
[18] L. Conklin, G. Robinson, and E. Keary, ‘OWASP Secure Code Review Guide 2.0’. Jul. 2017.
[19] D. Wichers, E. Worcel, and P. Subramanian, ‘Source Code Analysis Tools | OWASP Foundation’, Nov. 22, 2021. https://owasp.org/www-community/Source_Code_Analysis_Tools (accessed Apr. 18, 2022).
[20] A. Austin and L. Williams, ‘One Technique is Not Enough: A Comparison of Vulnerability Discovery Techniques’, Sep. 2011, pp. 97–106. doi: 10.1109/ESEM.2011.18.
[21] J. Smith, B. Johnson, E. Murphy-Hill, B. Chu, and H. Richter Lipford, ‘Questions developers ask while diagnosing potential security vulnerabilities with static analysis’, Aug. 2015, pp. 248–259. doi: 10.1145/2786805.2786812.
[22] A. Bhargav, Static Analysis and Code Review for DevSecOps Course | AppSecEngineer, (2020). Accessed: Apr. 25, 2022. [Online]. Available: https:/www.appsecengineer.com/courses-collection/static-analysis-and-code-review-for-devsecops
[23] R. Croft, D. Newlands, Z. Chen, and M. A. Babar, ‘An Empirical Study of Rule-Based and Learning-Based Approaches for Static Application Security Testing’, ArXiv210701921 Cs, Jul. 2021
[24] Z. Mushtaq, G. Rasool, and B. Shehzad, ‘Multilingual Source Code Analysis: A Systematic Literature Review’, IEEE Access, pp. 11307–11336, 2017, doi: 10.1109/ACCESS.2017.2710421.
[25] A. Delaitre, B. Stivalet, P. Black, V. Okun, T. Cohen, and A. Ribeiro, ‘SATE V Report: Ten Years of Static Analysis Tool Expositions’. Special Publication (NIST SP), National Institute of Standards and Technology, Gaithersburg, MD, Oct. 23, 2018. doi: https://doi.org/10.6028/NIST.SP.500-326.
Comments