On open source security

In the cur­rent deba­te about trus­ting soft­ware that uses cryp­to­gra­phic tech­ni­ques, the posi­ti­on that Open Source soft­ware is inher­ent­ly more trust­wor­t­hy than com­mer­cial soft­ware is repea­ted over and over again. While I per­so­nal­ly think that the free soft­ware move­ment has done a gre­at deal to advan­ce the sta­te of com­pu­ting and is among­st last century’s accom­plish­ments the human race can actual­ly be proud of, I do not fol­low the reaso­ning that having the source code to a spe­ci­fic cryp­to­gra­phic pro­duct available is any state­ment about its trust­wort­hi­ness, par­ti­cu­lar­ly in its secu­ri­ty or qua­li­ty of cryp­to­gra­phic processes.

One of the main dif­fe­ren­ces bet­ween medi­um-sized soft­ware endea­vors in com­mer­cial soft­ware com­pa­nies and the open source world is the adhe­rence to pro­ces­ses. Com­mer­cial soft­ware com­pa­nies have a rather clear chain of respon­si­bi­li­ty and defi­ned allo­ca­ti­on of resour­ces. This enables them to defi­ne spe­ci­fic pro­ces­ses that need to be adhe­red to in order to build their appli­ca­ti­on. Poten­ti­al­ly, this includes various stages of review and vali­da­ti­on (from basic design drafts to imple­men­ta­ti­on spe­ci­fics) or test­ing (from source-level unit tests to func­tion­al tests of parts and ulti­m­ate­ly, the full appli­ca­ti­on). Most free soft­ware pro­jects don’t have the luxu­ry of deve­lo­pers con­tri­bu­ting test sui­tes, or sharp minds having a chan­ce to review design spe­ci­fi­ca­ti­ons to under­stand the impact a spe­ci­fic chan­ge might have. 

Serious test­ing and qua­li­ty assu­rance takes time. The pro­cess of soft­ware test­ing is resour­ce inten­si­ve (eit­her you need qua­li­fied, good tes­ters or you need to have deve­lo­pers who keep the test­ing suite in sync with the pro­duct). And the release sche­du­le needs to accom­mo­da­te test­ing; this means lon­ger release cycles, slo­wing down the total deve­lo­p­ment speed. 

Whilst I am not say­ing that all com­mer­cial soft­ware ven­dors do stick to a rigid set of pro­ces­ses that insu­re their qua­li­ty, I think that they are in a bet­ter situa­ti­on to actual­ly fol­low through on such pro­ces­ses if they cho­se to ali­gn them­sel­ves with such goals. 

Also, as any­bo­dy who is invol­ved in com­pu­ter pro­gramming in a serious fashion will glad­ly tell you, dis­co­ve­ring bugs is hard work. It takes dedi­ca­ti­on (even stub­born­ness) to hunt through code to find tho­se situa­tions whe­re it does­n’t behave as inten­ded. Many a soft­ware pro­duct have suf­fe­r­ed from delays becau­se the­re were still cri­ti­cal bugs that had to be resol­ved. In the same vein, it is even har­der to spot chan­ges that are deli­bera­te­ly intro­du­ced to thwart spe­ci­fic aspects of the pro­duct whilst lea­ving most ever­y­thing else int­act. It requi­res very detail­ed know­ledge of the pro­gramming lan­guage and tools in use, the desi­ra­ble out­co­me, deep under­stan­ding of the algo­rith­ms invol­ved and a good set of tools to vali­da­te and veri­fy that things are as expected. 

This brings us to yet ano­ther new topic: trus­ting your con­tri­bu­tors. What moti­va­tes the per­son to bring about chan­ges to the appli­ca­ti­on? What kind of a skill set do they have, how deep is their under­stan­ding of the tech­ni­ques and tools? Open source pro­jects sel­dom­ly do deep back­ground checks on their con­tri­bu­tors, or rely on out­si­der infor­ma­ti­on about the peo­p­le behind pull requests. 

The next topic in that con­text is trus­ting your tools. The com­pi­ler that you use dai­ly, are you cer­tain that it does not alter your algo­rith­ms as it trans­forms your wri­tin­gs into ano­ther for­mat? The libra­ri­es that you link against (may­be even dyna­mi­cal­ly, making yours­elf trust any fur­ther chan­ges in tho­se libra­ri­es), what gua­ran­tees that you know all their func­tions, all of their side effects? Who is more likely to invest the signi­fi­cant resour­ces requi­red to build a trus­ted toolchain? 

Of cour­se, having source code available offers a num­ber of opti­ons for the users of that soft­ware. That includes deep and detail­ed inspec­tion and audits. But I think the rea­li­ty is that only very few, very sel­ect pro­ducts are ever pla­ced under such scr­uni­ty. And even then, the results can only be appli­ed to one very spe­ci­fic ver­si­on, in one very spe­ci­fic con­fi­gu­ra­ti­on. Any chan­ges would have to be sub­jec­ted to a simi­lar regi­men to have any signi­fi­can­ce in estab­li­shing the trust­wort­hi­ness of a codebase. 

Would you hazard a guess what the per­cen­ta­ge of code is that has been sub­jec­ted to such scru­ti­ny in the free ope­ra­ting sys­tem you’­re using? And how do you know you can trust the enti­ty that did tho­se audits? 

Unless you have clear ans­wers to both ques­ti­ons, open source soft­ware is not more trust­wor­t­hy than clo­sed source soft­ware is. Not less, eit­her. But also: not more. 


Beitrag veröffentlicht

in

von

Schlagwörter:

Kommentare

Eine Antwort zu „On open source security“

  1. Avatar von Stefan

    I do not see the pic­tu­re that dark: Do not over­ra­te „processes“ in so cal­led „professional soft­ware development”. 

    Clo­sed Source allows for pre­ten­ding the­re were secu­ri­ty audits, but for no one to check inde­pendent­ly (No, TÃœV bad­ges do not impress me). Open Source on the other hand allows for inde­pen­dent and repeata­ble audits. It is not that the­se audits have to take place real­ly, but that they could hap­pen any time, unex­pec­ted and by gifted peo­p­le from aca­de­mia. And while it takes experts to do that, the­re are some, and the num­ber of secu­ri­ty rela­ted pie­ces of soft­ware is limi­t­ed. So while i can­not audit the soft­ware i use mys­elf, i have solid trust that someone more capa­ble than me alre­a­dy did it, and would speak out loud if some­thing fishy would appear.

    In most com­pa­nies, the­re is no cul­tu­re of spea­king out loud things found in audits, but mere­ly sil­ent­ly fix them (if at all) in some future release.

    I for mys­elf pre­fer an Open Source pro­duct that is not audi­ted but could be any­ti­me wit­hout per­mis­si­on of some invol­ved par­ty over a Clo­sed Source pro­duct whe­re i have to belie­ve promises.

    But you are right in the fact that Open Source pro­ducts are not immu­ne to tin­ke­ring, and will never be.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert