- Programvarusårbarheter är sårbarheter som kan utnyttjas och som kan leda till dataintrång, ransomware och avbrott i tjänsten om de inte åtgärdas omedelbart.
- De vanligaste sårbarheterna inkluderar injektioner (SQL, kommandon), XSS, buffertöverflöden, felaktig åtkomstkontroll, osäkra API:er och opatchad programvara.
- Kombinationen av kodgranskningar, penetrationstester, specialiserade skannrar och bra patchhantering minskar attackytan drastiskt.
- Effektivt skydd kräver också att man åtgärdar hårdvaru- och mänskliga faktorers sårbarheter genom policyer, utbildning och en stark cybersäkerhetskultur.

Programvarusårbarheter är den svaga länken i de flesta moderna digitala system: en liten brist i koden, en felkonfiguration eller en ouppdaterad patch kan öppna dörren för dataintrång, ransomware eller allvarliga driftstörningar. Även om många organisationer redan har antivirusprogram, brandväggar och andra försvarslager, kan om programvaran är sårbar, all den ansträngningen äventyras på några minuter.
Allt som designats av människor är känsligt för misslyckanden , och programvara är inget undantag. Från webbapplikationer och API:er till operativsystem, firmware och kärndrivrutiner kan alla dessa komponenter innehålla sårbarheter som kan utnyttjas. Att förstå vad sårbarheter är, de olika typerna som finns, hur man upptäcker dem och framför allt hur man åtgärdar och hanterar dem snabbt är nyckeln till att undvika stora problem som kan leda till miljontals dollar i förluster, regulatoriska påföljder eller skador på ryktet.
Vad är en mjukvarusårbarhet och varför är det så viktigt?
Inom datavetenskap är en sårbarhet en svaghet i ett system, en applikation, en enhet eller en process som en angripare kan utnyttja för att skada, ändra eller komma åt information eller tjänster utan auktorisering. Denna svaghet kan finnas i koden (programmeringsfel), hårdvaran, konfigurationen, interna procedurer eller till och med mänskligt beteende.
En sårbarhet i sig är ännu inte en attack ; det är en latent risk. Problemet uppstår när någon lyckas utnyttja den, antingen avsiktligt (en cyberbrottsling utför en attack) eller oavsiktligt (en användare orsakar en krasch genom att ange oväntad data). Ett enkelt, dåligt hanterat buffertöverflöde kan utlösa allt från en denial-of-service-attack till exekvering av godtycklig kod.
Effekterna av en utnyttjad sårbarhet kan vara enorma : stöld eller exponering av personliga och ekonomiska uppgifter, distribution av skadlig kod, datakryptering via ransomware, störningar i kritiska tjänster eller till och med kompromettering av övergripande infrastruktur. När det gäller webbapplikationer kan till exempel en SQL-injektion eller XSS-attack bli porten till resten av företagsnätverket.
Att upptäcka och åtgärda sårbarheter tidigt är mycket billigare än att reagera efter en incident. Att integrera säkerhet i programvaruutvecklingslivscykeln (SDLC) och anta DevSecOps-liknande metoder gör att du kan "flytta säkerheten åt vänster": att hitta brister i de tidiga design- och kodningsfaserna, när det är billigare att åtgärda dem än att patcha system som redan är driftsatta i produktion.
En sårbarhet kan manifestera sig på många olika sätt . Det kan vara en tjänst som lyssnar på en onödig port, ett öppet Wi-Fi-nätverk, en exponerad brandväggsport, en obefintlig lösenordspolicy eller anläggningar utan fysisk åtkomstkontroll. Alla dessa situationer, även om de inte verkar vara rent "programvarurelaterade", är en del av den uppsättning sårbarheter som en angripare kan utnyttja för att uppnå sitt mål.

Huvudtyper av programvarusårbarheter
Programvarusårbarheter omfattar flera kategorier , från klassiska minnesfel till logiska brister i autentisering eller brister i arkitekturdesign. Nedan följer några av de vanligaste och mest relevanta typerna idag, av vilka många återspeglas direkt i listor som OWASP Top 10.
Nolldagssårbarheter
En nolldagarssårbarhet är en brist som är okänd för tillverkaren och som redan utnyttjas av angripare innan en patch finns tillgänglig. Fall som Log4j-sårbarheten visade hur farliga dessa situationer kan vara: miljontals system exponerades medan leverantörer kämpade för att förbereda korrigeringar.
I en nolldagarssårbarhet har angripare en tillfällig fördel eftersom de har en fungerande exploit medan försvarare förblir oförberedda. I det här scenariot är beteendebaserad detektering, trafikfiltrering, nätverkssegmentering och policyer för lägsta behörighet avgörande för att mildra effekten tills officiella patchar släpps.
Fjärrkodkörning (RCE)
En sårbarhet för fjärrkörning av kod gör det möjligt för en angripare att köra skadliga instruktioner på ett målsystem utan fysisk åtkomst. Det är en av de mest kritiska kategorierna eftersom den, när den utnyttjas, kan användas för att installera skadlig kod, komma åt känsliga data, skapa bakdörrar eller koppla in sig mot andra interna system.
RCEs förlitar sig vanligtvis på andra underliggande sårbarheter , såsom minnesöverskott, injektioner eller problem med datadeserialisering. Lyckad utnyttjande resulterar vanligtvis i en fullständig kompromettering av det drabbade systemet, särskilt om den sårbara applikationen körs med förhöjda rättigheter.
Problem med datavalidering och sanering
Ett stort antal attacker härrör från dåligt validerade indata . Om en applikation inte kontrollerar eller rensar de data den tar emot (formulär, URL-parametrar, rubriker, JSON, etc.) kan en angripare smyga in skadligt innehåll som tolkas som oväntad kod eller instruktioner.
Denna kategori inkluderar flera välkända sårbarheter , såsom SQL-injektion, Cross-Site Scripting (XSS), strängformateringsfel och vissa buffertöverflöden. Att validera typer, intervall, format och längder för alla fält, samt att använda vitlistor och förbereda frågor på ett säkert sätt, är grundläggande för att minimera dessa risker och är en del av god säker utvecklingspraxis.
SQL-injektion och andra typer av injektion
SQL-injektion (SQLi) är en av de vanligaste attackerna mot webbapplikationer som interagerar med databaser. Det innebär att manipulerade SQL-satser infogas i oskyddade inmatningsfält (inloggningsformulär, sökningar, filter etc.) för att tvinga applikationen att köra frågor som inte är avsedda av utvecklaren.
Den här typen av sårbarhet gör det möjligt för angripare att läsa hela tabeller (inklusive lösenord och kreditkortsinformation), ändra eller ta bort poster, ändra inloggningsuppgifter eller göra hela databaser oanvändbara. Eftersom SQL-formulär och frågor är allestädes närvarande kan nästan vilken SQL-motor som helst (MySQL, PostgreSQL, SQL Server, Oracle och till och med vissa MongoDB-liknande implementeringar som stöder liknande frågor) påverkas om koden inte är ordentligt skyddad.
SQL-injektioner är inte begränsade till SQL-injektioner . Det finns också injektioner av operativsystemkommandon, LDAP-injektioner, mallinjektioner, rubrikinjektioner och osäker avserialisering. De har alla ett gemensamt problem: programvaran tolkar data som instruktioner eftersom korrekta kontroller och separation inte har implementerats.
Cross-Site Scripting (XSS) och Cross-Site Request Forgery (CSRF)
Cross-Site Scripting (CSSS) gör det möjligt för en angripare att injicera skript på legitima webbsidor som andra användare normalt besöker. Om programmet inte filtrerar det visade innehållet korrekt kan det skadliga skriptet stjäla sessioner, fånga in autentiseringsuppgifter eller ändra webbplatsens beteende från offrets webbläsare.
Cross-site request forgery (CSRF), å andra sidan, lurar en autentiserad användares webbläsare att utföra oönskade åtgärder på en betrodd applikation (som att ändra ett lösenord eller göra en överföring) genom att utnyttja det faktum att webbläsaren automatiskt skickar sessionscookies. Skyddet är beroende av anti-CSRF-tokens, lämpliga rubriker och ytterligare verifieringsåtgärder.
Buffertöverflöde och formateringsfel
Buffertöverflöde är ett klassiskt säkerhetsproblem i C och C++ . Det uppstår när ett program skriver mer data än vad som får plats i ett reserverat minnesområde (buffert), vilket skriver över angränsande områden och potentiellt ändrar variabler, returadresser eller interna systemstrukturer.
Detta okontrollerade beteende kan leda till krascher, frysningar eller, i värsta fall, godtycklig kodkörning. På liknande sätt kan formateringsfel i strängar (till exempel felaktig användning av utskriftsfunktioner med användarkontrollerade parametrar) möjliggöra minnesmanipulation eller läckage av känslig information om det inte programmeras noggrant.
Felaktig åtkomstkontroll och osäker design
Felaktig åtkomstkontroll uppstår när applikationen inte korrekt verifierar vad varje användare har behörighet att göra, vilket tillåter åtgärder eller åtkomst som borde begränsas. Detta inkluderar allt från administrativa funktioner som är synliga för alla autentiserade användare till API:er som inte tillämpar rollbaserade kontroller.
Osäker design, å andra sidan, återspeglar djupare arkitektoniska brister, inte bara kodningsfel. Det handlar om problematiska strukturella beslut, som att inte beakta lagerstrukturering, att inte inkludera loggning och spårbarhetsmekanismer, eller att inte planera för skydd av känsliga data från början. Att korrigera dessa problem kräver vanligtvis betydande förändringar av systemets grund.
Kryptografiska fel och brist på kryptering
Kryptografiska brister sträcker sig från att använda föråldrade algoritmer (som trasiga chiffer eller osäkra hashfunktioner) till dåligt implementerade protokoll eller felaktig återanvändning av nycklar. Allt detta gör att det teoretiska skydd som kryptografi erbjuder försvinner i praktiken.
Avsaknaden av kryptering är också en sårbarhet i sig . Att lagra data i klartext i databaser, filer eller säkerhetskopior, eller att misslyckas med att kryptera kommunikationen mellan klient och server, underlättar avsevärt arbetet för en angripare som får tillgång till miljön eller avlyssnar nätverkstrafik.
Svaga och dåligt konfigurerade API:er
API:er har blivit en högsta prioritet inom hantering av cybersäkerhetsrisker eftersom de är den tysta porten till kritisk data och funktioner. Många organisationer säkrar sina synliga webbgränssnitt, men lämnar interna, mobila eller tredjeparts-API:er mindre skyddade.
Typiska API-sårbarheter inkluderar svag autentisering, dålig auktorisering, överdriven dataexponering, alltför detaljerade felmeddelanden och avsaknaden av begränsning av förfrågningshastigheten. Alla dessa gör API:er till en perfekt vektor för att automatisera storskaliga attacker.
Sårbarheter på grund av föråldrad och opatchad programvara

Opatchad programvara är förmodligen den vanligaste akilleshälen i alla organisationer. Varje gång en leverantör släpper en säkerhetsuppdatering och den inte installeras, lämnar det en dörr öppen med ett lås vars funktion redan är allmänt känd, ofta dokumenterad i databaser som CVE-listan (Common Vulnerabilities and Exposures); det är därför proaktivt programvaruunderhåll är viktigt.
Dessa opatchade sårbarheter påverkar alla typer av komponenter : operativsystem, affärsapplikationer, webbläsare, plugin-program, nätverksenheters firmware, hårdvarudrivrutiner etc. Ju längre patchen förblir opatchad, desto större är sannolikheten att fungerande exploater kommer att dyka upp och börja användas i stor utsträckning.
Cyberbrottslingar söker aktivt efter föråldrade system eftersom de är måltavlor med låg ansträngning: det räcker med att skanna IP-intervall eller publicerade tjänster för att hitta versioner som är kända för att vara sårbara och starta automatiserade attacker, utan behov av komplex ingenjörskonst.
Varför många sårbarheter inte patchas
Trots den uppenbara fördelen med att "ständigt uppdatera " stöter organisationer på flera praktiska hinder: mängden uppdateringar, beroenden mellan system, brist på tid eller personal och alltmer distribuerade miljöer.
Bland de vanligaste faktorerna är logistiska problem (tusentals olika applikationer att uppdatera), resursbegränsningar (överbelastade IT-team, brist på budget), komplexiteten i starkt sammankopplade system (en patch kan bryta kompatibiliteten) och, på senare tid, svårigheten att hantera patchar på fjärrenheter eller utanför företagets nätverk.
Äldre system utgör ett särskilt känsligt fall . Många äldre system upphör att få tillverkarsupport, vilket innebär att officiella patchar inte längre är tillgängliga. De är dock fortfarande viktiga för kritiska processer, vilket gör det svårt att avveckla dem. I dessa fall måste åtgärder som att isolera dem från nätverket eller implementera kontrollerad virtualisering övervägas.
Risker med ouppdaterad programvara
Konsekvenserna av att inte installera säkerhetsuppdateringar är långtgående . För det första ökar de exponentiellt exponeringen för cyberattacker; för det andra kan de leda till bristande efterlevnad av regelverk; och slutligen har de ekonomiska och anseendemässiga konsekvenser som kan vara i åratal.
Ur ett cybersäkerhetsperspektiv utnyttjas opatchad programvara för att starta dataintrång, olika typer av skadlig kodinfektion och storskaliga ransomware-kampanjer. Uppmärksamma fall som WannaCry-attacken utnyttjade kända sårbarheter i opatchade Windows-system, vilket påverkade hundratusentals datorer världen över.
Inom reglerade sektorer (finans, hälso- och sjukvård, betaltjänster) kan underhåll av föråldrade system bryta mot regler som GDPR, HIPAA eller PCI DSS, vilka kräver implementering av rimliga åtgärder för att skydda data. Böter kan uppgå till en betydande andel av de årliga intäkterna, utöver den anseendekostnad som är förknippad med ett offentligt intrång.
Den direkta ekonomiska skadan från en sårbarhetsincident som inte har uppdaterats inkluderar incidenthantering, forensisk analys, återställning av säkerhetskopior, juridisk rådgivning, kundmeddelanden och potentiell ersättning. Detta förvärras av förluster på grund av driftstopp, kundbortfall och kostnaden för att därefter stärka säkerhetsåtgärderna.
Andra sårbarhetsområden: hårdvara och mänsklig faktor
Säkerhet slutar inte med applikationsprogramvara . Hårdvaran som dessa applikationer körs på och de personer som använder dem är viktiga delar av attackytan. En seriös cybersäkerhetsplan kan inte ignorera dessa element.
Hårdvarusårbarheter
Inom hårdvarusektorn härrör många svagheter från fabriksfel eller dålig efterföljande hantering. Enheter som levereras med standardlösenord, föråldrade routrar eller kameror, förfalskad utrustning eller firmware med kända sårbarheter är vanliga exempel.
Några vanliga hårdvarurisker inkluderar standardlösenord som aldrig ändras, brist på åtgärder mot obehörig fysisk åtkomst, föråldrad firmware, enheter utan officiellt stöd, fault injection-attacker eller användning av förfalskad hårdvara med potentiellt skadliga modifieringar.
Dessutom har många infrastrukturkomponenter en lång livslängd och blir föråldrade, samtidigt som nya hot uppstår. Utan förnyelse, segmentering och hårdare planer blir de svaga länkar som är mycket svåra att skydda.
Personalrelaterade sårbarheter
Den mänskliga faktorn är fortfarande en av de största riskfaktorerna . Anställda som använder svaga eller återanvända lösenord, faller för nätfiskemejl, ansluter obehöriga enheter, delar inloggningsuppgifter eller ignorerar säkerhetsrutiner – ofta utan ont uppsåt – kan undergräva även de bästa tekniska försvaren.
Bland de vanligaste sårbarheterna relaterade till personal finns åtkomst till osäkra nätverk, bristande medvetenhet om nätfiske, användning av förutsägbara lösenord, installation av programvara utan auktorisering, bristande efterlevnad av företagspolicyer eller interna hot från missnöjda anställda.
Att minska dessa risker kräver mycket mer än en skriftlig policy . Det kräver kontinuerlig utbildning och informationsspridning, simuleringar (såsom kontrollerade interna nätfiskekampanjer), övervakning av efterlevnad och att främja en kultur där rapportering av incidenter eller misstänkt beteende är en självklarhet.
CVE:er och avancerade sårbarheter: ett exempel på ett fall i Linuxkärnan
Vissa sårbarheter påverkar mycket låga lager i systemet , såsom operativsystemkärnan eller virtualiseringsmoduler. Ett illustrativt exempel är en brist dokumenterad som CVE-2026-23005, relaterad till FPU-tillståndshantering och XSAVE/XRSTOR-instruktionerna i x86-miljöer med KVM-virtualisering.
I det här specifika fallet uppstår problemet med hanteringen av XFD-registret och XSTATE_BV-fältet i XSAVE-tillståndet för de virtuella gästmaskinerna. Om vissa FPU-funktioner (som avancerade tillägg som AMX) är inaktiverade via XFD men fortfarande markerade som "används" i XSTATE_BV, kan kärnan försöka återställa ett inkonsekvent tillstånd och utlösa ett #NM-undantag, vilket potentiellt till och med kan orsaka systempanik.
Utlösaren kan till exempel vara en skrivning till MSR IA32_XFD av gästmaskinen, kombinerat med ett avbrott eller en kontextväxling just i det ögonblick då den virtuella maskinens FPU-tillstånd ännu inte har synkroniserats korrekt. Det kan också inträffa om användarutrymmet introducerar inkonsekventa XSAVE-tillstånd via gränssnitt som KVM_SET_XSAVE.
Kärnlösningen innebär att XSTATE_BV rensas för funktioner som inaktiverats av XFD när gästmaskinens XSAVE-tillstånd uppdateras. Detta säkerställer att XRSTOR inte försöker återställa information för komponenter som XFD anser vara inaktiva. Denna korrigering bibehåller överensstämmelse med Intels specifikationer och förhindrar undantag för otillgängliga enheter.
Det här exemplet visar att sårbarheter inte alltid är uppenbara för dem som bara ser applikationslagret. De finns ofta i samspelet mellan hårdvara, kärna och virtualisering, och kräver hög grad av expertis för att identifiera och åtgärda. Därav vikten av att noggrant övervaka operativsystemens säkerhetsrekommendationer och noggrant tillämpa lågnivåuppdateringar.
Metoder och verktyg för att upptäcka sårbarheter
Att systematiskt upptäcka sårbarheter innebär att kombinera både manuella och automatiserade metoder. En enda metod är otillräcklig: kodgranskning, penetrationstestning, systemskanning och testning med simulerade illvilliga användare är alla kompletterande komponenter.
källkodsgranskning
Kodgranskning är ett av de mest effektiva försvaren för att upptäcka sårbarheter innan programvara når produktion. Det kan göras manuellt, genom kollegial granskning bland utvecklare, eller med hjälp av statiska analysverktyg som automatiskt letar efter riskmönster.
Vid manuella granskningar måste de ansvariga vara väl bekanta med den terminologi som används, bästa säkerhetspraxis (felkontroll, inmatningsvalidering, minneshantering, autentisering, kryptering) och ha tydliga checklistor. Att bara granska den "lyckliga vägen" räcker inte; edge cases och kapplöpningsförhållanden måste också identifieras.
Statiska analysverktyg och SAST kompletterar denna process genom att skanna stora kodbaser efter kända mönster kopplade till typiska sårbarheter: injektioner, XSS, buffertöverflöden, användning av farliga funktioner etc. Även om de genererar falska positiva resultat hjälper de till att undvika att förbise vissa återkommande problem.
Penetrationstester och sårbarhetsskanningar
Penetrationstestning simulerar verkliga attacker mot applikationer, infrastruktur och API:er för att identifiera intrångsvektorer genom att kedja samman sårbarheter, precis som en angripare skulle göra. Dessa tester kan vara black-box (utan föregående information), gray-box (med viss kontext) eller white-box (med tillgång till kod och arkitektur).
Parallellt skannar sårbarhetsskannrar portar , tjänster och applikationer och letar efter kända sårbara versioner eller problematiska konfigurationer. De är idealiska verktyg för att upprätthålla en aktuell karta över riskerna i organisationen och prioritera åtgärder.
Specialiserade verktyg: OWASP ZAP, Nikto och Acunetix
OWASP ZAP är ett allmänt använt verktyg med öppen källkod för att analysera webbapplikationer. Det låter dig fånga upp trafik, automatisera identifieringsattacker, köra SQL-injektionstester, XSS-attacker, autentiseringskontroller med mera, och genererar rapporter som beskriver de upptäckta sårbarheterna och deras inverkan.
Nikto fokuserar på att analysera webbservrar , kontrollera svaga konfigurationer, föråldrade versioner, känsliga kataloger och filer samt felkonfigurerade rubriker. Det är särskilt användbart som en snabb skanner för att identifiera enkla men farliga problem i webbmiljöer.
Acunetix är en mer omfattande kommersiell lösning som kombinerar djupa automatiserade skanningar av webb- och mobilapplikationer med riktade tester för kodinjektion, autentiserings- och auktoriseringsfel, XSS, CSRF och många andra kategorier. Dess rapporter innehåller vanligtvis specifika rekommendationer för att åtgärda varje fynd.
Användartestning med fokus på säkerhet
Utöver teknisk testning är det avgörande att införliva säkerhetsinriktad användartestning. Det handlar inte bara om att verifiera att applikationen "fungerar", utan om att kontrollera hur den beter sig när den ställs inför illvilliga användare, felaktiga inmatningar eller oförutsedda arbetsflöden.
Datainjektionstestning fokuserar till exempel på att introducera specialutformad data (specialtecken, långa strängar, misstänkta strukturer) för att testa hur applikationen bearbetar den. Om det visar sig att programvaran filtrerar otillräckligt öppnar det dörren för SQL-injektion, XSS och andra attacker.
Autentiseringstester verifierar robustheten hos inloggningsprocessen , sessionshanteringen, mekanismerna för lösenordsåterställning och den rollbaserade åtkomstkontrollen. Försök görs att kringgå inloggningsprocessen, eskalera behörigheter, återanvända sessioner eller manipulera tokens för att utvärdera styrkan hos hela autentiseringssystemet.
Bästa praxis för att förebygga och hantera sårbarheter
En effektiv sårbarhetsstrategi kombinerar förebyggande , tidig upptäckt och snabba åtgärder. Det är omöjligt att förhindra 100 % av sårbarheterna, men det är möjligt att minska deras antal, allvarlighetsgrad och den tid de kan utnyttjas.
Patchunderhåll och hantering
Att hålla system och applikationer uppdaterade är grundläggande och en del av programvaruunderhållet . Detta innebär att implementera säkerhetsuppdateringar så snart som möjligt, etablera regelbundna underhållsfönster, testa uppdateringar i förproduktionsmiljöer och automatisera driftsättning så mycket som möjligt.
Automatiserade lösningar för patchhantering hjälper till att orkestrera uppdateringar av operativsystem och tredjepartsprogram, prioriterar dem baserat på kritiskhet och minskar manuella åtgärder. Integrering av dessa verktyg med slutpunktssäkerhet (antivirus, EDR, brandvägg) ger en enhetlig bild av skyddsstatus.
Riskbaserad prioritering är nyckeln : alla patchar är inte lika brådskande. Att använda mätvärden som CVSS, kombinera hotinformation (att veta vilka sårbarheter som aktivt utnyttjas) och beakta varje systems roll i verksamheten hjälper till att avgöra vad som ska åtgärdas först.
Personalutbildning och säkerhetskultur
Ingen teknik kan kompensera för bristande medvetenhet . Regelbunden utbildning av all personal i nätfiske, lösenordsanvändning, enhetsskydd, hantering av känslig information och incidentrapportering minskar attackytan märkbart.
Dessutom är det viktigt att främja en kultur där säkerhet är allas ansvar, inte bara IT-avdelningens. Detta inkluderar utvecklare, drift, HR, ekonomi och ledning. Säkerhet bör integreras i dagliga processer och beslut, inte vara en eftertanke.
Policyer, revisioner och incidenthantering
Att definiera tydliga säkerhetspolicyer hjälper till att sätta gränser för vad som är och inte är tillåtet: programvaruanvändning, fjärråtkomst, lösenordshantering, datalagring, personliga enheter (BYOD) etc. Men dessa policyer måste granskas och revideras regelbundet för att säkerställa efterlevnad.
Regelbundna säkerhetsrevisioner möjliggör upptäckt avvikelser , identifiering av föråldrade system, dåligt implementerade processer och tidigare obemärkta sårbarheter. Baserat på dessa revisioner utvecklas korrigerande åtgärdsplaner och prioriteringar omprövas.
Att ha en väldefinierad incidenthanteringsplan är avgörande för att minimera effekterna när något oundvikligen går fel. Denna plan bör innehålla rutiner för upptäckt, inneslutning, utrotning, återställning och kommunikation, samt tydliga ansvarsområden för varje inblandat team.
I en miljö där hot ständigt utvecklas är det enda realistiska sättet att hålla sig säker att anta att sårbarheter alltid kommer att finnas, men arbeta för att minska deras antal, upptäcka dem tidigare och minimera deras utnyttjandetid. Detta genom att kombinera god design, säker utveckling, disciplinerad patchhantering, specialiserade verktyg, skyddad hårdvara och framför allt utbildad personal som är medvetna om sin roll i organisationens säkerhet.