Qualität entsteht bei der Herstellung
In modernen Fertigungsbetrieben ist es fast schon selbstverständlich, dass der Entstehungsprozess jedes einzelnen Produktes komplett nachvollziehbar ist. Wenn Fehler in den verwendeten Materialien festgestellt werden, so können durch Dokumentationen gezielt die produzierten Chargen zurückgerufen werden, in welchem die fehlerhaften Bauteile eingesetzt wurden.
Wie häufig dies vorkommt, hat der Hersteller oft selbst in der Hand: Die Qualität der eingekauften Rohstoffe und der Fertigungsprozesse kann stark beeinflusst werden. Der Niedergang großer Teile der Automobilindustrie der USA in den 80er Jahren wird daher auch die großen Teilen einer hohen Mängeltoleranz in der Herstellung zugeschrieben. Die Qualität eines so produzierten Fahrzeuges konnte dadurch nie an die Qualität japanischer Fabrikate herankommen.
“You cannot inspect quality into a product”
Harold S. Dodge, Zitat aus Out Of The Crisis von W. Edwards Deming (1982)
Software-Qualität wird durch Bausteine bestimmt
Inwiefern werden solche Qualitätsansprüche auch bei der Software-Entwicklung eingehalten? Mit der Verwendung von Quellcodeverwaltungssystemen ist bereits ein guter Schritt in diese Richtung gegangen. Mit diesen Systemen lässt sich nachvollziehen, wie Software hergestellt wurde und welche Bausteine dabei verwendet wurden.
Analog zur Automobilindustrie, in welcher der Großteil der Fahrzeugproduktion über Zulieferer erfolgt und deren Ergebnisse nur zusammengebaut werden, besteht auch moderne Software zu einem Großteil aus kombinierten Fremdkomponenten. Und doch sind es gerade diese Komponenten, welche häufig besonderen Einfluss auf die Qualität und vor allem Sicherheit der produzierten Software haben. Eine Sicherheitslücke in Fremdkomponenten verursacht dabei oft einen Rückruf in der Form, dass neue Versionen der abhängigen Software bereitgestellt werden müssen. Im Fall von Cloud-Diensten kann dies sogar bedeuten, dass diese vorübergehehend komplett vom Netz genommen werden müssen. Denn die Zeit, bis Angriffswerkzeuge(Exploits) für Schwachstellen bereitstehen, sinkt kontinuierlich. Ebenso sollte man sich ständig bewusst sein, dass auch Fremdkomponenten bösartigen Code beinhalten können.
In der Praxis stellt meistens bereits die Identifikation der problematischen Komponenten die größte Hürde dar. Diese erfolgt dabei – wenn überhaupt – manuell und sehr spät nach der Veröffentlichung der Probleme. Deutlich wird dies beispielsweise, wenn man sich die Download-Zahlen von öffentlichen Quellen von Softwarekomponenten anschaut. Die Firma Sonatype hat dies für den von ihr verwalteten Teil des Maven-Repositories getan. Alamierend: Jeder achte Download auf der Platform betraf eine kompromittierte Komponente, bei welcher zum Zeitpunkt des Downloads Sicherheitslücken bekannt waren. Gleichzeitig gab es für diese Komponenten auch bereits neuere Versionen, welche die Fehler nicht mehr aufwiesen. Besonders erschreckend ist außerdem, dass der Anteil dieser problematischen Downloads sich in den letzten Jahren sogar noch gesteigert hat.
Entwickelt sich also trotz öffentlichwirksamen Schwachstellen wie Heartbleed kein Bewusstsein für diese Problematik? Die größte Herausforderung ist es vermutlich eher, dass die extrem hohe Anzahl der verwendeten Komponenten es schlicht unmöglich macht, diese manuell zu prüfen. Gleichzeitig steigt der Druck, in möglichst kurzer Zeit funktionstüchtige Software zu produzieren. Besonders wenn es keine klaren Regeln zur Verwendung von Open-Source-Komponenten gibt, kann es hier zu einer sehr großen Vielfalt in den Abhängigkeiten kommen. Auf der anderen Seite führen extrem strenge Vorgaben, beispielsweise mit wochenlangen Freigabeprozessen für neue Komponenten oder Versionen, zu einer starken Missachtung der Regeln und damit zu den gleichen Problemen.
Qualitätskontrolle für die eingesetzen Bausteine
Ein großer Teil der aufgezeigten Gefahren kann bereits mit vergleichsweise geringem Aufwand identifiziert und reduziert werden. Verschiedenste Hersteller bieten Lösungen an, mit welchen über automatische Analysen die verwendeten Fremdkomponenten geprüft werden können und eine Identifikation von Problemen ermöglicht wird. Als Beispiele hierfür seien Blackduck Software und WhiteSource Software genannt, sowie Sonatype als Autoren des genannten Berichtes. Ergänzend bieten sich wie bereits erwähnt Regeln zur Verwendung von Open-Source-Komponenten an, an welchen sich die Auswahl der Fremdkomponenten orientieren sollte.
Die Qualität der Software steigt durch diese Lösungen messbar an. Dies wird hauptsächlich dadurch erreicht, dass bereits das Veröffentlichen neuer Software-Versionen mit bereits bekannten Schwachstellen in den Abhängkeiten verhindert werden kann. In den Untersuchungen von Sonatype reduzierte sich dabei die durchschnittliche Angriffsfläche um 63%.
Auf Basis dieser Daten gilt es nun, bereits bei der Auswahl der verwendeten Fremdkomponenten in der Software-Entwicklung auf eine gesunde Basis zu setzen, und die Integrität dieser Bausteine auch konstant zu prüfen. Die Qualität der produzierten Anwendungen hängt entscheidend davon ab.
Abschließend sei an dieser Stelle noch darauf hingewiesen, dass auch der Gesetzgeber zu einem verantwortungsvollen Herstellungsprozess anhält. Kommt es beispielsweise aufgrund von Sicherheitslücken zum Verstoß gegen Datenschutzgesetze, so kann der Software-Hersteller bei einem fahrlässigen Entwicklungsprozess durchaus haftbar gemacht werden.
Als Inspiration für diesen Beitrag diente der Vortrag “The Data behind DevSecOps” von Derek E. Weeks auf der Bosch Connected World 2018. Für mehr Informationen zu den verwendeten Daten ist an dieser Stelle auch der volle “2017 state of the software supply chain report” von Sonatype zu empfehlen.