On open source security

In the cur­rent debate about trus­ting soft­ware that uses cryp­to­gra­phic tech­ni­ques, the posi­tion that Open Source soft­ware is inher­ently more trust­wor­thy than com­mer­cial soft­ware is repea­ted over and over again. While I per­so­nally think that the free soft­ware move­ment has done a great deal to advance the state of com­pu­ting and is amongst last century’s accom­plish­ments the human race can actually 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­able is any state­ment about its trust­wort­hi­ness, par­ti­cu­larly in its secu­rity or qua­lity of cryp­to­gra­phic processes.

One of the main dif­fe­ren­ces bet­ween medium-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 responsi­bi­lity and defined allo­ca­tion of resour­ces. This enab­les them to define spe­ci­fic pro­ces­ses that need to be adhe­red to in order to build their app­li­ca­tion. Poten­ti­ally, this inclu­des various sta­ges of review and vali­da­tion (from basic design drafts to imple­men­ta­tion spe­ci­fics) or tes­ting (from source-level unit tests to func­tio­nal tests of parts and ulti­mately, the full app­li­ca­tion). Most free soft­ware pro­jects don’t have the luxury of deve­l­o­pers con­tri­bu­ting test sui­tes, or sharp minds having a chance to review design spe­ci­fi­ca­ti­ons to under­stand the impact a spe­ci­fic change might have.

Serious tes­ting and qua­lity assurance takes time. The pro­cess of soft­ware tes­ting is resource inten­sive (eit­her you need qua­li­fied, good tes­ters or you need to have deve­l­o­pers who keep the tes­ting suite in sync with the pro­duct). And the release sche­dule needs to accom­mo­date 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­cial soft­ware ven­dors do stick to a rigid set of pro­ces­ses that insure their qua­lity, I think that they are in a bet­ter situa­tion to actually fol­low through on such pro­ces­ses if they chose to align them­sel­ves with such goals.

Also, as any­body who is invol­ved in com­pu­ter pro­gramming in a serious fashion will gladly tell you, dis­co­ve­r­ing bugs is hard work. It takes dedi­ca­tion (even stub­born­ness) to hunt through code to find those situa­ti­ons where it doesn’t behave as inten­ded. Many a soft­ware pro­duct have suf­fe­red from delays because there 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­ra­tely 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 detailed know­ledge of the pro­gramming lan­guage and tools in use, the desi­ra­ble out­come, deep under­stan­ding of the algo­rithms invol­ved and a good set of tools to vali­date and verify 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 app­li­ca­tion? 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­domly do deep back­ground checks on their con­tri­bu­tors, or rely on outs­ider infor­ma­tion about the people behind pull requests.

The next topic in that con­text is trus­ting your tools. The com­pi­ler that you use daily, are you cer­tain that it does not alter your algo­rithms as it trans­forms your wri­t­ings into ano­ther for­mat? The libra­ries that you link against (maybe even dyna­mi­cally, making your­self trust any fur­ther chan­ges in those 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 course, having source code avail­able offers a num­ber of opti­ons for the users of that soft­ware. That inclu­des deep and detailed inspec­tion and audits. But I think the rea­lity is that only very few, very select pro­ducts are ever pla­ced under such scrunity. And even then, the results can only be applied to one very spe­ci­fic ver­sion, in one very spe­ci­fic con­fi­gu­ra­tion. Any chan­ges would have to be sub­jec­ted to a simi­lar regi­men to have any signi­fi­cance in esta­blis­hing the trust­wort­hi­ness of a codebase.

Would you hazard a guess what the per­cen­tage of code is that has been sub­jec­ted to such scru­tiny in the free ope­ra­ting sys­tem you’re using? And how do you know you can trust the entity that did those audits?

Unless you have clear ans­wers to both ques­ti­ons, open source soft­ware is not more trust­wor­thy 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­ture that dark: Do not over­rate „pro­ces­ses“ in so cal­led „pro­fes­sio­nal soft­ware development”.

    Clo­sed Source allows for pre­ten­ding there were secu­rity audits, but for no one to check inde­pen­dently (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 these audits have to take place really, but that they could hap­pen any time, unex­pec­ted and by gif­ted people from aca­de­mia. And while it takes experts to do that, there are some, and the num­ber of secu­rity rela­ted pie­ces of soft­ware is limited. So while i can­not audit the soft­ware i use mys­elf, i have solid trust that someone more capable than me alre­ady did it, and would speak out loud if some­thing fishy would appear.

    In most com­pa­nies, there is no cul­ture of speaking out loud things found in audits, but merely silently 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 anytime wit­hout per­mis­sion of some invol­ved party over a Clo­sed Source pro­duct where i have to believe promises.

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

Schreib einen Kommentar

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