Säkerhetstestning

Statisk applikationssäkerhetstestning analyserar källkod, bytekod eller kompilerade artefakter utan att köra applikationen. Den fungerar genom att tolka koden till ett abstrakt syntaxträd (AST), bygga en modell av dataflödet genom applikationen och tillämpa regler som detekterar säkerhetsrelevanta förhållanden som användarkontrollerad data som flödar in i en databasfråga utan sanering (SQL-injektion) eller användarinput reflekterat i HTML-utdata utan kodning (XSS).

SAST är vällämpat för att hitta strukturella sårbarheter som verkar som konsekventa kodmönster. SQL-injektion, kommandoinjektion, sökvägstraversal, hårdkodade hemligheter och saknad inmatningsvalidering. Det kämpar med sårbarheter som bara uppträder i körtidskontext. Auktorisationsfel, affärslogikfel och konfigurationsberoende beteende.

Populära SAST-verktyg inkluderar Semgrep (snabb, regelbaserad, mycket anpassningsbar), SonarQube (brett språkstöd, spårar fynd över tid) och CodeQL (GitHubs frågebaserade analys). Var och en har olika regeldjup och integrationskomplexitet.

Det vanligaste misstaget med SAST är att köra det med standardregler och acceptera alla fynd okritiskt. Standardregeluppsättningar är utformade för att vara breda snarare än specifika för en given kodbas, vilket vanligtvis producerar höga falsk-positiv-frekvenser. Effektiv SAST kräver justering.

Dynamisk applikationssäkerhetstestning testar en körande applikation utifrån, och behandlar den som en svart låda. Testaren skickar förfrågningar, observerar svar och letar efter beteenden som indikerar sårbarheter. SQL-felmeddelanden i svar, reflekterad inmatning i HTML, oväntade omdirigeringar och saknade säkerhetshuvuden. DAST kan hitta sårbarheter som bara uppträder vid körning. Inklusive injektionsbrister, autentiserings- och sessionshanteringsproblem.

DAST-verktyg fungerar vanligtvis i två lägen. Passiv skanning (observera trafik utan att skicka skadliga nyttolaster) och aktiv skanning (skicka tillverkade attacknyttolaster för att sondera efter sårbarheter). OWASP ZAP är ett populärt verktyg med öppen källkod som stöder båda lägena och kan köras utan huvud i CI-pipelines. Burp Suite är industristandard för manuell testning av säkerhetsproffs.

Kvaliteten på DAST-resultat beror starkt på kvaliteten på testmiljön. En staging-miljö som använder en annan databas eller saknar samma sessionshantering som produktion kommer att producera resultat som inte korrekt återspeglar produktionsbeteende. Autentiserad DAST, där verktyget loggar in med ett testanvändarkonto, hittar avsevärt fler sårbarheter.

En vanlig missuppfattning är att DAST 'testar hela applikationen' och därför ger heltäckande säkerhetstäckning. DAST har begränsad täckning av applikationsfunktioner som det inte kan upptäcka eller komma åt. DAST kompletterar SAST och manuell testning men ersätter dem inte.

Software composition analysis inventarierar tredjepartsbibliotek och komponenter i en kodbas och kontrollerar dem mot databaser med kända sårbarheter. Moderna applikationer innehåller vanligtvis hundratals direkta beroenden och tusentals transitiva. SCA undersöker hela beroendegrafiken, inklusive transitiva beroenden, och identifierar komponenter med kända CVE:er, föråldrade versioner och riskfyllda licenser.

CVSS-poäng (Common Vulnerability Scoring System) är standardmåttet för sårbarhetens allvarlighetsgrad. Ett kritiskt CVSS-poäng indikerar en allvarlig sårbarhet, men CVSS ensamt avgör inte exploaterbarhet i ett specifikt sammanhang. En kritisk CVE i en bibliotekskomponent som aldrig anropas av applikationen är mindre brådskande. Nåbarhetsanalys, att avgöra om den sårbara kodsökvägen faktiskt anropas av applikationen, minskar avsevärt felaktig-positiv-liknande fynd.

Populära SCA-verktyg inkluderar Dependabot (GitHubs inbyggda beroendeoppdateringstjänst), Snyk (brett språkstöd, nåbarhetsanalys) och OWASP Dependency-Check. Licensefterlevnadsskanning är ofta en sekundär funktion för SCA-verktyg.

Den vanligaste spänningen i SCA är mellan säkerhetsfördelen med att uppdatera beroenden och den operativa risken med brytande ändringar. Praxisen att hålla beroenden aktuella genom automatiserade, inkrementella uppdateringar är mycket säkrare än att skjuta upp alla uppdateringar tills en kritisk CVE tvingar fram en nöduppgradering.

Hemlighetsskanning detekterar autentiseringsuppgifter, tokens, API-nycklar, privata nycklar och andra känsliga värden som har committats till källkodsrepositoryn eller visas i byggartfakter. Hemligheter committade till ett repository, särskilt ett offentligt sådant, måste antas vara komprometterade omedelbart.

Detektionstekniker inkluderar mönstermatchning mot kända hemliga format (GitHub-tokens matchar ett specifikt regex, AWS-åtkomstnycklar har en igenkännlig struktur), entropianalys (strängar med hög entropi är troligen slumpmässiga och möjligen kryptografiska material) och maskininlärningsmodeller. GitHub Advanced Security, GitGuardian, TruffleHog och gitleaks är populära verktyg.

Pre-commit hooks kan skanna iscensatta filer innan en commit görs, vilket ger den tidigast möjliga detekteringen. CI-baserad skanning är dock mer tillförlitlig som kontroll eftersom den är svårare att kringgå. Historisk skanning söker hela git-historiken efter hemligheter som committades och sedan raderades. Radering tar inte bort en hemlighet från historiken.

När en hemlighet detekteras i ett repository är det korrekta svaret. Omedelbart rotera autentiseringsuppgiften (generera en ny och återkalla den exponerade), granska loggar för att avgöra om autentiseringsuppgiften användes av någon annan än den avsedda användaren och undersöka hur den committades.

Containerskanning inspekterar containerimages för kända sårbarheter i de paket och bibliotek de innehåller. Den opererar på två nivåer. OS-nivåskanning (undersöker paket installerade av distributionens pakethanterare) och applikationsnivåskanning (undersöker språkspecifika paket som npm, pip, maven). En heltäckande skanning täcker båda nivåerna.

Basimagen är vanligtvis den största källan till sårbarheter i en containerimage. En image baserad på ubuntu:20.04 som inte byggdes om på tre månader kan ha dussintals kända CVE:er i sina OS-paket, även om applikationen själv inte har några nya kodändringar. Det är därför regelbunden ombyggnad av images från uppdaterade basimages är en viktig del av containersäkerhetshygienen.

Trivy är ett brett använt verktyg med öppen källkod som kontrollerar OS-paket, språkberoenden och konfigurationsproblem i ett enda verktyg. Kommersiella alternativ inkluderar Snyk Container och registryintegrerade skannrar i AWS ECR och Google Artifact Registry.

En kritisk distinktion är mellan 'imagen har CVE:er' och 'imagen har exploaterbara sårbarheter i sitt sammanhang.' En containerimage kan ha dussintals CVE:er i sällan använda OS-paket som aldrig är nåbara från extern inmatning. Team som tillämpar skannersutdata direkt på releaseportar utan kontextuell triagering hamnar ofta i ett av två misslyckningssätt. Blockerar för mycket eller tillåter för mycket.

Infrastruktur-som-kod-skanning analyserar moln- och plattformskonfigurationsfiler (Terraform, CloudFormation, Kubernetes YAML) för säkerhetsmissar-konfigurationer innan de tillämpas på verklig infrastruktur. IaC-skannrar letar efter kända högrisksmönster. S3-buckets med offentlig åtkomst aktiverad, säkerhetsgrupper med öppen ingress på 0.0.0.0/0, databaser utan kryptering i vila och IAM-policyer med wildcard-behörigheter.

Populära IaC-skanningsverktyg inkluderar Checkov (brett IaC-formatstöd, 1000+ inbyggda kontroller, stöd för anpassad policy i Python), tfsec (Terraform-fokuserat, snabbt) och KICS (bred formatsupport). Det rätta verktyget beror på IaC-ramverket i användning och om anpassade policyer behövs.

Den viktigaste distinktionen mellan IaC-skanning och CSPM (Cloud Security Posture Management) är tidpunkt. IaC-skanning opererar på kod före driftsättning, det är en förebyggande kontroll. CSPM-verktyg skannar levande molnresurser efter driftsättning, de är detektiva kontroller. Båda är värdefulla.

IaC-skanning möjliggör tidig korrigering av felkonfigurationer. Att ett terraform apply med en offentlig S3-bucket blockeras i pipelinen är oändligt billigare än att manuellt identifiera och stänga en exponerad bucket efter driftsättning.

En kvalitetsport är en policybeslutspunkt i pipelinen som utvärderar säkerhetstestresultat och avgör om bygget ska fortsätta. En sårbarhet som matchar portens kriterier blockerar pipelinen, en som inte matchar passerar igenom. Kvalitetsportar gör säkerhetstestning handlingsbar.

Portdesign kräver balansering av strikthet med praktiskhet. Att blockera på varje kritisk CVE, även för en bibliotekskomponent i ett djupt nestet transitivt beroende med en teoretisk exploit, kommer snabbt att producera en pipeline som inte kan driftsätta. En pragmatisk metod beaktar kombinationen av allvarlighetsgrad, exploaterbarhet och affärspåverkan.

Tidsbaserad undantagshantering är en viktig funktion för operativa SCA-portar. En port som ger en konfigurerbar respitperiod, 'blockera om denna CVE är mer än 30 dagar gammal och oadresserad', gör det möjligt för team att arbeta i rimlig takt.

Larmtrötthet är fienden till funktionella kvalitetsportar. När portar ständigt utlöser med lågsignalsfynd lär sig utvecklare att ignorera dem. Det rätta svaret på alltför många portfel är inte att sänka tröskeln utan att undersöka varför porten utlöser.

En falsk positiv i säkerhetstestning är ett fynd som verktyget rapporterar som en sårbarhet men som inte representerar en verklig säkerhetsrisk i det specifika sammanhanget för applikationen. Vanliga orsaker inkluderar. SAST-verktyg som flaggar ett dataflöde som farligt utan att beakta att inmatningen valideras uppströms och SCA-verktyg som flaggar en CVE utan att veta att den sårbara kodsökvägen aldrig anropas.

Falska positiver har en direkt kostnad. Varje falsk positiv kräver tid att undersöka, triagera och undertrycka. I miljöer med hög volym där en skanner producerar hundratals fynd per build, överstiger den sammanlagda kostnaden för att triagera falska positiver kostnaden för de verkliga sårbarheter den hittar.

Det rätta svaret på en falsk positiv är att undertrycka den explicit med dokumenterad motivering, inte att tysta verktyget eller inaktivera regeln. En undertryckning bör registrera. Vad fyndet är, varför det inte är en verklig sårbarhet i detta sammanhang, vem som fattade det beslutet och när beslutet bör granskas igen.

Distinktionen mellan en falsk positiv (verktyget har fel om risken) och en accepterad risk (verktyget har rätt om risken, men teamet har beslutat att inte åtgärda den av dokumenterade skäl) spelar roll för revision och efterlevnad. En falsk positivundertryckning säger 'detta är inte en sårbarhet.' En accepterad risk säger 'detta är en verklig sårbarhet som vi har bedömt och accepterat under specifika villkor.'