Codekwaliteit
- Inleiding
- SonarSource
- Java
- SonarQube Server
- SonarQube Scanner
- SonarQube IDE (SonarLint)
- OWASP Dependency Check
- Slot
Inleiding
Codekwaliteit omvat diverse aandachtsgebieden voor wat betreft je code. Aandachtsgebieden zijn bijvoorbeeld leesbaarheid, herbruikbaarheid, betrouwbaarheid, onderhoudbaarheid en efficiëntie. De kwaliteit van de code zou met dit alles verbeterd kunnen worden.
Een hogere kwaliteit van code zal op de korte termijn geen meerwaarde tonen waardoor veel personen en organisaties er niet eens aan willen beginnen (alles doet het toch? so who cares?).
Op de lange termijn zal het wel zijn vruchten afwerpen omdat met een hoge kwaliteit van code je programmatuur gemakkelijker uitgebreid kan worden. Ook zullen, met een hogere kwaliteit van code, bugs minder tot niet optreden en kunnen bugs sneller opgelost worden als ze optreden. Verder kan de samenwerking met andere ontwikkelaars (voor zover je met anderen wil/kan samenwerken) met een hogere kwaliteit van code productiever worden.
Het kan interessant zijn om erachter te komen wat je code scoort qua codekwaliteit en of de code mogelijke kwetsbaarheden bevat en of er aanbevelingen gedaan kunnen worden om je code te verbeteren. Voor dat soort dingen zijn er de tools van SonarSource en de OWASP Dependency-Check-tool en meer over die tools in deze post.
SonarSource
SonarSource is een bedrijf dat open source software maakt waarmee codekwaliteit gemanaged kan worden. Het idee is dat de code wordt gescand en mogelijke issues vooraf gedetecteerd worden. De scan geeft diverse aanbevelingen om bugs te voorkomen en om de kwaliteit van je code te verbeteren. SonarSource heeft een aantal producten en we gaan het in deze post hebben over SonarQube Server, SonarQube Scanner en SonarQube IDE (voorheen SonarLint).
De SonarSource producten maken gebruik van Java en Java moet dan ook aanwezig zijn op het apparaat waarop je de SonarSource producten wilt laten draaien. SonarQube Server kan op een server draaien of gewoon op je lokale PC waarbij in het geval van een lokale PC de lokale PC voor SonarQube Server de server is. Voor deze post installeren we alles op een lokale PC met Windows 10.
SonarQube Server zorgt o.a. voor het doen opslaan en het doen bijwerken van rules in een database en het beschikbaar stellen van die rules naar de SonarQube Scanner. Beheerzaken zoals het disablen van sommige rules omdat je die niet van belang vindt voor je scan en het configureren van de database waarin het één en ander wordt opgeslagen, dat gebeurt allemaal via SonarQube Server.
Het scannen van je code gebeurt door de SonarQube Scanner die gebruikt maakt van de rules die beschikbaar zijn gesteld door de SonarQube Server. Het resultaat van een scan wordt door SonarQube Scanner naar SonarQube Server gestuurd.
SonarQube Server maakt met de gegevens van de scan een mooi rapport met allerlei “metrics” en wat al niet meer. Ook zorgt SonarQube Server ervoor dat het rapport wordt opgeslagen zodat je het rapport kan inzien en/of kan verwijderen als je het rapport niet meer nodig hebt.
Het één en ander wordt opgeslagen in een database. Diverse database formaten worden door SonarSource ondersteund. Gekozen kan worden voor bijvoorbeeld PostgreSQL of Oracle, maar er kan ook gekozen worden voor Microsoft’s SQLServer. Voor de Community Build evaluatie versie wordt default een H2-database aangemaakt op de lokale harde schijf van het apparaat waarop de SonarQube-producten worden geïnstalleerd.
SonarQube IDE (voorheen SonarLint) is een plugin dat gebruikt kan worden in IDEs (Integrated Development Environments) zoals Visual Studio. De plugin detecteert de code tijdens het schrijven van de code (als een soort spellingscontrole).
Java
Op het moment van dit schrijven is volgens de website van SonarSource Java versie 17 vereist voor SonarQube Server (Community Build-versie). Ook voor SonarQube IDE (voorheen SonarLint) is Java versie 17 vereist. Voor de SonarQube Scanners zijn Java versie 11 of 17 nodig.
Java is dus vereist op het apparaat waarop de producten van SonarSource mogen draaien en we installeren Java versie 17 op onze lokale PC daar we SonarSource producten op onze lokale PC willen hebben. We gaan voor de installatie van Java naar de website van Oracle en we downloaden de Windows x64 MSI Installer.
We installeren met de MSI Installer Java 17:
Java 17 is na de installatie aanwezig in (default) folder C:\Program Files\Java\jdk-17. We voegen bij de Path-Environment-variabele folder C:\Program Files\Java\jdk-17\bin toe aan de lijst van eerder opgegeven folders:
We maken ook een JAVA_HOME-Environment-variabele aan daar Java die nodig heeft:
En Java is geïnstalleerd wat we als volgt kunnen zien:
SonarQube Server
In de vorige paragraaf hebben we Java geïnstalleerd op het apparaat waarop we de SonarSource-producten willen hebben. Eén van de eerste randvoorwaarden voor het doen draaien van SonarSource-producten is daarmee vervuld en nu is het SonarQube Server waarop we ons kunnen richten.
We gaan daarvoor naar de website van SonarSource voor het doen downloaden van SonarQube Server. We kiezen in deze post voor de installatie van de Community Build waarvoor we het desbetreffende .zip-bestand downloaden:
We unzippen het .zip-bestand naar folder C:\Sonar\Server. In die folder vinden we een bin\windows-x86-64 sub-folder met daarin .bat-file StartSonar.bat. Dit .bat-bestand hebben we nodig voor de SonarSource-applicaties:
We voegen bij de Path-Environment-variabele folder C:\Sonar\Server\bin\windows-x86-64 toe aan de lijst van eerder opgegeven folders (in de vorige paragraaf hadden we voor de installatie van Java folder C:\Program Files\Java\jdk-17\bin toegevoegd):
We openen een CMD Command Prompt-venster en we gaan naar folder C:\Sonar\Server\bin\windows-x86-64 in welke we StartSonar.bat starten:
En we hebben SonarQube opgestart. Als je met SonarQube Server en SonarQube Scanner aan de gang gaat dan moet de desbetreffende CMD Command Prompt-venster open blijven. De CMD Command Prompt-venster kan je sluiten zodra je klaar bent met de SonarSource-applicaties.
Je kunt SonarQube Server opstarten zodra SonarQube operationeel is. Het opstarten van SonarQube Server gaat via de 9000-poort van je localhost:
http://localhost:9000
En een inlogscherm verschijnt waarmee je op SonarQube Server kunt inloggen:
De login is admin en het Password is ook admin bij het voor de eerste keer inloggen. SonarQube Server zal dan vragen of je een ander wachtwoord kunt invoeren. Verder wordt ook de vraag gesteld welke modus je wilt gebruiken. We gebruiken in deze post de Multi-Quality Rule (MQR)-modus, maar dat kun je achteraf altijd bij de settings veranderen.
In deze post gaat het om een evaluatie met een gratis Community Build en we gebruiken voor alles de admin-user. De admin-user heeft out-of-the-box niet alle rechten en we passen dit aan bij Administration > Security > Global Permissions. We kennen als volgt de rechten toe aan de admin-user:
We hebben SonarQube Server aan de praat gekregen en we kunnen aan de gang met SonarQube Scanner.
SonarQube Scanner
De volgende stappen voor het scannen van je code:
Creëer een project
Het scanproces begint vanuit SonarQube Server met de creatie van een nieuw project. We creëren een lokaal project:
We geven het project een naam (in dit voorbeeld MRA_WebAPI01) en een waarde voor de project key zodat daarmee een token gegenereerd kan worden:
We gebruiken de global setting:
We geven bij de Analysis Method op dat onze repository ergens “locally” aanwezig is (bijvoorbeeld op de lokale harde schijf van de PC in kwestie):
Je gaat een token voor je project genereren:
Schrijf of sla de waarde van de gegenereerde token ergens op daar je die later nodig zult hebben:
Je aangemaakte project vind je terug in SonarQube Server:
De vraag wordt vervolgens gesteld wat er precies gescand moet worden voor je project. Het gaat in dit geval om een .NET-solution en SonarQube Server komt met aanwijzingen wat voor je scan geïnstalleerd en gedraaid moet worden:
Een project is aangemaakt en de instructies van SonarQube Server gaan we navolgen voor de scan van je code.
Installeer de scanner
Eén van de instructies van SonarQube Server is dat we de .NET Core Global Tool nodig hebben voor de scan. We gaan naar de site van SonarSource voor de download van die tool.
Geen download in het geval van de .NET Core Global Tool, maar een installatie met dotnet.exe dat deel uitmaakt van de .NET Core CLI:
En we installeren als volgt de .NET Core Global Tool met de dotnet.exe-tool:
De van toepassing zijnde SonarQube Scanner is geïnstalleerd en we kunnen onze .NET-solution scannen.
Doe de scan
We openen een CMD Command Prompt-venster en we voeren daarbinnen de instructies uit zoals aangegeven door SonarQube Server. De te scannen .NET solution/project staat in dit voorbeeld in folder C:\Blog\Csharp12\WASM en de “begin”-commando ziet er als volgt uit:
dotnet sonarscanner begin
/k:"MRA_WebAPI01"
/d:sonar.host.url="http://localhost:9000"
/d:sonar.token=
"... geef de token op
die je hebt gegenereerd
bij de aanmaak van je project ..."
We gaan naar folder C:\Blog\Csharp12\WASM en we voeren de “begin”-commando uit:
De volgende stap is dat binnen dezelfde CMD Command Prompt-venster voor de desbetreffende .NET solution/project met de dotnet.exe-tool een build wordt gemaakt:
dotnet build
En we doen als laatste stap in de CMD Command Prompt-venster de “end”-commando om het één en ander af sluiten en om de gegevens van de scan naar SonarQube Server te sturen. De “end”-commando ziet er als volgt uit:
dotnet sonarscanner end
/d:sonar.token=
".. geef de token op
die je hebt gegenereerd
bij de aanmaak van je project..."
En we voeren de “end”-commando uit:
De scan is gedaan en een rapport is aanwezig in SonarQube Server:
We zoomen in op het rapport en we zien dat onze gescande code voldoet aan de Quality Gate en dat we “geslaagd” (Passed) zijn voor de gedane scan/test. Het rapport komt in dit voorbeeld wel met 20 aanbevelingen waarmee we de onderhoudbaarheid (Maintainability) van onze code kunnen verbeteren:
Bijvoorbeeld dat al deze if-statements te complex zijn en “gerefactored” mogen worden naar iets wat beter te begrijpen is:
En SonarQube hebt zijn zegje gedaan. Gaan we er wat mee doen of is dat allemaal te ver gezocht waarbij SonarQube verder zijn kop moet houden?
SonarQube IDE (SonarLint)
Het kan zijn dat je graag wil dat tijdens het schrijven van je code je door SonarQube op verschillende dingen wordt geattendeerd.
Voor deze behoefte heeft SonarSource de SonarQube IDE (voorheen SonarLint). SonarQube IDE is een plugin dat gebruikt kan worden in IDEs (Integrated Development Environments) zoals Visual Studio. De plugin detecteert de code tijdens het schrijven van de code als een soort spellingscontrole.
We gebruiken in ons voorbeeld Visual Studio als IDE en we installeren in Visual Studo de SonarQube IDE. We gaan daarvoor naar de extensions:
En we zoeken naar de SonarQube IDE extension. De extensie kan ook gevonden worden met de oude naam (SonarLint):
Een VSIX Installer gaat de installatie van de extension doen waarbij Visual Studio na de installatie opnieuw opgestart moet worden:
En we zien dat de SonarQube IDE extension actief is:
Wat tot uiting komt in allerlei Warnings in de IDE (in dit geval Visual Studio). De waarschuwingen uit de SonarQube IDE beginnen allemaal met een “S“:
En we hebben er een assistent/kwelgeest bij die ons assisteert/lastig valt bij het schrijven van onze code.
OWASP Dependency Check
OWASP Dependency Check is een tool dat scant op kwetsbaarheden in third party libraries welke gebruikt worden door een software applicatie. De tool doet dat door o.a. gebruik te maken van de National Vulnerability Database (NVD) die onderhouden wordt door de US National Institute of Standards and Technology (NIST).
We gaan voor de tool naar de desbetreffende GitHub-repository:
En we downloaden het .zip-bestand dat op het moment van dit schrijven de recentste versie is.
We unzippen het .zip-bestand naar folder C:\Sonar\OWASP\dependency-check. In die folder vinden we een bin-sub-folder met daarin .bat-file dependency-check.bat. Dit .bat-bestand hebben we uiteindelijk nodig voor het doen van de scan.
We openen een CMD Command Prompt-venster en we gaan naar folder C:\Sonar\OWASP\dependency-checkdependency-check.batC:\Blog\Csharp12\WebAPI.
dependency-check.bat
--scan C:\Blog\CSharp12\WebAPI
De OWASP Dependency Check tool gaat eerst controleren op updates zodat ze met de recentste gegevens aan de slag kan:
Vervolgens wordt begonnen met het daadwerkelijk scannen en het resultaat wordt (default) in bestand dependency-check-report.html gezet:
Het rapport zou kunnen aangeven dat je binnen je software applicatie gebruik maakt van een third party library dat een kwetsbaarheid bevat. De meeste leveranciers houden hun libraries goed up-to-date en eventuele kwetsbaarheden zijn meestal opgelost in een recentere versie van die third party library.
Slot
In deze post hebben we het gehad over Codekwaliteit en tools die een bijdrage kunnen leveren aan het verbeteren van de kwaliteit van je code en het doen opsporen van kwetsbaarheden in je code. We hebben de tools van SonarSource en de OWASP Dependency-Check-tool de revue laten doen passeren. Alle tools slaan hun bevindingen op in een rapport die je na de scan kan inzien. Voor deze post hebben we alles op een lokale PC met Windows 10 geïnstalleerd en een scan gedaan op een .NET solution/project die lokaal op die PC aanwezig is.
Een hogere kwaliteit van code zal op de korte termijn geen meerwaarde tonen waardoor veel personen en organisaties er niet eens aan willen beginnen (alles doet het toch? so who cares?). Op de lange termijn zal het wel zijn vruchten afwerpen doordat met een hoge kwaliteit van code je programmatuur gemakkelijker uitgebreid kan worden. Ook zullen, met een hogere kwaliteit van code, bugs minder tot niet optreden en kunnen bugs sneller opgelost worden als ze optreden. Verder kan de samenwerking met andere ontwikkelaars (voor zover je met anderen wil/kan samenwerken) met een hogere kwaliteit van code productiever worden.
De grote vraag is wat we met de bevindingen van de tools doen. Disablen we alle rules zodat er geen waarschuwingen en bevindingen meer komen om van het gezeur af te zijn? Of gaan we serieus naar de bevindingen kijken? Ik zou pleiten voor de gulden middenweg. Kijk serieus naar de bevindingen, maar het is aan jou om ze over te nemen want de codeer standaarden en de kwaliteitscriteria van SonarSource hoeven niet de jouwe te zijn.
Hopelijk ben je met deze posting weer wat wijzer geworden en ik hoop je weer terug te zien in één van mijn volgende blog posts. Klik op de Home-button om te zien wat ik nog meer geschreven heb…