Säker utveckling i din organisation?

Ägnade lite lunchtid åt att lyssna på en podcast om att rulla ut säker systemutveckling i sin organisation. Det är en bekant på Carnegie-Mellon University som intervjuas - Robert Seacord.

Är statisk kodanalys lösningen?
Robert tycker att verktyg som analyserar källkoden har sin plats men tenderar att få för mycket fokus i organisationen. Det största problemet är att analysverktygen sällan integreras i utvecklarnas vardag. Istället körs de emellanåt och felrapporterna läggs in i ett ärendehanteringssystem för att en bra bit senare landa i utvecklarnas knä. Då får utvecklaren hela kostnaden av att sätta sig in i koden igen och man odlar ett penetrate-and-patch-beteende. Bättre då att få förståelse för säker utveckling och integrera det i det dagliga kodandet:

"... when they're initially writing it, they understand the context in which the code's being written, they understand the complexities of the software. And that's the time to get it right."

Finns det något att göra åt språk som C?
Roberts grupp är engagerade i C1X, den nya C-standarden. De skriver på ett appendix kring säkerhet i C. Efter en del power-search på nätet hittade jag en pdf från 23/2 i år som beskriver deras arbete.

Deras huvudspår är att göra säkerhetsfunktioner valbara i kompilatorn och på så sätt nå samma säkerhetsnivå som Java, rent språkmässigt.

"... if these changes are made through the standards process and in specific implementations such as GCC and Visual Studio and so forth, all that's required then is that source code is recompiled. And development organizations will automatically pick up a lot of protections that are currently lacking in existing applications."

För egen del anser jag att ett av de största (säkerhets-)problemen i C är den manuella minneshanteringen och det kan man ju inte lösa med en ny kompilator. Å andra sidan kommer man nog långt på att rensa upp i pekararitmetiken och multipla anrop till free().

Säkerhet eller prestanda?
Att skriva säker kod tar i många fall (inte alla) längre tid än att skriva osäker kod. Och att följa upp varningar från kompilatorn eller något analysverktyg tar också tid. Därtill har man tiden det faktiskt tar att analysera koden.

Men om koden dessutom blir långsammare pga inkompilerade säkerhetskontroller så börjar det blir problematiskt. Robert har diskuterat med Microsoft där man är på gång att stänga av vissa default-inställningar i kompilatorn som syftar till högre säkerhet. Varför? Jo, de har fått en 200-300 % prestandaförsämring.

Här måste vi så klart hitta en balans.

"... part of this is coming up with solutions that have adequate performance and not trying to force overbearing solutions on developers. But part of this has to be developers being willing to accept some performance hit in order to drive down the number of vulnerabilities that they're deploying in their software."

Hela podcasten är 20 minuter -- lyssna här (mp3)
Det finns också en transkribering -- läs här (pdf)