Jag har i ett tidigare blogginlägg spekulerat över bestående skador efter heartbleed-buggen. Forsätter här med en betraktelse om möjliga orsaker till att några få rader rader felaktig programkod kan få sådana följder, risken för att det kan komma fler och vad man möjligen kan göras för att förebygga dessa.
När Robin Seggelmann postade sin "patch" för OpenSSL den 30:e december 2011 fanns nog bara ett gott uppsåt. Men kvalitetsgranskningen av denna patch brast och "heartbleed-buggen" var ett faktum som sedan distribuerades med OpenSSL version 1.0.1 14:e mars 2012.
När man bygger något så förutsätter man att de ingående delarna eller komponenterna är felfria och har en förutsägbar (lång) livslängd. Fallerar någon del så riskeras helheten. Bilindustrin drabbas regelbundet av att någon bilmodell måste återkallas för att åtgärda felaktiga eller misstänkt felaktiga komponenter. Kostnaderna för detta och den ev. varumärkesskada kan bli mycket höga. Konsekvenserna är dock ofta kontrollerbara då bilbranschen har väl upparbetade distributionskanaler som gör det relativ enkelt att spåra de enskilda, misstänkta fordonen för att erbjuda felrättning. Om bilarna skulle förbli oåtgärdade finns risken för olyckor och incidenter där oskyldiga och ovetande kan bli skadade.
När man bygger IT-system använder man oftast ett stort antal fria eller kommersiella komponenter och förutsätter att de fungerar exakt som deras specifikationer beskriver. Hur kvalitetssäkringen av dessa görs är oftast helt okänd för de som inkluderar dem i sina produkter. Ju fler komponenter av okänd kvalitet som används ju större är risken att bygger en bristfällig slutprodukt.
Man bygger alltså in en risk för att produkten beter sig felaktigt och kanske farligt i vissa situationer.
Bygger man sedan samverkande system av produkter som innehåller okända komponenter ökar riskerna ytterligare för att helheten kommer att bete sig mycket oförutsett och att felsökning av sådant beteende blir svårt och felrättning kanske blir helt omöjligt.
Ytterligare en risk med att bygga komplexa system är att de som designar dem inte bara litar på att komponenter och produkter beter sig enligt specifikation utan att de också designar lösningar som i sig är så komplexa så att, även om de byggs av felfria komponenter, de kommer få, till en del, oförutsägbart beteende.
Jag kallar ovanstående komplexitetens förbannelse. Av människan byggda system kan snabbt nå en komplexitet som inte längre kan förstås av människor, kanske inte ens av upphovsmännen.
Hur klarar vi då en framtid med dessa dystra förutsägelse?
Det som är enkelt att säga och svårt att leva efter är uttryck som "Keep it simple, stupid" (K.I.S.S.)" eller mitt eget motto; "ju enklare desto bättre".
I verkligheten är det väl snarast att man måste säkra kvaliteten i varje utvecklingssteg och för varje, koncept, arkitektur, komponent, produkt och slutligen det kompletta systemet.
För att säkra kvaliteten gäller först att med bra metoder och kunskap undvika att bygga in fel, nästa är att testa och då inte bara att det önskade beteende uppfylls utan också testa att inget oönskat kan ske.
När så en liten komponent som OpenSSL kan få hela internets trovärdighet i gungning så beror det på "komplexitetens förbannelse"!
Inga kommentarer:
Skicka en kommentar