Open-Source Lösungen modifizieren

Open-Source Lösungen modifizieren

Marc Ruef
by Marc Ruef
time to read: 3 minutes

Bei der Initiierung eines Software-Projekts stehen viele unserer Kunden vor der Frage, ob sie sich auf quelloffene Projekte oder auf kommerzielle Lösungen abstützen sollen. Gerade im Webbereich stehen eine Vielzahl unterschiedlicher Content Management Systeme mit verschiedenen Lizenzmodellen zur Verfügung.

Im Zuge des bestehenden Kostendrucks entscheidet sich so mancher Kunde dafür, auf eine freie Lösung zu setzen. Technische Mitarbeiter sehen darin oftmals weniger den kommerziellen Faktor als Killerkriterium, sondern die Möglichkeit, aufgrund der Offenheit der Lösung eigene Anpassungen einbringen zu können. Dadurch verspricht man sich ein hohes Mass an Flexibilität.

Selbstverständlich wird diesen Aspekten gut und gerne ein hohes Gewicht beigemessen. Dennoch vergisst man gerne in der treibenden Euphorie, dass Anpassungen an quelloffenen Projekten umfangreiche Abhängigkeiten mit sich tragen. Diese können und werden sich mittel- und langfristig ebenfalls negativ auf die Sicherheit einer Lösung auswirken.

Software-Development am Beispiel einer Webapplikation

Wird eine individuelle Anpassung an einem Produkt vorgenommen, erschliessen sich zwar neue Funktionalitäten. Gleichzeitig entfernt man sich aber vom offiziellen Release. Dies bedeutet, dass man vielleicht den Support des Produkts verliert. Zudem bedeutet dies aber ebenfalls, dass sich Patches unter Umständen nicht mehr ohne weiteres einspielen lassen. Ebenso grundlegende Produkt-Upgrades, die voraussichtlich alle eigenen Änderungen überschreiben würden.

Will man eigene Anpassungen an einer Lösung vornehmen, muss man die grundlegende Qualität einer allgemeinen Software-Entwicklung berücksichtigen. Damit lassen sich kleinere Anpassungen nicht mehr mal nebenher realisieren. Man braucht Entwicklungs- und Test-Systeme. Man braucht einen Prozess, um die Änderungen in die produktive Umgebung übertragen zu lassen. Man braucht eine Abnahme und einen Dokumentationsprozess. etc.

Je länger man ein Produkt betreut und sich durch die individuellen Anpassungen vom offiziellen Release entfernt, desto schwieriger wird es, sich am ursprünglichen Produkt zu orientieren. Sehr schnell hat man eigentlich eine eigene und mehr oder weniger eigenständige Lösung.

Jene Vorteile, die quelloffenen Produkten anhaften, gehen damit zwangsweise verloren. Denn so müsste man die eigenen Änderungen ebenfalls publik machen (ins ursprüngliche Projekt zurückfliessen lassen), um zum Beispiel von der Community profitieren zu können. Doch nur die wenigsten Unternehmen können diesem ideologischen Ansatz einen Vorteil abgewinnen. Zu gross wird die eigene Leistung eingeschätzt, die man dann nicht ohne finanzielle Entlöhnung teilen möchte.

Aus diesem Gründen ist so manches Unternehmen in monetärer Hinsicht mittel- und langfristig besser beraten, wenn es sich auf rein kommerzielle Lösungen verlässt. Im produktiven Betrieb wird Support und Stabilität gerne über Flexibilität, Transparenz und Ideologie gesetzt. Das ist sehr schade, denn werden quelloffene Lösungen richtig betrieben, können damit die Vorteile aller Herangehensweisen vereint werden.

About the Author

Marc Ruef

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

You need support in such a project?

Our experts will get in contact with you!

×
Specific Criticism of CVSS4

Specific Criticism of CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentication

Voice Authentication

Marc Ruef

Bug Bounty

Bug Bounty

Marc Ruef

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here