- Säkerhet som process
- Proaktivt arbete
- Öppenhet för kritik
- Ansvar för förvaltning
Säkerhet är inte ett mål utan en ständigt pågående process. Du blir aldrig "klar" med säkerhet. I processen kan man vara reaktiv och proaktiv. Gällande den reaktiva delen så behöver man inte ta höjd för zero-day exploits eftersom de är rätt ovanliga idag. Vanligare är rapporter om krascher som kan vara tecken på säkerhetshål och rapporter från analysverktyg såsom Coverity eller Fortify.
Simon berättade att arbetet med att utreda en kraschrapport är så pass arbetsamt att han och de andra kärnutvecklarna inte alltid hinner med. Strategin har därför blivit att öppet bjuda in communityn att granska huruvida ett rapporterat fel har säkerhetsbärighet eller inte. Det betyder också att Simons säkerhetsarbete är mer öppet än Daniels arbete med libcurl.
Simons strategi har varit att tolka kraschrapporter konservativt, dvs att om det kan vara ett säkerhetshål så ska det hanteras så. Nackdelen är att stora organisationer som är beroende av din kod inte uppskattar den hållningen. För dem är en onödig säkerhetspatch en dyr historia.
#2 Arbeta proaktivt
Simon förordar öppna, tydliga kontaktvägar för att få mer information om problem. Att projektet är väl dokumenterat är också viktigt för att inflödet av feedback ska funka. Och med kvalitativ dokumentation menas en separat manual, inte bara kommenterad kod och projektwiki. Dra igång manualarbetet direkt även om det bara är en A4-sida. Då växer den organiskt.
Bidrag från communityn är viktiga men kräver lite mer än mottagande av kod. Simon kör konsekvent med copyright assignments på alla bidrag över tio rader kod. Sådana avtal reglerar att ett företag inte kan hävda copyright på ditt projekt bara för att person X arbetade för dem när X bidrog med kod. Dessutom poängterade Simon vikten av att faktiskt träffas i verkligheten och inte bara via nätet. Skaffa ansikten på kärntruppen så funkar samarbetet mycket bättre, även om det kräver en utomlandsresa eller två.
För att uppnå god kvalitet på koden så gillar Simon analysverktyg och metriker såsom cyklomatisk komplexitet och kodtäckning för enhetstester (det är inte utan att man minns sina gamla datalogitentor :). Manuell granskning är väldigt bra men dyrt i arbetstimmar. Och precis som Daniel så ser Simon storleken på funktioner som en mycket viktig faktor - små funktioner bra, stora funktioner dåligt.
Öppen källkod leder ofta till scratch your own itch vilket betyder att var och en patchar koden för egna husbehov. Enligt Simon leder det ofta till ruttnande design på sikt. Med för för små och isolerade bidrag så finns helt enkelt inte tid eller intresse för att förstå designen. Det är svårt att råda bot på men man bör vara medveten om fenomenet. Ett sätt att få fokus på styrningen av projektet är att ha bokade släpp, dvs så kallade timed releases. Inför ett bokat släpp skärper man upp projektet.
#3 Bjud in kritik
En fara inom fri mjukvara är att utvecklare inte alltid tar emot kritik på ett bra sätt. De är ofta är väldigt personligt involverade och lägger mycket prestige i sina projekt. Detta tillsammans med att säkerhetshål ofta hittas av okända personer som kanske aldrig bidrar med något mer kan leda till att kritik avfärdas eller behandlas styvmoderligt. Simon uppmanar till att bjuda in kritik och släppa på prestigen.
#4 Tag ansvar för koordinering av uppgraderingar/patchar
Bland det viktigaste för att uppnå kvalitet i mjukvara är att någon/några verkligen tar ansvar för att följa upp rapporterade problem och implementera och distribuera uppgraderingar och patchar. Tyvärr brister det i många fria mjukvaruprojekt. CERT-organisationer runt om i världen kan hjälpa till men de löser det inte nödvändigtvis, som Simon kunde visa med ett tydligt exempel. Samordningen i vendor-sec är tyvärr lite för sluten men kan hjälpa till att analysera om en rapporterad bugg verkligen är säkerhetsrelevant.
/John
Inga kommentarer:
Skicka en kommentar