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­ci­al 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­n­ing 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 pro­ces­ses.

One of the main dif­fe­ren­ces bet­ween medi­um-sized soft­ware endea­vors in com­mer­ci­al soft­ware com­pa­nies and the open source world is the adhe­rence to pro­ces­ses. Com­mer­ci­al 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­nal 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­l­o­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­l­o­pers who keep the tes­ting sui­te 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, slo­wing down the total deve­lop­ment speed.

Whilst I am not say­ing that all com­mer­ci­al 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­ti­ons whe­re it doesn’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­be­r­a­te­ly intro­du­ced to thwart spe­ci­fic aspects of the pro­duct whilst lea­ving most ever­y­thing else intact. 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­rithms invol­ved and a good set of tools to vali­da­te and veri­fy that things are as expec­ted.

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­rithms 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 yours­elf trust any fur­t­her 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 trusted tool­chain?

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 esta­bli­shing the trust­wort­hi­ness of a code­ba­se.

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 ent­i­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.

Ein Gedanke zu „On open source security“

  1. I do not see the pic­tu­re that dark: Do not over­ra­te „pro­ces­ses“ in so cal­led „pro­fes­sio­nal soft­ware deve­lop­ment”.

    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 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 alre­ady did it, and would speak out loud if some­thing fishy would appe­ar.

    In most com­pa­nies, the­re is no cul­tu­re of speaking 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 pro­mi­ses.

    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.