DevSecOps für sichere Softwarelieferketten | Anexia

Für die sichere Softwarelieferung erfassen wir den Weg einer Änderung vom Repository bis zur produktiven Ausführung. An jedem Übergang wird geprüft, wer etwas verändern darf, welche Nachweise entstehen und welche Entscheidung eine Veröffentlichung erlaubt. Das zeigt häufig Lücken zwischen einzelnen Werkzeugen: Ein Scanner findet einen Befund, aber niemand übernimmt seine Bewertung; ein freigegebenes Artefakt wird später neu gebaut und verliert damit seinen geprüften Bezug.

Bei der Entwicklungssicherheit beginnt die Umsetzung mit wenigen wirksamen Kontrollen an diesen Übergängen. Wir unterscheiden neue Änderungen von bestehenden Altlasten und legen einen nachvollziehbaren Umgang mit Ausnahmen fest. Für das DevSecOps braucht jede blockierende Regel einen Verantwortlichen und einen Bearbeitungsweg. Andernfalls verzögert sie lediglich Releases oder wird dauerhaft umgangen. Sicherheitsbefunde werden mit ihrer Erreichbarkeit und fachlichen Auswirkung bewertet. Der angestrebte Zustand ist ein Lieferprozess, in dem Entwicklung, Security und Betrieb dieselben Nachweise verwenden können. So verbindet das Security Engineering technische Prüfungen mit Entscheidungen, die im tatsächlichen Entwicklungsrhythmus getroffen und später nachvollzogen werden können.

Automatisierte Kontrollen werden dort eingesetzt, wo sie zuverlässige Entscheidungen ermöglichen. Fachliche Risikobewertungen behalten einen benannten Verantwortlichen. Für das Security Engineering dokumentieren wir die dafür relevanten Annahmen und begründen die gewählte Variante. Wesentliche Alternativen werden anhand derselben fachlichen Anforderungen betrachtet. Das erleichtert spätere Anpassungen, wenn sich Last, Datenbestand oder organisatorische Zuständigkeit verändern.

Eine tragfähige Entscheidung berücksichtigt auch Wartbarkeit und Übergabe. Bei der sicheren Softwarelieferung prüfen wir, welche Kompetenzen intern vorhanden sind und welche Betreuung zusätzlich benötigt wird. Technische Möglichkeiten werden dadurch mit einem realistischen Betriebsmodell verbunden. Der Auftraggeber erkennt, welche Aufgaben nach dem Projekt regelmäßig anfallen und welche Entscheidungen bei ihm verbleiben.

Zu viele irrelevante Warnungen führen dazu, dass Entwickler auch wichtige Meldungen ignorieren oder Prüfungen dauerhaft umgehen. Diesen Punkt behandeln wir bei der Entwicklungssicherheit als konkrete Prüffrage. Ein Risiko wird mit dem betroffenen Ablauf, seiner möglichen Auswirkung und einer geeigneten Maßnahme verbunden. Wo Voraussetzungen noch fehlen, bleibt die Aussage ausdrücklich offen, bis die notwendige Untersuchung erfolgt ist.

Wir betrachten Bearbeitungszeit kritischer Befunde, reproduzierbare Freigaben und die Zahl unbegründeter Ausnahmen statt allein die Anzahl installierter Scanner. Für das DevSecOps halten wir Ausgangslage, getestete Konfiguration und Ergebnis fest. Die Abnahme bezieht sich auf den vereinbarten Umfang. Offene Einschränkungen werden sichtbar dokumentiert und einem verantworteten nächsten Schritt zugeordnet. So kann Ihr Team zwischen nachgewiesener Funktion, einer bewussten Entscheidung und einer noch unbestätigten Annahme unterscheiden.

Projektbeispiel als illustratives Szenario

Das folgende Szenario ist ein Anwendungsbeispiel und keine Kundenreferenz. Ein Softwareunternehmen erhält Sicherheitsbefunde erst kurz vor geplanten Veröffentlichungen. Bei dem DevSecOps würde zunächst ein konkreter Releaseweg untersucht: vom neuen Quellcode über Tests und Pakete bis zur produktiven Anwendung. Die Frage wäre, wo Fehler früher erkannt werden können und welche Befunde eine Veröffentlichung tatsächlich verhindern müssen.

Für das Security Engineering würde das Team wenige, nachvollziehbare Prüfungen in diesen Ablauf integrieren. Ein bekannter kritischer Fehler müsste zuverlässig erkannt werden; ein dokumentierter Fehlalarm dürfte nicht bei jedem Durchlauf erneut ungeklärt blockieren. Zuständige Entwickler würden Befunde direkt ihrem Code und der betroffenen Version zuordnen können. Der Pilot würde außerdem einen Ausnahmefall durchspielen: Wer bewertet das Risiko, wie lange gilt die Ausnahme und welche Korrektur bleibt verbindlich eingeplant? Auch die Berechtigungen des Buildsystems wären Bestandteil der Untersuchung.

Die Wirkung von der sicheren Softwarelieferung würde an bearbeiteten Risiken und dem Verhalten realer Releases sichtbar. Eine steigende Zahl von Scannerfunden wäre allein kein Qualitätsgewinn. Vorgesehen wären ein geänderter Releaseprozess, nachvollziehbare Entscheidungsregeln und ein Arbeitsvorrat für bereits bekannte Schwachstellen. Das Entwicklungsteam könnte anschließend erkennen, welche Prüfungen zuverlässig helfen, welche manuelle Bewertung brauchen und wie sich Sicherheitsarbeit in die laufende Produktentwicklung einordnen lässt.

Unsere Erfahrung und unser Engineering Ansatz

Wir verbinden individuelle Softwareentwicklung mit den technischen Aufgaben der Einführung und Weiterentwicklung. Für das Security Engineering bringen wir die Perspektiven von Anwendung, Integration und Betrieb in einen gemeinsamen Arbeitsablauf. Die fachlichen Anforderungen bleiben dabei mit den technischen Entscheidungen verbunden. Sie arbeiten mit einem benannten Leistungsumfang und nachvollziehbaren Ergebnissen.

Unsere Erfahrung soll für Ihr Vorhaben konkret überprüfbar werden. Deshalb erläutern wir im technischen Austausch, wie wir die relevanten Risiken untersuchen, welche Arbeitsergebnisse vorgesehen sind und wie Ihr Team diese beurteilen kann. Für die sichere Softwarelieferung stimmen wir die beteiligten Rollen auf den tatsächlichen Bedarf ab. Verfügbare Referenzen werden mit dem jeweiligen Projekt- und Gesellschaftsbezug eingeordnet; vertrauliche Kundendetails werden nicht als allgemeine Werbeaussage verwendet.

Belegter Produktbezug

Die veröffentlichte Rahmenvereinbarung für maas.maker nennt Anexia Digital Engineering GmbH als Betreiberin der SaaS-Plattform. Den konkreten Bezug zu Ihrem Vorhaben erläutern wir im technischen Gespräch.

Aufwand für die sichere Softwarelieferung

Repositoryanzahl, Technologiemix, vorhandene Werkzeuge und Altlasten beeinflussen den Aufwand stärker als die Größe einer einzelnen Pipeline. Wir kalkulieren das DevSecOps deshalb anhand eines abgegrenzten Umfangs und ausdrücklich genannter Voraussetzungen. Ein erster Analyseschritt kann sinnvoll sein, wenn wesentliche technische Informationen noch fehlen. Danach lassen sich Arbeitspakete und Abnahmekriterien belastbarer vereinbaren.

Das Security Engineering kann als begrenztes Projekt, als gemeinsame Umsetzung mit Ihrem Team oder mit anschließender Betreuung organisiert werden. Nutzungsrechte, Zugänge, Dokumentation und Verantwortlichkeiten werden im Auftrag geklärt. Laufende Betriebszeiten, Reaktionsfristen und externe Verbrauchskosten sind eigene Vereinbarungen. So bleibt erkennbar, welche Leistungen einmalig erbracht werden und welche Aufgaben nach der Einführung regelmäßig anfallen.

Abgrenzung vom DevSecOps

Das Angebot umfasst technische Umsetzung und Prozessintegration; formale Zertifizierungsentscheidungen trifft eine zuständige Prüf- oder Zertifizierungsstelle. Für die Entwicklungssicherheit halten wir diese Grenze bereits im Angebot fest. Benötigte Zusatzleistungen werden mit ihrer fachlichen Begründung aufgenommen und nicht stillschweigend vorausgesetzt. Ihr Team kann dadurch passende interne Kompetenzen einplanen und die Gesamtleistung zwischen Beteiligten sinnvoll aufteilen.