Wordt het tijd om eens een nieuwe SAST-tool te proberen?

Het volledige rapport is hier te vinden.

Kwetsbaarheden in software zijn een veelvoorkomende manier voor aanvallers om systemen binnen te dringen. Het NCSC publiceert daarom voortdurend informatie over dergelijke kwetsbaarheden, in de vorm van advisories. Op basis hiervan kunnen organisaties nagaan of zij de betreffende software gebruiken en passende maatregelen treffen.  Daarnaast beperkt het NCSC de schade van kwetsbaarheden door advies te geven over veilige softwareontwikkeling. Zo publiceren we richtlijnen, en hebben we onderzoek laten uitvoeren naar threat modelling.

Wat is statische analyse?

Statische analyse is het testen van software zonder die daadwerkelijk te draaien. Dit gebeurt tijdens de implementatiefase van het softwareontwikkelingsproces. Het onderscheidt zich van dynamische analyse, zoals fuzzing, waarbij de software juist wel uitgevoerd wordt.

Statische analyse biedt verschillende voordelen ten opzichte van andere testmethoden. Zo detecteert het kwetsbaarheden vroeg in het ontwikkelproces, is de codedekking doorgaans relatief uitgebreid, en integreert het natuurlijk in het CI/CD-proces. Daarnaast wordt statische analyse meestal onderscheiden van software composition analysis, dat zich specifiek richt op de afhankelijkheden van de geteste software. Een veelgebruikte tool voor statische analyse is bijvoorbeeld SonarQube.

Nieuwe ontwikkelingen in statische analyse

Hoewel statische analyse al heel lang bestaat, blijft het volop in ontwikkeling. Er komen voortdurend nieuwe tools beschikbaar, en bestaande tools worden steeds geavanceerder. Het is een domein waarin academische ontwikkelingen hun weg weten te vinden naar de praktijk. Zo zijn meerdere hedendaags populaire tools ontstaan uit spin-offs van universiteiten.

De centrale vraag van mijn onderzoek luidt: hoe kunnen Nederlandse organisaties profiteren van nieuwe ontwikkelingen in statische analyse? Om deze vraag te beantwoorden heb ik een literatuurstudie gedaan en een enquête gehouden onder de doelgroepen van het NCSC. In deze eerste van twee expertblogs bespreek ik de resultaten van de literatuurstudie.

Toolselectie

Aangezien er te veel SAST-tools bestaan om ze allemaal handmatig te bestuderen, heb ik een selectie uit deze lijst gemaakt op basis van de volgende criteria:

• Ondersteuning van meer dan slechts één populaire programmeertaal
• Detectie van meer dan alleen stijl- en structuurproblemen of afhankelijkheden
• Gebaseerd op nieuwe inzichten
• Populariteit, gemeten naar het aantal sterren op GitHub
• Transparante analysemethoden

Hier zijn drie tools uitgekomen die ik nader heb bestudeerd: CodeQL, Infer, en Semgrep. Deze heb ik op basis van wetenschappelijke literatuur met elkaar vergeleken en afgezet tegen de meer gevestigde tool SonarQube.

De geselecteerde tools

Voordat ik de vergelijking induik, volgt hier een korte toelichting op de drie geselecteerde nieuwe tools.

CodeQL. Het kernidee van CodeQL is om broncode te beschouwen als data, die vervolgens via een querytaal kan worden bevraagd. Er zijn veel openbare regels beschikbaar, geschreven in deze querytaal, waarmee CodeQL volledig automatisch kan worden ingezet als SAST-tool.

Daarnaast is het mogelijk om eigen regels te schrijven en zelfs om CodeQL te gebruiken bij het pentesten. CodeQL is ontstaan uit onderzoek aan de Universiteit van Oxford en via een spin-off uiteindelijk onderdeel is geworden van GitHub, dat weer onderdeel is van Microsoft.

CodeQL is gratis voor open source software en tegen betaling beschikbaar voor commerciële software. Het is geïntegreerd in het cloudplatform van GitHub, maar ook beschikbaar als losstaande CLI-tool.

Infer. Infer is gebaseerd op een formele logica die redeneert over het geheugen van een computerprogramma. Hierdoor is het vooral geschikt om kwetsbaarheden op te sporen die voortkomen uit verkeerd geheugengebruik.

Net als CodeQL vindt Infer zijn oorsprong in academisch onderzoek, dat via een spin-off op de markt is gebracht. Deze spin-off is overgenomen door Facebook, waar Infer verder wordt ontwikkeld. Infer is open source en gratis te gebruiken.

Semgrep. Semgrep is, net als CodeQL, een query-gebaseerde SAST-tool. Dit betekent dat de detectieregels grotendeels losstaan van de engine die deze regels uitvoert. De regels worden geschreven in een relatief eenvoudige YAML-syntax. De engine maakt gebruik van patroonherkenning, vergelijkbaar met de populaire tool grep, maar verfijnt deze door semantische informatie over het programma te betrekken.

Semgrep is voortgekomen uit een eerdere tool van Facebook, maar wordt tegenwoordig ontwikkeld door een onafhankelijk bedrijf. Er is een gratis open source versie beschikbaar en een commerciële variant met extra functionaliteit. Semgrep is geïntegreerd in het cloudplatform van GitLab, maar ook beschikbaar als losstaande CLI-tool.

De vergelijking

Er zijn meerdere recente wetenschappelijke studies waarin SAST-tools zijn geëvalueerd door ze te testen op een aantal programma’s met bekende kwetsbaarheden. Soms zijn dit kunstmatig gecreëerde programma’s, waarin handmatig kwetsbaarheden zijn ingebouwd. Andere onderzoeken werken met echte programma’s,  bijvoorbeeld oudere versies van open source programma’s met bekende kwetsbaarheden.

De meeste onderzoeken vergelijken tussen de 5 á 10 verschillende tools. Voor mijn literatuuronderzoek heb ik alleen onderzoeken geselecteerd waarin minstens twee van de vier eerder genoemde tools (SonarQube, CodeQL, Infer, Semgrep) zijn meegenomen.
Op basis van deze artikelen, trek ik de volgende conclusies:

• Infer detecteert een nauwere selectie aan CWE’s dan SonarQube, maar is daarin wel accurater.
• Voor security-gerelateerde bugs, zijn Semgrep OSS en CodeQL accurater dan SonarQube.
• SonarQube presteert beter dan de nieuwere tools als het gaat om algemene codekwaliteitsproblemen (zoals code smells en onderhoudbaarheid).
• CodeQL is over het algemeen iets accurater dan Semgrep OSS.
• SonarQube is sneller dan zowel CodeQL als Semgrep OSS.
• Op kleinere projecten zijn CodeQL en Infer sneller dan Semgrep OSS; bij grotere projecten is Semgrep OSS juist sneller.

Ervaringen ontwikkelaars

De bovenstaande onderzoeken vergelijken SAST-tools voornamelijk op harde criteria zoals accuraatheid en snelheid. Om echter goed te begrijpen hoe Nederlandse organisaties van de nieuwe tools kunnen profiteren, is het van belang om ook te kijken naar de praktische obstakels die ontwikkelaars ervaren bij het gebruik van deze tools. Vervolgens kan worden beoordeeld in hoeverre de nieuwe tools deze obstakels adresseren.

Op basis van Nachtigall et al. (2022) en Wadhams et al. (2024) heb ik de volgende vijf kernobstakels geïdentificeerd:

1. Te veel foutpositieven

2. Onvoldoende informatieve meldingen

3. Gebrek aan hulp bij het oplossen van meldingen

4. Onvoldoende workflowintegratie

5. Beperkte incorporatie van gebruikersfeedback

Deze obstakels heb ik onderverdeeld in subobstakels. Voor elk subobstakel heb ik handmatig beoordeeld in hoeverre de drie nieuwe tools (CodeQL, Infer en Semgrep OSS) dit probleem aanpakken. Zie onderstaande tabel voor een volledig overzicht, waarbij de beoordeling al volgt is gecodeerd:

• (-) niet geadresseerd
• (±) gedeeltelijk geadresseerd
• (+) volledig geadresseerd

Hoewel de nieuwe tools veel van de bekende obstakels geheel of gedeeltelijk adresseren, is er nog ruimte voor verbetering. De toepassingen die nog het minst worden ondersteund, zijn: het toekennen van een betrouwbaarheidsscore aan een melding, het prioriteren van de meldingen, en het meenemen van gebruikersfeedback over echtpositieven.

Conclusies en aanbevelingen

Op basis van de literatuurstudie lijken de nieuwe SAST-tools op verschillende gebieden beter te presteren dan de gevestigde referentietool. Dit is een goede reden voor organisaties om met nieuwe tools te experimenteren. Met name query-gebaseerde tools, die het mogelijk maken om je eigen regels te schrijven, bieden voordelen.

Dit soort tools zijn aanpasbaar aan de specifieke context van een organisatie en maken het mogelijk om snel regels toe te voegen wanneer er een nieuw type kwetsbaarheid wordt ontdekt. Bij gebruik van dit soort tools kan het de moeite waard zijn om in-house kennis te ontwikkelen over het schrijven van eigen detectieregels.

Tot slot blijkt uit verschillende onderzoeken dat SAST-tools elkaar complementeren: de ene tool detecteert kwetsbaarheden die door de andere tool over het hoofd worden gezien, en vice versa. Het kan daarom de moeite waard zijn om meerdere tools te gebruiken, of een dienst die een combinatie van meerdere tools aanbiedt.

In de volgende expertblog ga ik in op de resultaten van de survey die ik heb uitgevoerd. Die geven een indruk van welke SAST-tools er in Nederland het meest worden gebruikt, en hoe de ervaringen daarmee verschillen tussen sectoren. Nu al meer weten? Kijk dan vooral naar het volledige rapport.