Jump to content

Das Microsoft-Dilemma


fuji-man

Empfohlene Beiträge

Werbung (verschwindet nach Registrierung)

Sicherheit ist keine Frage von Quelloffenheit.

 

Sicherheit in der Entwicklung entsteht (oder eben nicht) im Entwicklungsprozess und kann nicht nachträglich reingetestet werden.

 

Sicherheit beim Anwender entsteht durch a) Bereitstellen von Patches und B) regelmäßiges Einspielen.

 

Letzteres ist bei OpenSource schwieriger, da eine öffentlich bekannte Schwachstelle in einer Bibliothek oft in tausenden von Produkten auftaucht, und nicht jedes von denen sich darum schert.

Link zum Beitrag
Auf anderen Seiten teilen

  • Antworten 53
  • Created
  • Letzte Antwort

Letzteres ist bei OpenSource schwieriger, da eine öffentlich bekannte Schwachstelle in einer Bibliothek oft in tausenden von Produkten auftaucht, und nicht jedes von denen sich darum schert.

Braucht sich auch nicht darum scheren. Die Bibliothek wird gegen eine neue Version ausgetauscht und die "Produkte" sind automatisch korrigiert, ohne neu kompiliert werden zu müssen.
Link zum Beitrag
Auf anderen Seiten teilen

Braucht sich auch nicht darum scheren. Die Bibliothek wird gegen eine neue Version ausgetauscht und die "Produkte" sind automatisch korrigiert, ohne neu kompiliert werden zu müssen.

 

Es ist nicht immer alles dynamisch gelinkt, meistens sind es statische Anwendungen die FOSS Code im Bauch haben.

Das sind nicht nur komplette Komponenten, oft auch nur mehr oder weniger lange code snippets von StackOverflow ;)

 

Dann:

 

- muss der Entwickler seine Software weiterhin warten (wollen)

- er muss wissen welche FOSS Komponenten er nutzt (bzw. welche ggf. von anderen Komponenten inkludiert werden)

- er muss sich regelmäßig schlau machen ob es in den von ihm verwendeten Komponenten neue bekannte Schwachstellen gibt

- er muss seine Software dann updaten (was wegen des Testaufwands oft nicht geschieht)

- er muss die aktualisierte Software zum User bringen

- der User muss die neue Version nutzen

 

Das ist eine lange Kette von Abhängigkeiten die für große N nicht erfüllt wird.

Link zum Beitrag
Auf anderen Seiten teilen

Das hat weniger mit Steve Ballmer, als mit der Entwicklung des Internets und der damit verbundenen Möglichkeiten zu tun. Mit Betriebssystemen lässt sich kaum noch was verdienen, daher gab es Win10 ja auch geschenkt. Das große Geld macht man heute mit Cloud-Diensten wie Microsofts Azure und mit den Daten der Nutzer. Keine Probleme mehr mit Raubkopien, regelmäßig Geldeingang und Zugriff auf fremde Daten.

Alles richtig, ich habe Ballmer trotzdem erwähnt, weil er ja nunmal für den berühmten Satz "Linux is a cancer" steht, der ja wiederum auf die GPL rekurriert. Und diese Auffassung beschreibt schon ein Stück weit die MS-Doktrin seiner Zeit. Sein Nachfolger Nadella vollzog ja dann den Wandel hin zum Cloudgeschäft, was sicherlich einerseits der übergeordneten Entwicklung an sich geschuldet ist aber bestimmt auch damit zu tun hat, dass er ja schon in seiner Zeit bevor er CEO wurde, genau dieses Cloudbusiness verantwortet hat. Insofern wohl die richtige Personalie zur richtigen Zeit.

 

Link zum Beitrag
Auf anderen Seiten teilen

- muss der Entwickler seine Software weiterhin warten (wollen)

- er muss wissen welche FOSS Komponenten er nutzt (bzw. welche ggf. von anderen Komponenten inkludiert werden)

- er muss sich regelmäßig schlau machen ob es in den von ihm verwendeten Komponenten neue bekannte Schwachstellen gibt

- er muss seine Software dann updaten (was wegen des Testaufwands oft nicht geschieht)

- er muss die aktualisierte Software zum User bringen

- der User muss die neue Version nutzen

Abgesehen von dem Begriff FOSS betrifft dies doch auch jede Art von propriäterer Software, oder?

 

Wenn ich lese, dass die Entwickler von OpenBSD den Quellcode regelmäßig auf der Suche nach Schwachstellen auditiert, nach lizensiertem Quellcode absucht und diesen nach Möglichkeit ersetzt, den ganzen Quellcode aufgrund besserer Lesbarkeit nach ANSI C übersetzt und das gesamt Userland sehr eng mit dem Kernel verbunden ist, dann kommt dies weniger bei der Entwicklung einer Windows-Version oder Anwendung zur Sprache, obwohl dies ein guter Marketing-Punkt wäre.

Die Usability ist/war bei letzterem eben wichtiger.

Link zum Beitrag
Auf anderen Seiten teilen

Werbung (verschwindet nach Registrierung)

Abgesehen von dem Begriff FOSS betrifft dies doch auch jede Art von propriäterer Software, oder?

 

Wenn ich lese, dass die Entwickler von OpenBSD den Quellcode regelmäßig auf der Suche nach Schwachstellen auditiert, nach lizensiertem Quellcode absucht und diesen nach Möglichkeit ersetzt, den ganzen Quellcode aufgrund besserer Lesbarkeit nach ANSI C übersetzt und das gesamt Userland sehr eng mit dem Kernel verbunden ist, dann kommt dies weniger bei der Entwicklung einer Windows-Version oder Anwendung zur Sprache, obwohl dies ein guter Marketing-Punkt wäre.

Die Usability ist/war bei letzterem eben wichtiger.

 

Aber ja.

 

Bei OpenSource, bzw. Produkten die bekanntermaßen auf OpenSource aufsetzen, ist eben die Sichtbarkeit höher.

 

Bei quasi allen Cloud-Anwendungen liegt massig Open Source zugrunde, d.h. da kann ich Schwachstellen schneller und leichter sehen. Das hat nichts damit zu tun dass Closed Source sicherer wäre.

Link zum Beitrag
Auf anderen Seiten teilen

Propriätere Software kann natürlich ebenso per Disassembler oder Untersuchung von Eintrittspunkten abgetastet werden. Durch Eingabe von Daten, die den vordefinierten Bereich sprengen, können so auch Abstürze provoziert werden, die zu Sicherheitslücken führen könnten.

Für viele Dinge braucht man den Quellcode garnicht.

Link zum Beitrag
Auf anderen Seiten teilen

Sicherheit ist keine Frage von Quelloffenheit.

 

Sicherheit in der Entwicklung entsteht (oder eben nicht) im Entwicklungsprozess und kann nicht nachträglich reingetestet werden.

Du gehst von einer idealen Welt aus, in der Menschen keine Fehler machen. Ja, Quelloffenheit bedeutet nicht automatisch mehr Sicherheit, sondern wie man mit Fehlern umgeht. Jeder Programmierer ist auch nur ein Mensch, der Fehler macht. Wir reden nun mal von sehr komplexen Systemen.

Die Frage ist, wie man solche Fehler aufdeckt und wie man dann damit umgeht.

Ich denke, bei M$ gäbe es nicht so viele Zero-Day-Bugs, die erst Jahre später gefunden werden, wenn der Quellcode für alle einzusehen wäre.

 

Sicherheit beim Anwender entsteht durch a) Bereitstellen von Patches und :cool: regelmäßiges Einspielen.

 

Letzteres ist bei OpenSource schwieriger, da eine öffentlich bekannte Schwachstelle in einer Bibliothek oft in tausenden von Produkten auftaucht, und nicht jedes von denen sich darum schert.

Dieses Argument verstehe ich nicht. Das Einspielen von Patches gilt doch als guter Tipp bei Closed- und Open-Source. Bei Linux werden Patches entweder durch Upgrade der Distribution, einen neueren Kernel oder durch den Paketmanager bewerkstelligt. Also genau so, wie bei M$ oder Apple, nur dass da die Begriffe andere sind. Das Prinzip ist das Gleiche und genau so einfach oder schwer zu bedienen.

 

Selbst wenn sich der Programmierer eines Open-Source-Projekts nicht mehr darum kümmert, so dass eine Schwachstelle ungepatcht bleibt, kann sich ganz legal jemand anders darum kümmern, weil eben Open-Source. Wenn M$ keinen Bock aufs Patchen hat, wie z.B. bei Skype, dann bleibt es eben ungepatcht. Dieser Prozess wird sogar bewusst in Kauf genommen, weil man so Kunden zum Kauf seiner neuen Produkte "anregen" möchte.

 

Mein derzeit noch größeres Sorgenkind ist Android. Wobei nicht Android selbst, sondern die Hersteller von Smartphones, die ihre Produkte nur sehr kurz supporten. Google hat das Problem verstanden und steuert nun mit Project Treble dagegen. DOch auch dagegen sträuben sich die Smartphone-hersteller, weil das unter Umständen bedeutet, dass die Menschen ihre Produkte länger als 2 Jahre nutzen würden. Alternativ kann man sich eine Custom-ROM, wie z.B. LineageOS installieren, da hat man keine Probleme mit Patches.

 

BTW: Die Rolle rückwärts bei vielen Behörden ist nicht technisch sondern politisch motiviert.

Link zum Beitrag
Auf anderen Seiten teilen

Du gehst von einer idealen Welt aus, in der Menschen keine Fehler machen. Ja, Quelloffenheit bedeutet nicht automatisch mehr Sicherheit, sondern wie man mit Fehlern umgeht. Jeder Programmierer ist auch nur ein Mensch, der Fehler macht. Wir reden nun mal von sehr komplexen Systemen.

Die Frage ist, wie man solche Fehler aufdeckt und wie man dann damit umgeht.

Ich denke, bei M$ gäbe es nicht so viele Zero-Day-Bugs, die erst Jahre später gefunden werden, wenn der Quellcode für alle einzusehen wäre.

 

Nein, davon gehe ich nicht aus. Das würde meiner täglichen Arbeit tangential widersprechen ;)

 

Und meine Aussage sind _gerade_ für Firmen wie MS zutreffend. 

 

 

 

Selbst wenn sich der Programmierer eines Open-Source-Projekts nicht mehr darum kümmert, so dass eine Schwachstelle ungepatcht bleibt, kann sich ganz legal jemand anders darum kümmern, weil eben Open-Source. 

 

Es geht um irgendwelche Anwendungen, die zur Zeiteinsparung Open Source nutzen, sich aber anschliessend nie wieder darum kümmern ob es da Probleme gibt. Oft weiss kein Mensch dass eine spezielle Open Source überhaupt verbaut ist.

Es gibt Tools um das herauszufinden, aber die muss man bewusst anwenden und lizensieren, und das tut bei Weitem nicht jeder.

 

Und "kann sich jemand anderes kümmern" - wer bitte geht jetzt hier von einer idealen Welt aus?? :D

 

 

Wenn M$ keinen Bock aufs Patchen hat, wie z.B. bei Skype, dann bleibt es eben ungepatcht. Dieser Prozess wird sogar bewusst in Kauf genommen, weil man so Kunden zum Kauf seiner neuen Produkte "anregen" möchte.

 

Das ist schlichterdings Unfug. 

https://www.theregister.co.uk/2018/02/15/microsoft_skype_fixed/

Link zum Beitrag
Auf anderen Seiten teilen

Open Source ist keine Garantie für Fehlerunanfälligkeit. Allerdings hat die Closed-Source-Politik eines "security-by-obscurity" gewisse Nachteile. Wie oben schon jemand richtig sagte: nicht alle Schwachstellen werden öffentlich gemacht, und es kann Schwachstellen geben, die weder MS noch der Community bekannt sind, die jedoch irgendwann völlig überraschend ausgenutzt werden. Es ist also durchaus möglich, dass closed source dazu führt, dass Schwachstellen - wegen fehlender Möglichkeit zur Code-Inspektion - nicht oder später gefunden werden als bei open source.

 

Etwas anderes kommt hinzu. Linux und auch Apple OS lassen alles, was mit Internet zu tun hat, primär in einer sogenannten "Sandbox" laufen. Das ist eine abeschottete, gesicherte Umgebung, in der die Manipulation systemwichtiger Dateien deutlich erschwert wird. Dagegen ist es leider eine Eigenart von MS, aus Tradition heraus den IE sowie etliche andere Applikationen sehr tief ins System hineinzuverstricken. Kompromittiert man also den IE, hat man oft Zugriff auf wichtige Systemkomponenten.

 

Auch Mozilla Firefox hatte schon diverse Schwachstellen, aber der Browser ist open source, und man hat schon den Eindruck, dass Schwachstellen schnell und zuverlässig gefixt werden. Außerdem fehlt hier die tiefe Verstrickung der Applikation ins System, trotzdem ist der Browser mindestens genauso schnell wie der IE.

 

Man gewinnt dann auch noch deutlich an Sicherheit, wenn man den Firefox mit "NoScript" abdichtet. Ein m.E. sehr empfehlenswertes Plugin. Das Teil schaltet Skripte (Javascript, Java) nur separat für die Webseiten frei, wo es der User erlaubt und denen er vertraut. Also z.B. dieses Forum hier, welches Javascript ja auch wegen des Foreneditors braucht. Oder für Online-Banking und sonstige wichtige Seiten.

 

Für alle andere Seiten bleibt Javascript dann erst einmal schön draußen. Vorteil: zum einen lädt er dann vieles von dem ganzen Werbe- und Popup-Bling-Bling nicht mehr. Zum anderen ist es halt einfach so, dass leider der größte Teil an Browser-Schwachstellen (und zwar egal ob IE oder Firefox...) auf Javascript basiert. Sperrt man also Javascript aus für die Seiten, wo man es nicht unbedingt braucht, gewinnt man statistisch nochmal eine ganze Menge an Sicherheit.

 

Absolute Sicherheit gibt es nicht. Aber mit einem abgedichteten Firefox sowie mit vernünftigem Surf-Verhalten (also nicht auf alles klicken, was klickipunt oder nackt ist oder beides, und nicht jeden dämlichen e-mail-Anhang öffnen...) ist auch mit einem Windows-PC die statistische Wahrscheinlichkeit, sich was zu fangen, extrem gering - wenn der Rechner vernünftig gepatcht wird.

 

Vor allem: Finger weg von Adobe Flash. Das Teil ist absolut Super-Pfui bezüglich PC-Sicherheit. Schwachstellen immer neue so ungefähr im Wochenturnus. Der Mist kommt mir hier nicht auf den Rechner. Und ein Webdesigner, der immer noch der Meinung ist, zwingend Flash für die Seite zu brauchen, der soll m.E. nach Hause gehen.

 

Man kann auch mit Android hervorragend leben, wenn man nicht jede dämliche Bling-Bling-app aus dubiosen Quellen herunterlädt und installiert. Hier hat das iPhone den Vorteil, dass bei nicht jail-gebreakten Geräten nur Apps aus geprüften Quellen installiert werden können - aus dem zertifizierten app-store. Wäre das nicht so, dann gäbe es für iPhone mindestens genauso viele Exploits und Handyviren wie für Android.

Link zum Beitrag
Auf anderen Seiten teilen

.... Welche Daten zu welchem Zweck im Hintergrund gezogen werden und wo sie dann landen, weiß auch nur M$. Die Hardware und Software sind dann nicht mehr das Produkt, sondern der Nutzer bzw. die Daten, die er produziert, sind das Produkt. Hard- und Software sind dann nur noch der Köder.

 

eigentlich nicht:

 

https://docs.microsoft.com/en-us/wi...ic-level-windows-diagnostic-events-and-fields

https://docs.microsoft.com/en-us/wi...stic-data-windows-analytics-events-and-fields

https://docs.microsoft.com/en-us/wi...vel-windows-diagnostic-events-and-fields-1703

 

Microsoft hat sich (und das zu Recht) Kritik div. Datenschützer anhören müssen. Mittlerweile sind sie erstens sehr transparent und haben (meines Wissens nach) mittlerweile keine Probleme mehr.

Im Gegenteil, sie sind sehr aktiv, um Firmen bei der Umsetzung des GDPR zu unterstützen und bieten Schulungen, Support, Tools etc.. an.

Link zum Beitrag
Auf anderen Seiten teilen

Es ist nicht immer alles dynamisch gelinkt, meistens sind es statische Anwendungen die FOSS Code im Bauch haben.

Wer so programmiert, gehört mit dem nassen Handtuch... - das ist einfach blamabel. Und nachdem der Source-Code von allen einsehbar ist, ist diese Blamage auch öffentlich. Im Gegensatz zu nicht Open-Source-Produkten, die sich heimlich an Open-Source bedienen. Die müssen den dann wirklich statisch einbinden, damit sie nicht gleich auffliegen.

 

Und wenn der Programmierer eines Open-Source-Produktes keinen Bock mehr hat, kann ein anderer übernehmen. Und wenn die Software brauchbar ist und auch gebraucht wird, dann passiert das auch. Wenn über die entsprechenden Portale Fehler gemeldet werden und es Lösungen gibt, der Urheber aber gerade nicht erreichbar ist, passiert es oft genug, dass einfach die Betreuer der Distribution kurzerhand Änderungen machen, ode Korrekturen der Anwender einarbeiten, bevor sie die Pakete neu erstellen.

Link zum Beitrag
Auf anderen Seiten teilen

Das stimmt. Die Politik war das Gejammer der Anwender leid.

 

Nun, ich arbeite hauptberuflich in einer (sehr) großen Behörde. Sofern man einen Restbezug zur Realität hat, relativiert sich da dieses Gejammere von Anwendern über Software und/oder Arbeitsprozesse schnell und entpuppt sich oft vielmehr als bloßer Unwille, jegliche - auch noch so kleine - Änderung gewohnter Abläufe zu akzeptieren bzw. damit konstruktiv umzugehen.

Link zum Beitrag
Auf anderen Seiten teilen

Wer so programmiert, gehört mit dem nassen Handtuch... - das ist einfach blamabel. Und nachdem der Source-Code von allen einsehbar ist, ist diese Blamage auch öffentlich. Im Gegensatz zu nicht Open-Source-Produkten, die sich heimlich an Open-Source bedienen. Die müssen den dann wirklich statisch einbinden, damit sie nicht gleich auffliegen.

 

Und wenn der Programmierer eines Open-Source-Produktes keinen Bock mehr hat, kann ein anderer übernehmen. Und wenn die Software brauchbar ist und auch gebraucht wird, dann passiert das auch. Wenn über die entsprechenden Portale Fehler gemeldet werden und es Lösungen gibt, der Urheber aber gerade nicht erreichbar ist, passiert es oft genug, dass einfach die Betreuer der Distribution kurzerhand Änderungen machen, ode Korrekturen der Anwender einarbeiten, bevor sie die Pakete neu erstellen.

 

Alles schön und gut, aber die Realität ist halt anders.

 

Der Vortrag verdeutlicht das ganz nett: 

 

Link zum Beitrag
Auf anderen Seiten teilen

@HERBERT-50: Windows hatte halt einen großen Startvorteil, indem es damals auf DOS aufsetzte, und das blieb dann űber 10 Jahre lang so. DOS User(und DOS war halt damals schon marktführend) mußten also nicht "hart" umsteigen, sondern konnten ihre gewohnte Softwareumgebung weiter nutzen und starteten den "grafischen Betriebssystem-Aufsatz" (Produktbezeichnung bis einschließlich Version 3.0) Windows zunächst nur bei Bedarf , bzw. nutzten die DOS-Box, wenn die Hardware Ressourcen das hergeben.

Sowas ging halt mit Linux (das erst 1991 kam und nochmals erst viel später eine GUI bekommen hat) oder gar auf MacOS zunächst gar nicht und später bestenfalls sehr schlecht über Emulatoren.

 

OS/2 war da schon eine andere Hausnummer, mit seiner nahezu perfekten DOS und Windows 3.1 Emulation und einer wirklich guten eigenen API und GUI. In der Theorie zumindest, aber IBM hat es nach allen Regeln der Kunst versaut. Die frühen Versionen hakten an allen Ecken und Enden, der Ressourcenverbrauch war angesichts des dem User dabei vermittelbaren Mehrwerts ("sieht aus wie DOS aber braucht nen viermalsoteuren Rechner") einfach nur aberwitzig, das Marketing war durchweg grausam, und als man dann endlich die Kurve bekam und mit Warp bzw. Warp Connect eine nicht nur erstmals endkundentaugliche, sondern abgesehen von einigen kleineren Inkompatibiliäten wirklich sehr rund laufende Version am Start hatte, war der Zug längst abgefahren.

 

Daran änderten dann auch das quasi Verschenken und die Gratisbeilage zu Billigheimer-PCs nichts mehr, letzteres fiel sogar den beteiligten Händlern letztendlich auf die Füße, in Form von schlechteren Konditionen als man da doch noch auf Windows umschwenkte.

 

War wirklich schade, ich hatte noch Mitte der 90er meine Fidonet Mailbox unter OS/2 laufen, als Hintergrundtask auf einem meiner Bürorechner, und man konnte auf dem parallel noch sehr gut arbeiten.

 

Auch die ursprünglich mal mit DOS laufende EDV bei mehreren Kunden hatte ich noch bis teils kurz vor die Jahrtausendwende via OS/2 praktisch "windowsfrei" gehalten, aber irgendwann ging es halt beim besten Willen nicht mehr.

Link zum Beitrag
Auf anderen Seiten teilen

Hm, was soll uns das sagen?

 

Dass man dem Vortrag mit Skepsis folgen sollte. Ich sehe es als Werbung für die eigene Firma: SourceClear

 

Ganz allgemein ging es in dem Video aus dem ersten Beitrag aber nicht primär um Microsoft vs. Open-Source, sondern darum, dass Microsoft die Regierungen und Verwaltungen in der Hand hat und mit ihnen macht, was Microsoft will.

Link zum Beitrag
Auf anderen Seiten teilen

Dass man dem Vortrag mit Skepsis folgen sollte. Ich sehe es als Werbung für die eigene Firma: SourceClear

 

Ganz allgemein ging es in dem Video aus dem ersten Beitrag aber nicht primär um Microsoft vs. Open-Source, sondern darum, dass Microsoft die Regierungen und Verwaltungen in der Hand hat und mit ihnen macht, was Microsoft will.

 

Interessante Lesart. Da steht "Ist Open Sourc Software wirklich eine Alternative?" nach Bericht über Schwachstellen in Microsoft, die von WannaCry genutzt wurden.

 

Ich kann natürlich jeden Vortrag, der vom Angestellten irgendeiner Firma gehalten wird, als Werbung für ebendiese Firma abtun. Oder man beschäftigt sich halt mal mit dem Inhalt. 

Link zum Beitrag
Auf anderen Seiten teilen

Nun ja, vom eigenen Standpunkt gesehen, wird z.B. ein Oracle-Mitarbeiter oder einer, der mit Oracle verbandelt ist, wird immer die Vorteile der eigenen Datenbank heraus stellen. Es gab gerade sogar die Ankündigung, dass Admins zur Optimierung der nächsten Datenbank-Version nicht mehr benötigt werden (was MS schon zu SQL 2005 behauptet hatte).

 

Ein MS-Mitarbeiter wird in einem Vortrag heraus stellen, dass die Performance von 'SQL 2017 auf Linux' alles andere schlagen wird, was nicht ausschließlich im Hauptspeicher läuft. Alles jetzt etwas übertriebene dargestellt, aber man kennt die Marketing-Leute ja.

 

Solange ich nicht selbst beide Systeme im produktiven Einsatz als Vergleich sehe, kann ich keine Aussage treffen, weiß aber, dass die Hersteller alle nur "mit Wasser kochen" und natürlich verkaufen wollen (wo das Geld eben hinfließt).

 

Nach dem BSI existieren gerade übrigens keine offenen Schwachstellen in Open Source (Linux) oder proprietären Betriebsystemen:

https://www.cert-bund.de/schwachstellenampel

Die Anzahl der veröffentlichten ist vergleichbar.

Link zum Beitrag
Auf anderen Seiten teilen

Nach dem BSI existieren gerade übrigens keine offenen Schwachstellen in Open Source oder proprietären Betriebsystemen:

https://www.cert-bund.de/schwachstellenampel

Die Anzahl der veröffentlichten ist vergleichbar.

 

Abzüglich der Dinge die noch in der responsible disclosure Periode sind, und die die Tavis Ormandy heute morgen unter der Dusche eingefallen sind ;)

 

https://www.cvedetails.com/vulnerability-list/vendor_id-26/Microsoft.html

 

Aber genau das ist ja der Punkt: Es gibt nicht so etwas wie 100% Sicherheit, es geht darum wie schnell ein Hersteller reagiert, und wie schnell Patches beim Anwender wirksam werden. In der Beziehung ist Microsoft schon deutlich besser geworden.

 

Ist natürlich immer schön auf große Anbieter einzutreten, aber man muss auch die Anzahl der Schwachstellen in Relation zur Codebasis setzen. 

Link zum Beitrag
Auf anderen Seiten teilen

Ist natürlich immer schön auf große Anbieter einzutreten, aber man muss auch die Anzahl der Schwachstellen in Relation zur Codebasis setzen.

Bezüglich Zahlen: hier wird ein Sicherheitsreport zu Open Source veröffentlicht, der über Jahre läuft:

https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-software-scan-report.html

 

Linux liegt dabei mit etwa einem Durchschnittswert von 0.47 'Defekten' pro 1000 Zeilen Programmcode. Ein Programmpaket wie Postgresql liegt je nach Version bei 0.05-0.1 'Defects' pro 1000 Zeilen Programmcode.

 

Von Windows 10 konnte ich keine Vergleichswerte finden, aber eine Behauptung ging dahin, dass sich im Vergleich zu Windows 7 die non-feature-Updates für Windows 10 verdoppelt hätten, was auf eine Verschlechterung der Defect Density hindeuten würde.

Link zum Beitrag
Auf anderen Seiten teilen

Interessante Lesart.

Der Titel hier ist: "Das Microsoft Dilemma" und das ist auch der Titel, des im Eingangsbeitrag verlinkten Videos. Dieses hat als Begleittext:

 

"Wanna Cry" war ein Weckruf: Die Cyber-Attacke mit dem Erpressungstrojaner traf im Mai 2017 hunderttausende Rechner in über 100 Ländern. Dass ein Schadprogramm so eine Schlagkraft entwickeln kann, liegt auch an Microsoft.

Die Frage, ob Open-Source eine Alternative ist, ist in dem Zusammenhang eigentlich nicht die richtige Frage. Die eigentliche Frage wäre, warum man die "Weltherrschaft" Microsofts einfach so widerstandslos hinnimmt?

Link zum Beitrag
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

×
×
  • Neu erstellen...