SAST vs DAST vs IAST: Sikkerhetstest for komplementariteter av de tre brødrene, ikke erstatning

De tre vanligste forkortelsene i brukssikkerhetstestene er SAST, DAST, IAST. Manges første reaksjon var å «velge en av de sterkeste», men det var et hyklerisk forslag — de tre brødrene konkurrerte ikke, men så på det samme spørsmålet fra forskjellige perspektiver. Valget avhenger ikke av hvem som er mer avansert, men på scenen du er i programvare livssyklusen, hva slags loophole du vil finne og hvor mye du kan bære.

I. DEFINISJONER PÅ FØRSTE REFERENCE

• SAST (statisk brukssikkerhetstest)Andre arrangørerIkke kjør programmet, under hvilken skanningskildekoden/bytekoden finner et sløyfehull som tilhører den hvite boks.
• DASTAndre arrangørerKjøreprogramEksterne oppstartsforespørsler, simulerte angrep er \"svarte bokser\" og ingen kildekode kreves.
• IAST (interaktiv brukssikkerhetstest)Andre arrangørerKjør programmet innefraPlug-in (agent), kombinert med strømnings- og kodesammenheng, tilhører Gråboksen.

Nøkkelen til å forstå disse tre er at de hver svarer på forskjellige spørsmål: SAST spør, - hvor kan det være en feil i koden - Dast spør, kan vi faktisk komme oss gjennom når vi kjører - IAST spør: I denne operasjonen, som datastrøm virkelig flyter til farepunktet."

SAST: Strakse problemet på kodeskrivingsstadiet

SAST analyserer direkte kildekoden (eller kompilerer mellomproduktene) og utfører ikke programmet. Fordelen er å være i stand til å detektere problemer i et tidlig stadium, eller selv når koden sendes inn, å finne bestemte dokumenter og linjetall, med lave reparasjonskostnader. Den dekker kodene kan feies " og er ikke avhengig av driftstiden.

Shortboard: Feilhastigheten er vanligvis høy fordi den ikke bestemmer om et visst antall koder vil bli utløst i den virkelige virksomheten; problemene som utsettes kun når du kjører (f.eks. konfigurasjonsfeil, forsikring omgås, faktiske anropskjede av avhengighet på biblioteket) er ikke fullt ut sett; kildekoden er nødvendig og tredjeparts lukket kildekomponent er ikke funksjonell.

Typisk scenario: CI streaming linjekode innsendingsdører er lukket for å hindre synlig injeksjon, hard-kode nøkkel, farefunksjon ringer inn i ryggraden.

Dast: Verifisering " fungerer det virkelig?"

Dast bruker målet som en svart boks til å sende forespørsler fra utsiden, bygge angrepslaster og observere respons. Den største verdien er...Nær et reelt angrep.— Problemet med \"reell tilgang til kjøring\" ble funnet, med relativt lite underrapportering. Ingen kildekode er nødvendig, så tredjepartskomponenter, konfigurasjonslag kan også dekkes.

ShortboardDet er ofte bare før utplassering at deteksjonen av sen deteksjon og kostnadene ved reparasjon er høy; dekning er begrenset til reptiler og testruter som kan nås ved eksempel, uten deteksjon av ikke-deteksjonsbare funksjonspunkter; det er vanskelig å lokalisere kildekoden nøyaktig, og utvikling og rapportering er ofte bare kjent \"hven URL er problematisk\"; og konfigurasjonskostnadene er høye for scenarier som krever innlogging, flertrinns forretningsprosesser.

Typisk scenario: sikkerhetsklarering før du går på nettet, periodisk skanning av utplasserte miljøer.

IV. IAST: Run-time plugger, balansere sammenheng med reelle datastrømmer

IAST observerer også kodeutførelse og ekstern strøm når programmet kjører ved å implantere antert i søknaden. Det kan se hvordan forespørsler kommer inn, og hvordan data strømmer inn i koden, slik at det kan gis.Ta det fulle beviset på vertshuset.Den er vanligvis lavere enn SAST og nøyaktig.

ShortboardBehovet for å kunne distribuere sonder i målmiljøet (som gir bekymringer om produksjonsmiljøet); tillit til testdekning, som ikke kan finnes uten at koden implementeres, som ofte er bundet til funksjonell/automatisk testing; forskjeller i språk- og rammestøtte; og visse ytelseskostnader.

Typisk scenario: kjører i testmiljøet i forbindelse med automatisert testing, både for å validere funksjonaliteten og for å synkronisere utgangssikkerhetskonklusjoner.

Fem, tre mot en.

Dimensjoner	SAST	DAST	IAST
Testobjekt	Kilde/byte (ikke kjører)	Aktivt mål (ekstern)	Operative applikasjoner (intern plugger)
Perspektiv	Hvit boks	Svart boks	Grå boks
Tid for intervensjon	Koding/innsendelsesfase tidligst	Etter bruk	Test/kjøretid
Trenger kildekode	Ja.	Ingen grunn.	Krav (kan kobles)
Feilrapportert nivå	Høy	Lav	Lavere
posisjon presisjon	Til fil/linje	Til URL/ grensesnitt	For å ringe Inn/datastrøm
Overskriv avhengighet	Begrenset (se kildekodedelen)	Overstyr eksponering mens du kjører	Begrenset ved å utføre bane
Typisk scene	CI Code Door Ban	Sjekk og aksepter før du går på nettet.	Kombinert med automatisert testing

VI. Hvorfor komplementaritet i stedet for substitusjon

Hvis du setter de tre sammen, de finner sine blinde soner å være komplementære:

• SAST ser koden, men vet ikke om den vil bli utløst; DAST vet om den kan utløses, men vet ikke i hvilken linje problemet er; IAST begge, men krever at koden skal utføres.
• SAST dekker tidlig, bredt og høyt; DAST har liten støy men sen intervensjon, smal dekning; og IAST har høy nøyaktighet, men kan plugge inn og kjøre godt nok.
• Bare gå til SAST, som er sårbar for \"en haug av rødt tape\" tretthet; gå til DAST, hvor loophole ofte er utsatt på linjen; gå til IAST, hvor veien som den ikke er nådd er blind.

Svaret på virkeligheten er ikke en eller to, men en fase-for-trinns tilnærming: tidlig bruk av SAST for å jamne et klart mønster av dårlig smak og fare, testfasen av IAST for å være nøyaktig validert med IAST i forbindelse med automatisering, og opp- og ned-linje bruk av DAST for ekstern aksept fra aggressorens perspektiv. Tre overtroskaber utgjør en søknadssikkerhetstest lukket loop uten betydelige hull.

VII. PRACTISKE ANSVARER om landing

1. Feilrapportering som behandler det

Ingen fikser rapporten, ingen gjør det. Det er en klar triageprosess: som ser, hvor lenge å stenge, hvordan å markere " akseptere risiko " . Spesielt, SAST trenger baseline management, ellers arven fra historien vil drukne nye problemer.

Dekning er viktigere enn verktøymerker

Evnen til IAST å oppdage avhenger direkte av hvor mange koder som er dekket av testen; DAST avhenger av hvor mange grensesnitt som nås av reptiler. Det er mer meningsfullt å måle “deteksjonshastigheten” før å gå på nettet enn å erstatte et dyrere verktøy.

3. Ikke behandle sikkerhetsprøver som en-off tester Ta den.

Sikkerhetstester bør være innebygd i en kontinuerlig forskning og D-prosess, i stedet for sentralisert før du går på nettet. CI kjører SAST, testmiljø IAST, regelmessig gjør DAST for produksjon, så det trenger ikke å stole på menneskekjøtt for å redde brannen.

4. Fokus på synergi blant verktøy

Den ideelle tilstanden er at tre typer resultater kan grupperes i samme visning: samme loophole, SAST gir kode plassering, IAST gir datastrøm bevis og DAST validerer tilgjengelighet. Det er verdt mer enn de tre krigstorne øyene.

VIII. En liste over beslutninger

• Ja.InnsendingsfaseBare hold av det åpenbare løkkehullet på SAST, fokus på dørlukninger og baselines.
• For å bekrefteKan systemet virkelig angripes? • Opp med DAST, med fokus på dekning og innloggingskonfigurasjon.
• For å få sikkerhetskonklusjoner.Utgang med automatisert testingFinn nøyaktig på IAST.
• Begrensede ressurser kan bare brukes som en første prioritet for SAST å etablere en bunnlinje og deretter gradvis å fullføre IAEA/DAST.
• Søket etter en one-size-fits-all, permanent løsning - eksisterer ikke, men måten å organisere og behandle er svaret.

SAST er mulig, DAST er praktisk, IAST er spesifikk - kombinert er et komplett bilde.