Es ist eine komplexe Angelegenheit, da verschiedene Aspekte mit Vor- und Nachteilen zu berücksichtigen sind und es möglicherweise keine eindeutige Antwort gibt.

Der Sicherheitsvorteil von Open Source-Software soll von einem " Gesetz ", das Wikipedia" Linus 'Gesetz "nennt, das besagt, dass" bei genügend Augäpfeln alle Käfer flach sind ". Zunächst müssten Sie sich fragen, wie viele Augäpfel Sie haben werden. Wird Ihr Projekt beispielsweise geteilt, gespalten, von vielen Benutzern ausgiebig genutzt und von einer großen Community überprüft? Oder wird Ihre Software nur auf Ihrer Website verwendet und niemand anderes wird sich darum kümmern? Oder kann es sonst niemand wiederverwenden, weil es keine Lizenz für freie Software enthält? Am Ende wird es White-Hat-Augäpfel und Black-Hat-Augäpfel geben, also müssen Sie bereit sein zu akzeptieren, dass Sie einerseits eine gewisse Sicherheitsverbesserung durch ethische Hacker erhalten, andererseits aber auch angegriffen werden von schwarzen Hüten. Werden Angreifer besonders daran interessiert sein, auf Ihr Projekt abzuzielen, oder wird es nur nicht zielgerichteten Angriffen ausgesetzt sein? Dies sind alles Dinge, die Sie berücksichtigen sollten, und es ist möglicherweise nicht einfach, eine Schlussfolgerung zu ziehen. Es sei auch daran erinnert, dass es in mehreren Open-Source-Projekten Sicherheitslücken gab, die trotz aller Augäpfel der Community schon lange vorhanden waren (siehe Linus 'Gesetz auf Wikipedia).

Sicherheit durch Dunkelheit ist ein weiteres Konzept, das oft missverstanden wird, weil sein Name den Eindruck erweckt, dass es darum geht, etwas geheim zu halten. Es ist nicht so. Sicherheit durch Dunkelheit ist, wenn ein wesentlicher Teil Ihrer Sicherheit aus der Geheimhaltung der Methoden (der Implementierung) stammt. Hier ist ein Beispiel für Sicherheit durch Unbekanntheit:

  // Ohne Passwort anmelden, wenn die URL den Parameter dev = debug hat // Ich bin ein dummer Entwickler, daher glaube ich, dass dies sicher ist, weil niemand davon weiß !
// Aber dieser Quellcode kann nicht veröffentlicht werden oder ich werde sofort gehackt, wenn ($ login_password === $ password || $ _POST ['dev'] === 'debug') {login_ok ();}  

Selbst wenn Ihr Code korrekt ist und Sie sich auf Sicherheit verlassen, hindert Sie nichts daran, eine Verschleierungsebene darüber zu verwenden. Das heißt, wenn Sie den Quellcode privat halten, kann dies hilfreich sein, da dadurch ein potenzieller Angreifer verlangsamt wird. Das Wichtigste, an das Sie sich erinnern sollten, ist, dass Dunkelheit in Ordnung ist und nur dann als großer Vorteil angesehen werden kann, wenn es sich nur um eine Schicht über gutem Design handelt.

Abschließend würde ich sagen, dass Sie das besser nicht veröffentlichen sollten Quellcode, es sei denn, Sie haben einen Grund dazu (zum Beispiel, weil Ihre Software frei / frei sein soll und Sie eine Community rund um Ihr Projekt erstellen möchten). Wenn Ihr einziges Ziel darin besteht, die Sicherheit der Anwendung zu verbessern, erhalten Sie nichts, wenn Sie sie beispielsweise nur auf GitHub veröffentlichen. Wenn Sie wirklich befürchten, dass Ihre Software Fehler enthält, und Sie möchten, dass Ihnen jemand anderes hilft, indem er mehr "Augäpfel" bereitstellt, sollten Sie in Betracht ziehen, für ein professionelles Sicherheitsaudit zu zahlen.

Es ist wichtig zu lesen, was ich im Kontext geschrieben habe.

Ja, es gibt gelegentlich gültige Anwendungsfälle für Sicherheit durch Dunkelheit.

Dies wurde geschrieben als Antwort auf eine Frage zum Penetrationstest eines Black-Box-Systems, bei dem die Idee, dass die Quelle verfügbar ist, nicht einmal auf dem Tisch lag. In einem solchen Fall kann Sicherheit durch Dunkelheit einen gewissen Nutzen haben. In der Regel ist es jedoch nicht besonders nützlich, und wenn dies der Fall ist, ist nur als einzelner Teil einer umfassenderen Strategie zur Tiefenverteidigung nützlich. Sie können ein Ziel nicht angreifen, wenn Sie dies tun Ich weiß nicht, wo es ist, aber sobald der Böse weiß, was er anstrebt, sollten Sie auch andere Abwehrkräfte einsetzen, oder Sie werden den sprichwörtlichen Bach hinaufsteigen.

Auch --und zutreffender für diese Frage, bei der die Möglichkeit des Öffnens des Quellcodes in Betracht zieht - alle Vorteile, die Sie durch das Ausblenden der Quellen erzielen können, werden durch das Kerckhoff-Prinzip stark aufgewogen : "[Sie sollten immer davon ausgehen, dass] der Gegner das System kennt." Mit anderen Worten, wenn Sie Ihr System nicht als sicher betrachten können, wenn der Gegner über den vollständigen Quellcode verfügt, können Sie es nicht als sicher betrachten. (Was ist nur gesunder Menschenverstand; wie viel Vertrauen würden Sie in ein physisches Schloss setzen, in dem der Baumarkt Ihnen mitgeteilt hat, dass es wichtig ist, es zu verbergen, damit die Leute nicht sehen, um welche Art von Schloss es sich handelt?)

Wenn Sie beginnen mit der Annahme, dass der Gegner das System kennt - was in der realen Welt bedeutet, dass er dieses Wissen durch anderes Hacken, durch irgendeine Form von Spionage oder verschiedene andere Kompromisse erlangt hat -, dann folgt logischerweise das Veröffentlichen des Systems Code bringt ihm nichts Neues bei. Was es tut, ist, den Guten die Gelegenheit zu geben, aufzuholen: Ehrliche Leute, die niemals versuchen würden, Sie zu hacken oder Ihre Sicherheit zu gefährden, sind jetzt eingeladen, einen Blick darauf zu werfen und Orte aufzuzeigen, an denen es besser sein könnte.

Aus rein Cybersicherheitssicht ist die Veröffentlichung der Quelle ein klarer Gewinner gegenüber der Dunkelheit. Es kann andere Gründe geben, dies nicht zu tun (Schutz von Geschäftsmethoden oder anderen vertraulichen Informationen), aber es ist nicht einer von ihnen, Hacker besser fernzuhalten.

Sicherheit durch Dunkelheit ist keine schlechte Sache, sie ist einfach keine zuverlässige. Es sollte niemals Ihre Haupt- oder einzige Methode sein, etwas zu schützen. Es kann irreführend und illusorisch sein. Aber es hat immer noch einen gewissen Wert, zusätzlich zu anderen Methoden. Wenn Sie Ihre Plattform nicht kennen, kann dies einen Angreifer verlangsamen oder dazu führen, dass er mögliche Angriffswege verpasst. Insbesondere da das Gegenteil zutrifft, gibt es vorab geschriebene Stiftprüfwerkzeuge, die nacheinander bekannte Vulns anwenden. Warum riskieren, sie auszusetzen?

Der Ansatz "freundliche Augen" funktioniert unter Linux, da viele Leute Linux tatsächlich verwenden und ein Interesse daran haben, dass es weiterhin funktioniert. Gleiches gilt für Apache und was auch immer. Dies ist bei Ihrer Web-App wahrscheinlich nicht der Fall. Vermutlich entwickeln Sie Ihre Web-App für die spezifische Verwendung Ihres Unternehmens und nicht für ein allgemeineres Framework, das jeder in seine Website integrieren könnte. Es ist also unwahrscheinlich, dass Sie von Mitwirkenden profitieren.

Obscure 'em up! Und auch all die anderen, richtigen Sachen.

Es gibt einen wichtigen Unterschied zwischen der Veröffentlichung Ihres Codes und dem Versagen, Ihren Code vor dem Zugriff durch einen Exploit zu schützen.

Wenn Sie Ihren Code veröffentlichen, gibt es Blackhats, Greyhats und Whitehats mit Zugriff zu Ihrem Code. Die Whitehats enthüllen alle Schwachstellen, die sie entdecken, und Greyhats können sie offenlegen, wenn die Bug Bounty groß genug ist. Blackhats wird versuchen, Sie zu hacken, egal was passiert, und der veröffentlichte Code wird ihnen helfen. Daher besteht ein Kompromiss zwischen dem Nutzen, den Sie aus der Offenlegung von Sicherheitslücken ziehen können, und der Gefahr, dass Sicherheitslücken von Angreifern entdeckt werden. Dieser Kompromiss begünstigt jedoch häufig die Veröffentlichung.

Wenn Ihr Code durch einen Exploit aufgedeckt wird, haben meistens Blackhats Zugriff darauf. Wenn Schwachstellen auf diese Weise entdeckt werden, besteht eine viel geringere Wahrscheinlichkeit, dass sie verantwortungsbewusst offengelegt werden. Daher ist es sehr unwahrscheinlich, dass dieser Kompromiss zu Ihren Gunsten funktioniert.

Ich habe mehrere Open Source-Projekte entwickelt, darunter Digitalus CMS 2007-2012. Jetzt, da wir Tools wie NPM erstellt haben, bevorzuge ich einen Ansatz, bei dem ich bestimmte, allgemeinere Module teile, für die es so gut wie unmöglich wäre, geistiges Eigentum zu beanspruchen, und dann die endgültige Implementierung privat halte.

Dieser Ansatz ist für eine größere Bandbreite von Projekten einfacher anzuwenden und bietet Ihnen die Vorteile, Tausende von Augen auf Ihre Kernbibliotheken zu haben und gleichzeitig Ihre Kernanwendung zu schützen.