Doppelte Absicherung

Iterative Software-Entwicklung weiter stärken

| Autor / Redakteur: Mark Warren* / Stephan Augsten

Für eine sichere sgile Software-Entwicklung benötigt man eine möglichst gute Risikobewertung.
Für eine sichere sgile Software-Entwicklung benötigt man eine möglichst gute Risikobewertung. (Bild: Perforce Software)

Neue Software-Versionen werden dank iterativer Entwicklung in kürzeren Abständen bereitgestellt und Bugs so schneller beseitigt. Doch wenn neue Releases und Patches seltener installiert werden können oder sollen, hilft das nur wenig. Das Problem muss an der Wurzel gepackt werden, nämlich im Entwicklungsprozess.

Software schnell auf den Markt bringen und Änderungen in kurzfristigen Zyklen implementieren zu können, ist für viele Anwendungsentwickler heutzutage essentiell. In nahezu allen Branchen stellen Unternehmen ihre Lösungen in immer kürzeren Abständen bereit, Kundennutzen und Bedienkomfort stehen im Vordergrund.

Ob man dies nun „Continuous Delivery“ nennt, „Continuous Deployment“ oder „iterative Entwicklung“ – dieser Bereitstellungsansatz verändert das Wesen der Softwarebranche rasant und beeinflusst zunehmend unseren (Arbeits-)Alltag. Stellen wir uns nur einmal die Menge an Softwareupdates vor, die ein Online-Händler wie Amazon haben muss.

Vermutlich sind die meisten von uns auch im Privatleben mit einer steigenden Anzahl an Updates konfrontiert. Nicht selten werden diese mittlerweile sogar täglich für unsere Desktop-PCs, Laptops, Tablets oder Smartphones zur Verfügung gestellt.

Kleiner Bug, große Wirkung

Ein revolutionärer Ansatz zur Softwareentwicklung bringt allerdings auch seine Herausforderungen mit sich. Zunächst einmal beschränkt ein enger Veröffentlichungstakt mit kleinen Updates den Wirkungsradius der Änderungen potenziell – denn in der Theorie sind die Bugs „kleiner“ und leichter zu entdecken.

Falls aber ein Bug oder eine Sicherheitslücke in ein Release aufgenommen wird, kann der Fehler potenziell an hunderte oder tausende Server verteilt werden. Bevor der Fehler auffällt, sind wie im Falle von „Heartbleed“ mitunter schon zahlreiche Server und Millionen von Anwendern betroffen.

Natürlich ermöglicht Continuous Deployment aufgrund seiner agilen Natur wiederum rasche Korrekturen: Wie sich bei „Heartbleed“ gezeigt hat, waren die Hersteller recht schnell in der Lage, OpenSSH-Fixes zur Verfügung stellen. Das ändert aber nichts an der Tatsache, dass die Anfälligkeit faktisch in Umlauf gewesen ist – und so das Vertrauen der Anwender stark erschüttert sowie Software-Herstellern viel zusätzliche Arbeit beschert hat.

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 43377549 / Softwareentwicklung)