SAST vs DAST vs IAST: Säkerhetstest för komplementariteter av de tre bröderna, inte ersättning

De tre vanligaste förkortningarna i applikationssäkerhetstesten är SAST, DAST, IAST. Många människors första reaktion var att "välja en av de starkaste", men det var en hycklande proposition - de tre bröderna konkurrerade inte, men såg samma fråga ur olika perspektiv. Valet beror inte på vem som är mer avancerad, men på scenen du befinner dig i mjukvarulivscykeln, vilken typ av kryphål du vill hitta och hur mycket du kan bära.

Översikt över tillämpningen av de tre metoderna för säkerhetstestning

I. FÖRSLAG OM FÖRSTA FÖRSLAG

SAST (statiskt applikationssäkerhetstest)Övrig organisatörKör inte programmetUnder vilken skanningskällkoden/bytekoden hittar ett kryphål, som tillhör den vita lådan.
DASTÖvrig organisatörRunning programExterna lanseringsförfrågningar, simulerade attacker är "svarta lådor" och ingen källkod krävs.
IAST (Interactive Application Safety Test)Övrig organisatörKör program inifrånPlug-in (agent), i kombination med flödes- och kodkontext, hör till Grey Box.

Nyckeln till att förstå dessa tre är att de svarar på olika frågor: SAST frågar, "Var kan det finnas ett misstag i koden?" DAST frågar, "Kan vi faktiskt komma igenom när du kör?" IAST frågar, "I denna operation, vilken dataströmmen verkligen flyter till faran."

SAST: Främja problemet vid kodskrivningsstadiet

SAST analyserar direkt källkoden (eller sammanställer mellanprodukter) och utför inte programmet. Fördelen är att kunna upptäcka problem i ett tidigt skede, eller till och med när koden lämnas in, för att hitta specifika dokument och radnummer, med låga reparationskostnader. Den täcker "koderna kan sopas" och beror inte på körtidsmiljön.

ShortboardFelhastigheten är vanligtvis hög eftersom den inte avgör om ett visst antal koder kommer att utlösas i den verkliga verksamheten; de problem som exponeras endast när du kör (t.ex. konfigurationsfel, försäkran kringgår, faktiska samtalskedjan för att förlita sig på biblioteket) inte är helt sedda; källkoden behövs och tredjeparts stängd källkomponent är inte funktionell.

Typiskt scenario: CI streaming linje kod inlämning dörrar är stängda för att förhindra synlig injektion, hårdkodning nyckel, fara funktion samtal i ryggraden.

DAST: Verifiera "Fungerar det verkligen?"

DAST använder målet som en svart låda för att skicka förfrågningar från utsidan, konstruera anfallsbelastningar och observera svar. Det största värdet är...Nära en riktig attack.Problemet med "riktig tillgång till löpning" hittades, med relativt låg underrapportering. Ingen källkod krävs, så tredjepartskomponenter, konfigurationsskikt kan också täckas.

ShortboardDet är ofta bara tills utplaceringen av detektering av sen upptäckt och reparationskostnaden är hög; täckningen är begränsad till reptiler och testrutter som kan nås genom exempel, utan att detektera icke-detekterbara funktionella punkter; Det är svårt att lokalisera källkoden exakt, och utveckling och rapportering är ofta bara känd "som URL är problematisk"; och konfigurationskostnaderna är höga för scenarier som kräver inloggning, flerstegs affärsprocesser.

Typiskt scenario: säkerhetsclearance innan du går online, periodisk skanning av utplacerade miljöer.

IV. IAST: Run-time plugs, balansera sammanhang med verkliga dataflöden

IAST observerar också kodutförande och externt flöde när programmet körs genom att implantera antent i programmet. Det kan se hur förfrågningar kommer in och hur data strömmar in i koden, så det kan ges.Ta fullständiga bevis på värdshuset.Det är vanligtvis lägre än SAST och det är korrekt.

ShortboardBehovet av att kunna distribuera sonder i målmiljön (på grund av oro över produktionsmiljön); beroende på provtäckning, som inte kan hittas utan att koden genomförs, som ofta är knuten till funktionell / automatiserad testning; skillnader i språk och ramstöd; och vissa prestationskostnader.

Typiskt scenario: körs i testmiljön i samband med automatiserad testning, både för att validera funktionalitet och synkronisera utgångssäkerhetsslutsatser.

Titta på dataflöde och ring stack från insidan kod

5, tre mot en.

Dimensioner	Säkert	DAST	IAST
Testobjekt	Källa/byte (inte igång)	Aktivt mål (externt)	Operativa applikationer (interna kontakter)
Perspektiv	Vit låda	Black Box	Grey Box
Tid för intervention	Kodning/submissionsfas tidigast	Efter utplacering	Test/Run-time
Behöver källkod	Ja.	Inget behov.	Krav (kan anslutas)
Misreporterad nivå	Hög	Låg	Lägre
Position precision	För fil/line	För URL / Interface	Att ringa Inn / Data Stream
Överskridande beroende	Begränsad (se källkodsdel)	Override exponering när du kör	Begränsad av avrättningsväg
Typisk scen	CI Code Door Ban	Kontrollera och acceptera innan du går online.	Kombinerat med automatiserad testning

VI. Varför komplementaritet snarare än substitution

Om du sätter ihop de tre finner de att deras blinda zoner är komplementära:

SAST ser koden men vet inte om den kommer att utlösas; DAST vet om den kan utlösas men vet inte i vilken linje problemet är; IAST båda, men kräver att koden ska utföras.
SAST täcker tidigt, brett och högt; DAST har litet buller men sen intervention, smal täckning; och IAST har hög noggrannhet men kan koppla in och köra tillräckligt bra.
Gå bara till SAST, som är sårbar för "en massa röd tejp" trötthet; gå till DAST, där kryphålet ofta utsätts på linjen; gå till IAST, där den väg som den inte nås är blind.

Svaret på verkligheten är inte en eller två, utan ett steg-för-steg-tillvägagångssätt: den tidiga användningen av SAST för att sylt ett tydligt mönster av dålig smak och fara, testfasen av IAST som korrekt valideras med IAST i samband med automatisering, och upp- och ned-line användning av DAST för extern acceptans från angriparens perspektiv. Tre vidskepelser utgör ett applikationssäkerhetstest stängt slinga utan betydande luckor.

Statiska, dynamiska, interaktiva tester bildar en stängd cirkel.

VII. PRACTIKA ISSUES ON LANDING

Misreporting som handlar om det

Hur som helst, ingen fixar rapporten, ingen gör det. Det finns en tydlig triageprocess: vem ser, hur lång tid att stänga, hur man markerar "att acceptera risk". SAST behöver baslinjehantering, annars kommer historiens arv att dränka nya problem.

Täckning är viktigare än verktygsvarumärken

IASTs förmåga att upptäcka beror direkt på hur många koder som omfattas av testet; DAST beror på hur många gränssnitt som nås av reptiler. Det är mer meningsfullt att mäta "detekteringshastigheten" innan du går online än att ersätta ett dyrare verktyg.

Behandla inte säkerhetstest som engångstest Ta det.

Säkerhetstester bör inbäddas i en kontinuerlig R & D-process, snarare än centraliserad innan du går online. CI driver SAST, testar miljö IAST, gör regelbundet DAST för produktion, så det behöver inte förlita sig på mänskligt kött för att rädda elden.

Fokus på synergier bland verktyg

Det ideala tillståndet är att tre typer av resultat kan grupperas i samma vy: samma kryphål, SAST ger kod plats, IAST ger data ström bevis, och DAST validerar tillgänglighet. Det är värt mycket mer än de tre krigshärjade öarna.

VIII. En lista över beslut

Ja.InlämningsfasHåll bara av det uppenbara kryphålet på SAST, fokusera på dörr stängningar och baslinjer.
För att verifieraÄr det installerade systemet verkligen kapabelt att attackera? • Upp med DAST, med fokus på täckning och inloggningskonfiguration.
För att få säkerhetsslutsatser.Utgång med automatiserad testningOch hitta exakt på IAST.
Begränsade resurser kan endast användas som en första prioritet för SAST för att etablera en bottenlinje och sedan gradvis för att slutföra IAEA/DAST.
Sökandet efter en "one-size-fits-all, permanent lösning" finns inte, men sättet att organisera och bearbeta är svaret.

SAST är möjligt, DAST är praktiskt, IAST är specifikt - kombinerat är en komplett bild.