Statisk applikationssäkerhetstestning

Statisk applikationssäkerhetstestning (SAST) används för att säkra programvara genom att granska programvarans källkod för att identifiera källor till sårbarheter. Även om processen att statiskt analysera källkoden har funnits så länge som datorer har funnits, spred sig tekniken till säkerhet i slutet av 90-talet och den första offentliga diskussionen om SQL-injektion 1998 när webbapplikationer integrerade ny teknik som JavaScript och Flash .

Till skillnad från verktyg för dynamisk applikationssäkerhetstestning (DAST) för black-box-testning av applikationsfunktionalitet, fokuserar SAST-verktyg på applikationens kodinnehåll, white-box-testning . Ett SAST-verktyg skannar källkoden för applikationer och dess komponenter för att identifiera potentiella säkerhetsbrister i deras programvara och arkitektur. Statiska analysverktyg kan upptäcka uppskattningsvis 50 % av befintliga säkerhetsbrister.

I SDLC utförs SAST tidigt i utvecklingsprocessen och på kodnivå, och även när alla delar av kod och komponenter sätts ihop i en konsekvent testmiljö. SAST används också för kvalitetssäkring av programvara. även om de många resulterande falska positiva hindrar dess antagande av utvecklare

SAST-verktyg är integrerade i utvecklingsprocessen för att hjälpa utvecklingsteam eftersom de i första hand fokuserar på att utveckla och leverera mjukvara som respekterar begärda specifikationer. SAST-verktyg, liksom andra säkerhetsverktyg, fokuserar på att minska risken för stillestånd av applikationer eller att privat information som lagras i applikationer inte äventyras.

För år 2018 visar Privacy Rights Clearinghouse-databasen att mer än 612 miljoner poster har äventyrats av hackning.

Översikt

Applikationssäkerhetstester av applikationer som släpps: statisk applikationssäkerhetstestning (SAST), dynamisk applikationssäkerhetstestning (DAST) och interaktiv applikationssäkerhetstestning (IAST), en kombination av de två.

Statiska analysverktyg undersöker texten i ett program syntaktisk. De letar efter en fast uppsättning mönster eller regler i källkoden. Teoretiskt kan de också undersöka en sammanställd form av programvaran. Denna teknik bygger på instrumentering av koden för att göra mappningen mellan kompilerade komponenter och källkodskomponenter för att identifiera problem. Statisk analys kan göras manuellt som en kodgranskning eller revision av koden för olika ändamål, inklusive säkerhet, men det är tidskrävande.

Precisionen för SAST-verktyget bestäms av dess analysomfång och de specifika tekniker som används för att identifiera sårbarheter. Olika nivåer av analys inkluderar:

funktionsnivå - instruktionssekvenser.
fil eller klassnivå - en utökbar programkodmall för att skapa objekt.
applikationsnivå - ett program eller en grupp av program som interagerar.

Analysens omfattning avgör dess noggrannhet och förmåga att upptäcka sårbarheter med hjälp av kontextuell information.

På en funktionsnivå är en vanlig teknik konstruktionen av ett abstrakt syntaxträd för att styra dataflödet i funktionen.

Sedan slutet av 90-talet har behovet av att anpassa sig till affärsutmaningar förändrat mjukvaruutveckling med komponentisering. upprätthålls av processer och organisation av utvecklingsteam Att följa dataflödet mellan alla komponenter i en applikation eller en grupp av applikationer möjliggör validering av nödvändiga anrop till dedikerade procedurer för sanering och att korrekta åtgärder vidtas för att smutskasta data i specifika delar av kod.

Ökningen av webbapplikationer innebar att man testade dem: Verizon Data Breach rapporterar 2016 att 40 % av alla dataintrång använder sårbarheter i webbapplikationer. Förutom externa säkerhetsvalideringar ökar fokus på interna hot. Clearswift Insider Threat Index (CITI) har rapporterat att 92 % av deras svarande i en undersökning från 2015 sa att de hade upplevt IT- eller säkerhetsincidenter under de senaste 12 månaderna och att 74 % av dessa intrång kom från insiders. Lee Hadlington kategoriserade interna hot i 3 kategorier: skadlig, oavsiktlig och oavsiktlig. Mobilapplikationers explosiva tillväxt innebär att applikationer säkras tidigare i utvecklingsprocessen för att minska skadlig kodutveckling.

SAST styrkor

Ju tidigare en sårbarhet åtgärdas i SDLC, desto billigare är det att åtgärda. Kostnaderna att fixa i utvecklingen är 10 gånger lägre än vid testning och 100 gånger lägre än i produktionen. SAST-verktyg körs automatiskt, antingen på kodnivå eller applikationsnivå och kräver ingen interaktion. När de integreras i en CI/CD-kontext kan SAST-verktyg användas för att automatiskt stoppa integrationsprocessen om kritiska sårbarheter identifieras.

Eftersom verktyget skannar hela källkoden kan det täcka 100 % av det, medan dynamiska applikationssäkerhetstestningar täcker dess exekvering som eventuellt saknar en del av applikationen, eller osäkrad konfiguration i konfigurationsfiler.

SAST-verktyg kan erbjuda utökade funktioner som kvalitet och arkitektonisk testning. Det finns ett direkt samband mellan kvalitet och säkerhet. Programvara av dålig kvalitet är också dåligt säkrad programvara.

SAST svagheter

Även om utvecklare är positiva till användningen av SAST-verktyg, finns det olika utmaningar för utvecklarnas antagande av SAST-verktyg.

Med agila processer inom mjukvaruutveckling genererar tidig integration av SAST många buggar, eftersom utvecklare som använder detta ramverk fokuserar först på funktioner och leverans.

Att skanna många rader kod med SAST-verktyg kan resultera i hundratals eller tusentals sårbarhetsvarningar för en enda applikation. Det genererar många falska positiva resultat, vilket ökar utredningstiden och minskar förtroendet för sådana verktyg. Detta är särskilt fallet när sammanhanget för sårbarheten inte kan fångas upp av verktyget

Se även