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­worthy than com­mer­cial soft­ware is repeated 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 amongst last century’s accom­plish­ments the human race can actual­ly be proud of, I do not fol­low the rea­so­ning that having the source code to a spe­ci­fic cryp­to­gra­phic pro­duct avail­ab­le 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 enab­les them to defi­ne spe­ci­fic pro­ces­ses that need to be adhe­red to in order to build their app­li­ca­ti­on. Poten­ti­al­ly, this inclu­des various sta­ges of review and vali­da­ti­on (from basic design drafts to imple­men­ta­ti­on spe­ci­fics) or tes­ting (from source-level unit tests to func­tio­n­al tests of parts and ulti­mate­ly, the full app­li­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 tes­ting and qua­li­ty assuran­ce takes time. The pro­cess of soft­ware tes­ting 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 tes­ting suite in sync with the pro­duct). And the release sche­du­le needs to accom­mo­da­te tes­ting; this means lon­ger release cycles, slowing 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 align 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­vering bugs is hard work. It takes dedi­ca­ti­on (even stubborn­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­red 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­ber­ate­ly intro­du­ced to thwart spe­ci­fic aspects of the pro­duct whilst lea­ving most ever­ything else inta­ct. 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­t­her new topic: trus­ting your con­tri­bu­tors. What moti­va­tes the per­son to bring about chan­ges to the app­li­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 peop­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­tings into ano­t­her for­mat? The libra­ries that you link against (may­be even dyna­mi­cal­ly, making yourself trust any fur­ther chan­ges in tho­se libra­ries), 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 avail­ab­le offers a num­ber of opti­ons for the users of that soft­ware. That inclu­des deep and detail­ed inspec­tion and audits. But I think the rea­li­ty is that only very few, very select pro­ducts are ever pla­ced under such scru­ni­ty. And even then, the results can only be app­lied 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­worthy than clo­sed source soft­ware is. Not less, eit­her. But also: not more. 

Beitrag veröffentlicht





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 repeat­a­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 peop­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­ted. So while i can­not audit the soft­ware i use mys­elf, i have solid trust that someo­ne more capa­ble than me alrea­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 merely silent­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 without 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