Pay your debts!

DevSecOps hin oder her: Keine Software ist frei von technischen Schulden

Mike Bursell

© Shutterstock / Profit_Image

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. Red Hat arbeitet mit dieser Metapher, um auf Schwachpunkte in der Qualität von Programmcode hinzuweisen und Wege aufzuzeigen, wie sie sich 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:

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

Wenn die Entwickler wissen, was sie versäumt haben, können sie es 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-Workflows 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.
DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

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 wissen, 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 weiter verfolgt.
  • 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 ein Open-Source-Projekt 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: „Dieses 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:
    // 2018-05-02 (mmueller@company.com) Planned to use TLS 1.2 (check
    // for newer version) probably won’t need client
    // authentication. Don’t use ECC cipher suites.
    // Certificate management and revocation currently not specced.
  4. In Unit-Tests, die feststellen, ob über die Schnittstelle Daten in Klartext übertragen werden.

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 Quellcode-Dokumentation 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 sind, 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.

Geschrieben von
Mike Bursell

Mike Bursell ist Chief Security Architect bei Red Hat

Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: