dark

Technische Schulden in der DevScoreOps-Welt

Avatar

Wenn von technischen Schulden die Rede ist, denken viele vor allem an die traditionelle Applikationsentwicklung. Schuldzuweisungen aber helfen nicht weiter, denn auch die DevSecOps-Welt ist davon nicht verschont. Wichtig ist, technische Schulden genau zu dokumentieren und Prioritäten für deren Behebung festzulegen.

Wie bei fast allen Verfahren und Prozessen in der IT gibt es auch beim Konzept der technischen Schulden Anhänger und Kritiker. Mit dieser Metapher lassen sich auf Schwachpunkte in der Qualität von Programmcode hinweisen und Wege aufzeigen, wie sich diese Mängel beseitigen lassen.

 

Keine Software ist frei von technischen Schulden

Um eines klarzustellen: In jeder Software gibt es technische Schulden, die sich beispielsweise daraus ergeben, dass die Entwickler Kompromisse zwischen dem idealen Programmcode und dem Programmcode eingehen, der genügt, um Termine einzuhalten. Erkennen die Entwickler oder die Benutzer die Lücken, können sie Verbesserungen angehen – wenn nicht sofort, dann zu einem späteren Zeitpunkt. Bei den technischen Schulden lassen sich zwei Formen unterscheiden:

  • Nicht alle geplanten Funktionen wurden auch tatsächlich realisiert.
  • Das Projektteam traf suboptimale Entscheidungen.

Wenn die Entwickler wissen was sie versäumt haben, können sie es später, zu einem geeigneten Zeitpunkt nachholen. Wenn sich eine frühere Entscheidung als suboptimal herausstellt, können Entwickler sie revidieren.

Gerade bei DevSecOps ist Sicherheit immer wieder ein vernachlässigtes Thema bei den technischen Schulden. DevSecOps stellt einem gängigen Verständnis zufolge durch Automatisierung, Tooling und kulturellem Wandel die Sicherheit in den Mittelpunkt der DevOps-Praktiken, -Prozesse und -Bereitstellung. Das heißt, bereits in der Konzeptphase sollten eigentlich die Anwendungs- und Infrastruktursicherheit berücksichtigt werden. Um die Geschwindigkeit im DevOps-Workflow zu erzielen, müssen zumindest einige Sicherheitsfeatures automatisiert werden. Auch durch die Auswahl der geeigneten Tools sollten Entwickler zur Integration von DevOps-Sicherheit beitragen. Dennoch treten auch hier immer wieder technische Schulden auf. Einige Beispiele für sicherheitsrelevante Schulden:

  • Aktuell noch nicht öffentlich zugängige APIs werden bei der Authentifizierung vergessen.
  • Funktionen werden nicht klar voneinander getrennt.
  • Rollen werden den ursprünglichen Erwartungen zufolge fix codiert, mögliche künftige Änderungen werden nicht berücksichtigt.
  • Kryptographische Verfahren der Cipher-Suite werden zusammen mit der Applikation kompiliert.

All diese Arten von technischen Schulden können sowohl in Applikationen auftreten, die mit klassischen Entwicklungsmethoden entstanden sind, als auch in solchen, die mit eher agilen Methoden wie DevSecOps erstellt wurden. Mehr noch: In vielen Fällen befinden sich Projekte, die der klassischen Methode folgen, in einer besseren Position als agile oder DevOps-Projekte. Denn in der Regel gibt es eine klar definierte Produktmanagement-Rolle, die Kundenanforderungen zwischen den Releases sammelt, bewertet und entscheidet, welche für das nächste Release priorisiert werden. In der DevOps-Welt kann es schnell vorkommen, dass diffizile Funktionen oder schwierige Entscheidungen aufgeschoben werden. Wenn die Verantwortlichen Requests nicht konsolidieren, verdeckt der Fokus auf Pro-Sprint-Funktionen die technischen Schulden. Diese Probleme verschlimmern sich, wenn Teams nach dem Motto verfahren: Bei DevSecOps sind alle für die Sicherheit verantwortlich – und daher keine Sicherheitsexperten im Team vorhanden sind.

 

Sicherheitsanforderungen werden oft vernachlässigt

Ebenso wie bei der traditionellen Applikationsentwicklung ist auch bei DevOps die Sicherheit eine komplexe Herausforderung, die detailliertes Wissen erfordert. Technische Schulden können leicht entstehen, wenn Mitarbeiter, die keine Sicherheitsexperten sind, Entscheidungen treffen. Wie soll jemand mit wenig Know-how über Best-Practices im Bereich der IT-Sicherheit kennen, z.B. wann es sinnvoll ist Cipher-Suites zusammen mit einer Anwendung zu kompilieren und wann nicht? Technische Schulden werden aus drei Gründen zum Sicherheitsproblem:

  • Sicherheitsanforderungen haben oft keinen direkten funktionalen Bezug zu einer Anwendung und werden daher seltener weiterverfolgt;
  • Fundierte Sicherheitskenntnisse sind Mangelware. Zu wenige Verantwortliche, Architekten und Designer verstehen die Bedeutung und die Auswirkungen von IT-Sicherheit.
  • Entwicklerteams befassen sich erst gegen Projektende mit IT-Sicherheit, das Thema wandert sehr schnell in der To-Do-Liste nach unten und wird dann vergessen.

Es lohnt sich darüber nachzudenken, warum technische Schulden ein Gewinn für ein Projekt und insbesondere für Open-Source-Projekte sein können. Erkennen Unternehmen technische Schulden in einer Applikation, müssen Verantwortliche eine Entscheidung treffen: Sollen die Schulden behoben werden oder bleibt alles zunächst einmal wie es ist. Manchmal, und so unpopulär diese Ansicht auch sein mag, hat die Benutzerfreundlichkeit für eine bestimmte Zeit Vorrang vor der Sicherheit. Möglicherweise verfügt das Entwicklerteam auch nicht über das benötigte Fachwissen, um aktuell eine fundierte Entscheidung über Design oder Implementierung zu treffen. Auf jeden Fall muss diese Entscheidung dokumentiert werden und dazu gehört auch, warum sie so getroffen wurde. Existiert eine Dokumentation und es handelt sich um ein Community-Open-Source-Projekt, kann es außerdem sein, dass jemand anderes, der über die Ressourcen oder das Wissen über mögliche Implementierungen verfügt, die technischen Schulden beheben wird.

An einem konkreten Beispiel lässt sich am besten zeigen, wie Entwickler mit technischen Schulden umgehen sollten. Angenommen, an einer bestimmten Schnittstelle war keine Verschlüsselung enthalten. Welche Schritte können Entwickler unternehmen, um diese technische Schuld zu beheben? Zunächst einmal sollten sie den Mangel an mehreren Stellen klar und eindeutig aufzeichnen:

  1. In der Projektdokumentation, beispielsweise in der Form: „Uns fehlte die Zeit und daher enthält die Anwendung kein Zertifikatsmanagement.“
  2. In der Produktdokumentation durch den Hinweis: „Diese API ist für den Einsatz in einer geschützten Umgebung konzipiert und sollte nicht über das Internet genutzt werden.“
  3. im Quellcode durch Kommentare (Listing 1).
  4. In Unit-Tests, die feststellen, ob über die Schnittstelle Daten in Klartext übertragen werden.

 

Listing (1)

Inwiefern sind diese Maßnahmen hilfreich? In der Projektdokumentation können Entwickler klarere Anforderungen erstellen, in der Produktdokumentation legen sie fest, wie die Anwendung sicher eingesetzt werden kann und in der Quellcodedokumentation folgen Anweisungen für die künftige Implementierung. Der letzte Punkt, der Komponententest, mag seltsam erscheinen, denn wer will schon einen Test durchführen, von dem bekannt ist, dass er fehlschlägt? Wollen Entwickler sicherstellen, dass ein Feature oder eine Funktion implementiert ist, gibt es nichts Besseres als eine rote Ampel, um explizit zu überprüfen, ob alles so ist wie es sein soll. Mit dieser Methode sind nützliche technische Schulden dokumentiert und damit bekannt.

Wichtig ist, dass alle Beteiligten Schuldzuweisungen vermeiden – insbesondere dann, wenn Entwickler selbst die Betroffenen sind. Von einer guten Dokumentation profitieren mehrere Gruppen: Softwarearchitekten, Designer, Entwickler, Tester, Projektverantwortliche, Produktmanager, Vertrieb, Marketing, Support und nicht zuletzt Kunden.

 

Mike Bursell kam im August 2016 zu Red Hat, nachdem er zuvor bei Intel und Citrix in den Bereichen Sicherheit, Virtualisierung und Netzwerk tätig war. Nach einer Ausbildung zum Softwareentwickler spezialisierte er sich auf verteilte Systeme und Sicherheit und arbeitete in den letzten Jahren in den Bereichen Architektur und technische Strategie. Mike ist seit Mitte 2013 eng mit dem Telekommunikationsmarkt und dem ETSI NFV verbunden, mit Beiträgen in den Gruppen I SEC, INF und SWA, und ist Berichterstatter für drei sicherheitsrelevante Arbeitsthemen. Er war zwei Jahre lang stellvertretender Vorsitzender der ETSI NFV Security Working Group und war auch am OPNFV-Projekt beteiligt. Er spricht regelmäßig auf Veranstaltungen in Europa, Nordamerika und APAC.

Zu seinen beruflichen Interessen gehören: Linux, Open Source Software, Sicherheit, verteilte Systeme, Blockchain, NFV, SDN, Virtualisierung (einschließlch Linux-Container uind Hypervisor). Mike hat einen MA von der Universtiy of Cambridge und einen MBA von der Open University.

 

Total
0
Shares
Previous Post

Wir entscheiden zusammen, nicht allein

Next Post

Getting Hip with JHipster

Related Posts