Anders gefragt: Welches BSD hat die bestorganisierte bzw. effektivste Code-Review?
Dann hast sollte die Frage aber eher sein, welches BSD hat die meisten Bug-Reports, oder? Nur dass da neben dem Bug-Tracker auch Mailing Lists, etc. eingerechnet werden müsste. Effektiver Code-Review heißt ja vor allem auch immer mal wieder drüber zu gehen und nicht nur Patches zu begutachten. Regelmäßige Code-Audits, viele Leute die den Code verstehen und Bugs reporten sind ein sehr wichtiger Teil von effektivem Code-Review.
Nur wenn du Doku ausklammerst, dann ist halt wirklich die Frage was du unter Code-Review verstehst, also einfach weil falsche Dokumentation mitunter extrem kritisch sein kann. Wenn man annimmt, dass man das hat, was da in der Doku garantiert wird und dann ist es nicht so und irgendwann, wenn was schlimmes passiert ist heißt es sowas, wie "intentional Desgin", dann ist das oft deutlich schlimmer als, dass unter obskuren Umständen das Programm abstürzen und das vielleicht sogar dokumentiert ist oder es sogar eine Meldung abgibt, was ja auch immer wieder vorkommt. Das wird dann vielleicht als Bug mit niedriger Priorität gesehen, weil davor gewarnt wird, man vielleicht ein paar Schrauben drehen muss, damit man in die Situation wo das Problem auftritt kommen kann, aber ein Bug bleibt es trotzdem. Oder eben so Dinge, wo es Workarounds gibt, die man schon aus Gewohnheit macht, weil ein Zustand nicht erkannt wird. Dann kommt noch die Frage dazu, ob es ein Feature ist, dass das erkannt werden soll oder eben ein Bug, dass das nicht erkannt wird.
Leider ist die Definition von so solchen Dingen sehr, sehr schwer und es kommt zu subjektiven Meinungen und Situationen, die durch das Umfeld detoniert werden: Darf bzw. soll ein Programm mit einen Error (nicht unbedingt immer gleich ein segfault) beenden oder soll es trotzdem versuchen weiterzumachen? So eine Entscheidung hängt häufig vom Umfeld ab, wenn es dir um Durchsatz und Performance geht machst du manchmal weiter, handelst es noch einigermaßen, aber brichst nicht ab. Im Security-Bereich kann das ein schlimmer Fehler sein. Wenn das nicht dokumentiert ist, dann ist die fehlende Dokumentation für viele der wirklich Bug, denn sonst gehst du einfach von was bestimmten aus und je nach Einsatzbereich kann alles mögliche kritisch sein. Es gibt Anwendung, da ist Performance kritisch, manchmal hängt das sogar mit Security zusammen. Gerade wenn man an DoS-Attacken denkt ist es so, dass ein Performanceproblem in einem Fall, der im Normalbetrieb kaum vorkommt plötzlich ein Fall für deine Security wird.
Das mit der Doku geht auch anders rum: Spezifikationen. Was ist wenn der Fehler in einem Standard ist oder ein Standard aus sicherheitstechnischen Überlegungen absichtlich gebrochen wird? Ist das ein Bug, weil dein Protokoll-Stack den Standard verletzt und er somit keine valide Implementierung darstellt? Oder sagst du der Standard hat einen Bug? Aber was ist, wenn das nur gefährlich ist, weil man theoretisch vieles falsch machen könnte, man es aber auch "einfach" richtig, fehlerfrei implementieren könnte? Was ist, wenn die Doku darüber, dass du den Standard nicht ganz einhältst fehlt? Unter welchen Umständen zählt das?
Oder eben die Möglichkeit von falscher Konfiguration. Du kannst sicher viel Blödsinn machen, wenn du dich mit sysctls spielst. Ist das ein Bug, wenn es Nebeneffekte, die vielleicht nicht beachtet oder dokumentiert sind? Ist es ein Bug, wenn dein System-Update in speziellen Fällen fehlschlägt, die du aber explizit nicht nutzen sollst? Was ist wenn nicht klar ist, ob etwas zu einem Problem führen kann? Klar, auf den ersten Blick würde man sich denken, hey, selber schuld, wenn er Unfug damit treibt, aber dann muss man auch immer daran denken, dass ein Angreifer diesen Unfug durchaus treibt und vielleicht gerade ein komplexes Zusammenspiel vieler verschiedener Teile des Systems nutzt und es nur durch all diese Teile zum Auftreten eines Bugs kommen kann. Dann ist plötzlich ein Tool, das man einfach lokal verwendet um irgendwelche Daten gecached zu haben, damit Programm X schneller startet plötzlich der Grund, dass jemand über einen Remote-Angriff bestimmte Rechte erlangt.
Im Endeffkt ist es leider so, dass was man als kritischen Bug und Sicherheitslücke hat immer mal wieder genau sowas. Das ist nichts was man mit auf Patches schauen und Probleme in den Patches selbst findet, sondern mit Code-Review der vor allem auch nachdem Commit gelandet ist wenn möglich vor etwaigen Angreifern findet um einen Fix dafür zu releasen und unter die Leute zu bekommen. Klar, man könnte sagen, dann war es schon zu spät. Andererseits ist das echtes Code-Reviewing und reduziert die Anzahl der Bugs im System, während man woanders vielleicht viel mehr auf die einzelnen Patches/Commit schaut und deshalb vielleicht im großen Bild was übersieht, denn vieles wird ja auch erst sichtbarer, wenn man wirklich damit arbeitet und eben Stack X, Compiler Y und Konfiguration Z zusammen betrachtet, weil man es für die Anwendung gerade benötigt. Und da können Programmierer noch so gut sein, sie werden nicht das gesamte System in jeglicher Konfiguration durchdenken können und am Ende auch immer mal wieder Bugs einbauen und übersehen, denn die offensichtlichen findet man selbst, mit Tests, statischer Analyse oder jemand sobald es durch die Mailing List geht.
Und dann gibt es noch so Statistik-Sachen: Ist etwas ein Bug oder sind es zwei? Zählst du die Ursachen oder die Symptome?
Du kannst vielleicht hier Suchen nach den BSDs machen:
https://web.nvd.nist.gov/view/vuln/search
Das sind vor allem Sicherheitslücken also bei weitem nicht alle Bugs.
Nur die Frage, ob der Code-Review effektiv ist ist leider schwer, weil durch Reviews Bugs entdeckt werden, selbst wenn du einen Commit mit neuem Code schaust kannst du alte Fehler finden, vor allem wen der Review gut ist.
