Graudit understøtter flere programmeringssprog og giver dig mulighed for at integrere kodebasesikkerhedstest direkte i udviklingsprocessen.
Kilde:
Test er en vigtig del af softwareudviklingens livscyklus. Der er mange typer test, hver af dem løser sit eget problem. I dag vil jeg tale om at finde sikkerhedsproblemer i kode.
I den moderne realitet inden for softwareudvikling er det naturligvis vigtigt at sikre processikkerhed. På et tidspunkt blev det særlige udtryk DevSecOps endda introduceret. Dette udtryk refererer til en række procedurer, der har til formål at identificere og eliminere sårbarheder i en applikation. Der findes specialiserede open source-løsninger til kontrol af sårbarheder i overensstemmelse med standarder
Der er forskellige tilgange til at løse sikkerhedsproblemer, såsom Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), Software Composition Analysis, og så videre.
Statisk applikationssikkerhedstest identificerer fejl i allerede skrevet kode. Denne tilgang kræver ikke, at applikationen kører, hvorfor den kaldes statisk analyse.
Jeg vil fokusere på statisk kodeanalyse og bruge et simpelt open source-værktøj til at demonstrere alt i praksis.
Hvorfor jeg valgte et open source-værktøj til statisk kodesikkerhedsanalyse
Der er en række grunde til dette: For det første er det gratis, fordi du bruger et værktøj, der er udviklet af et fællesskab af ligesindede, som ønsker at hjælpe andre udviklere. Hvis du har et lille team eller startup, har du en fantastisk mulighed for at spare penge ved at bruge open source-software til at teste sikkerheden i din kodebase. For det andet eliminerer det behovet for, at du skal ansætte et separat DevSecOps-team, hvilket reducerer dine omkostninger yderligere.
Gode open source værktøjer skabes altid under hensyntagen til øgede krav til fleksibilitet. Derfor kan de bruges i næsten alle miljøer og dækker en lang række opgaver. Det er meget nemmere for udviklere at forbinde sådanne værktøjer med det system, de allerede har bygget, mens de arbejder på deres projekter.
Men der kan være tidspunkter, hvor du har brug for en funktion, der ikke er tilgængelig i det værktøj, du vælger. I dette tilfælde har du mulighed for at gafle dens kode og udvikle dit eget værktøj baseret på den med den funktionalitet, du har brug for.
Da udviklingen af open source-software i de fleste tilfælde er aktivt påvirket af fællesskabet, træffes beslutningen om at foretage ændringer ret hurtigt og konkret: Udviklerne af open source-projektet er afhængige af feedback og forslag fra brugere, på deres rapporter om fundet fejl og andre problemer.
Brug af Graudit til kodesikkerhedsanalyse
Du kan bruge forskellige open source-værktøjer til statisk kodeanalyse; der er ikke noget universelt værktøj til alle programmeringssprog. Udviklerne af nogle af dem følger OWASP anbefalinger og forsøger at dække så mange sprog som muligt.
Her vil vi bruge
Der er lignende værktøjer til statisk kodeanalyse - Rough Auditing Tool for Security (RATS), Securitycompass Web Application Analysis Tool (SWAAT), fejlfinder og så videre. Men Graudit er meget fleksibel og har minimale tekniske krav. Du kan dog have problemer, som Graudit ikke kan løse. Så kan du kigge efter andre muligheder her
Vi kan integrere dette værktøj i et specifikt projekt, eller gøre det tilgængeligt for en udvalgt bruger, eller bruge det samtidigt i alle vores projekter. Det er også her, Graudits fleksibilitet kommer i spil. Så lad os klone repoen først:
$ git clone https://github.com/wireghoul/graudit
Lad os nu oprette et symbolsk link, så Graudit kan bruge det i kommandoformat
$ cd ~/bin && mkdir graudit
$ ln --symbolic ~/graudit/graudit ~/bin/graudit
Lad os tilføje et alias til .bashrc (eller hvilken som helst konfigurationsfil du bruger):
#------ .bashrc ------
alias graudit="~/bin/graudit"
Genstart:
$ source ~/.bashrc # OR
$ exex $SHELL
Lad os tjekke, om installationen lykkedes:
$ graudit -h
Hvis du ser noget lignende, så er alt fint.
Jeg vil teste et af mine eksisterende projekter. Før værktøjet køres, skal det bestå en database svarende til det sprog, mit projekt er skrevet på. Databaserne er placeret i mappen ~/gradit/signatures:
$ graudit -d ~/gradit/signatures/js.db
Så jeg testede to js-filer fra mit projekt, og Graudit viste information om sårbarheder i min kode til konsollen:
Du kan prøve at teste dine projekter på samme måde. Du kan se en liste over databaser for forskellige programmeringssprog
Fordele og ulemper ved Graudit
Graudit understøtter mange programmeringssprog. Derfor er den velegnet til en bred vifte af brugere. Det kan i tilstrækkelig grad konkurrere med alle gratis eller betalte analoger. Og det er meget vigtigt, at der stadig sker forbedringer af projektet, og fællesskabet hjælper ikke kun udviklerne, men også andre brugere, der forsøger at finde ud af værktøjet.
Dette er et praktisk værktøj, men indtil videre kan det ikke altid identificere præcist, hvad problemet er med et mistænkeligt stykke kode. Udviklerne fortsætter med at forbedre Graudit.
Men under alle omstændigheder er det nyttigt at være opmærksom på potentielle sikkerhedsproblemer i koden, når du bruger værktøjer som dette.
Start…
I denne artikel så jeg på blot én af mange måder at finde sårbarheder på – statisk applikationssikkerhedstest. Det er nemt at udføre statisk kodeanalyse, men det er kun begyndelsen. For at lære mere om sikkerheden i din kodebase skal du integrere andre typer test i din softwareudviklings livscyklus.
Om reklamernes rettigheder
Kilde: www.habr.com