Eine individuell entwickelte Anwendung soll Ihren betrieblichen Ablauf zuverlässig unterstützen. Bereits bei der Beauftragung können Sie festlegen, welche Sicherheitsanforderungen die Entwicklung berücksichtigen muss und wie deren Umsetzung später überprüft wird. Das betrifft beispielsweise eine interne Fachanwendung, eine eigene Schnittstelle oder ein speziell entwickeltes Kundenwerkzeug. Entscheidend ist der konkrete Entwicklungsauftrag mit seinen Rollen, Daten und Betriebsbedingungen. Mit passenden Ergebnissen pro Projektphase können Sie Fortschritt beurteilen und offene Fragen vor dem produktiven Einsatz klären.
Den Geschäftsablauf vor der technischen Lösung beschreiben
Beginnen Sie mit der Aufgabe, die Ihre neue Anwendung erfüllen soll. Wer arbeitet damit, welche Daten werden verarbeitet und welche Entscheidung oder Tätigkeit hängt vom Ergebnis ab? Ein Entwickler benötigt diesen Zusammenhang, um Sicherheitsanforderungen sinnvoll einzuordnen. Eine Anwendung für öffentlich freigegebene Informationen hat andere Schutzfragen als ein internes Werkzeug mit vertraulichen Kundenvorgängen. Der gewünschte Nutzen sollte deshalb neben den Funktionen verständlich beschrieben sein.
Erfassen Sie auch die Grenzen des Projekts. Welche bestehenden Systeme bleiben verantwortlich und welche neuen Verbindungen sollen entstehen? Vielleicht übernimmt die Anwendung Daten aus einer vorhandenen Fachsoftware, verarbeitet sie weiter und gibt Ergebnisse an ein anderes System zurück. Lassen Sie diese Übergaben benennen. Ohne eine solche Darstellung kann ein Angebot einzelne Funktionen enthalten, während die Prüfung der eigentlichen Schnittstellen zwischen den Beteiligten ungeklärt bleibt.
Notieren Sie, was bei einer Fehlfunktion besonders problematisch wäre. Eine falsche Zuordnung, ein unberechtigter Einblick oder ein länger nicht verfügbarer Arbeitsweg können unterschiedliche Folgen haben. Die fachlich verantwortlichen Personen sollten diese Auswirkungen mit dem Entwicklungsteam besprechen. Daraus lassen sich konkrete Prüffragen ableiten. Eine allgemeine Forderung nach maximaler Sicherheit liefert dagegen weder eine nachvollziehbare Priorität noch ein eindeutiges Ergebnis für die spätere Abnahme.
Anforderungen mit einem bezeichneten Prüfstand vereinbaren
Halten Sie sicherheitsbezogene Anforderungen so fest, dass beide Seiten dieselbe Aussage darunter verstehen. Eine vertrauliche Ansicht soll beispielsweise nur den dafür vorgesehenen Rollen zugänglich sein. Welche Rollen gemeint sind und welche Daten die Ansicht enthält, wird im Projekt konkretisiert. Das Ergebnis sollte überprüfbar bleiben. Ein bloßes Attribut wie professionell abgesichert beschreibt keine ausreichende Grundlage für einen Vergleich unterschiedlicher Entwicklungsangebote.
NIST beschreibt im Secure Software Development Framework die Aufnahme und Pflege von Sicherheitsanforderungen über den Entwicklungsablauf. Die finale Veröffentlichung SP 800-218 trägt die Version 1.1 und stammt von 2022. Das Framework kann eine gemeinsame fachliche Sprache für Auftraggeber und Entwicklungsteam liefern. Seine Nennung allein ist jedoch kein Nachweis, dass Ihre Anwendung bereits nach einem vollständig bestätigten Verfahren entwickelt wurde. NIST: SSDF Version 1.1
Vermerken Sie, welche Fassung einer vereinbarten Grundlage verwendet wird. Die NIST-Publikationsübersicht führt daneben einen Entwurf der Version 1.2. Ein Entwurf und eine finale Veröffentlichung sollten im Auftrag unterscheidbar bleiben. Entscheidend ist, welche konkret ausgewählten Anforderungen zum Projekt gehören und wie Änderungen daran behandelt werden. Der Anbieter sollte diese Zuordnung erläutern können, statt unterschiedliche Versionsbezeichnungen ohne klaren Geltungsbereich miteinander zu vermischen. NIST: SSDF-Publikationen
Missbrauchsfragen früh am geplanten Ablauf prüfen
Bitten Sie das Entwicklungsteam, neben dem gewünschten Normalablauf auch unbeabsichtigte und unzulässige Nutzungen zu betrachten. Was soll passieren, wenn jemand einen Datensatz einer anderen Rolle anfordert oder eine unerwartete Eingabe übermittelt? Solche Fragen sollten sich auf Ihre Funktionen beziehen. Für die Projektführung benötigen Sie keine eigenen Angriffswerkzeuge, sondern eine verständliche Beschreibung der Risiken und der vorgesehenen Schutzentscheidungen im tatsächlichen Entwurf.
Beziehen Sie die zuständigen Fachbereiche ein. Sie können erklären, welche Zuordnung fachlich richtig ist und welche Ausnahme im Alltag wirklich gebraucht wird. Eine technische Rolle sollte nicht aus Unkenntnis des Geschäftsablaufs weitreichende Rechte erhalten. Umgekehrt braucht die Entwicklung eine bestätigte Entscheidung, wenn eine bewusst vorgesehene Zusammenarbeit Datenzugriffe zwischen Bereichen erfordert. Halten Sie diese begründeten Festlegungen im Projekt fest und machen Sie spätere Änderungen sichtbar.
Wenn ein Risiko erst während der Umsetzung erkannt wird, sollte sein weiterer Umgang klar sein. Wer bewertet die betriebliche Auswirkung und wer entscheidet über eine Anpassung des Umfangs? Der Anbieter sollte begründen, welche Änderung erforderlich ist und welche begrenzte Alternative bestehen könnte. Damit können Sie Sicherheitsbedarf und Projektziel gemeinsam beurteilen. Eine neue Feststellung darf weder stillschweigend ignoriert noch ohne erkennbare Entscheidung zum Anlass eines unbegrenzten Zusatzprojekts werden.
Als konkrete Gegenprobe können Sie einen Ablauf betrachten, in dem eine berechtigte Person dieselbe Aufgabe mit einer anderen Rolle ausführen möchte. Welche Ansicht soll sie erhalten und welche Information ausdrücklich nicht? Die fachlich verantwortliche Stelle bestätigt das gewünschte Ergebnis, während das Entwicklungsteam die passende Prüfung festlegt. Diese Zuordnung hilft auch bei späteren Erweiterungen: Eine neu hinzugefügte Rolle wird an demselben Geschäftsablauf betrachtet und nicht allein aus der technisch einfachsten Einstellung abgeleitet.
Entwicklungsumgebung und Produktionszugang unterscheiden
Fragen Sie, in welchen Umgebungen entwickelt und geprüft wird. Wer erhält Zugang zu den Projektunterlagen und welche Daten werden für Tests benötigt? Eine geeignete Testumgebung sollte ihren Zweck erfüllen, ohne dass dafür unkontrolliert vertrauliche Originaldaten an alle Projektbeteiligten verteilt werden. Lassen Sie die notwendigen Datenarten bestimmen und den vorgesehenen Umgang durch die zuständigen Fachpersonen freigeben. Die technische Bequemlichkeit ist dabei nicht die einzige Entscheidungsgrundlage.
Klären Sie, welche Rechte das Entwicklungsteam später in der produktiven Umgebung benötigt. Die Bereitstellung einer neuen Version und die laufende Verwaltung sämtlicher Geschäftsdaten sind unterschiedliche Aufgaben. Der Auftrag sollte erkennen lassen, wer welche Handlung ausführt und welche Freigabe benötigt wird. Ein dauerhaft weitreichender Zugang muss nicht automatisch die Folge eines erfolgreichen Entwicklungsprojekts sein. Lassen Sie die tatsächlich erforderliche Betriebsrolle getrennt beschreiben.
Vereinbaren Sie einen geschützten Umgang mit Zugangsmitteln und vertraulichen Konfigurationen. Sie gehören nicht als gewöhnlicher Text in allgemeine Aufgabenlisten oder Projektpräsentationen. Fragen Sie nach dem vorgesehenen Einrichtungs- und Übergabeweg. Ihr Unternehmen sollte handlungsfähig bleiben, auch wenn ein bestimmter Entwickler später nicht mehr beteiligt ist. Dafür braucht es bekannte berechtigte Zuständigkeiten und eine passende Dokumentation, keine breite Verteilung sämtlicher Geheimnisse.
Eingebundene Komponenten im Projekt mitführen
Individuelle Software kann vorhandene Bibliotheken und externe Dienste verwenden. Lassen Sie erklären, welche davon für die Anwendung wesentlich sind und wer ihre Pflege übernimmt. Eine Liste allein bestätigt noch nicht ihren passenden Einsatz. Für Ihr Unternehmen ist entscheidend, ob die Abhängigkeiten zum vorgesehenen Betrieb passen und wie relevante Änderungen während der Nutzung behandelt werden. Der Entwicklungsauftrag sollte diesen Punkt vor der Übergabe berücksichtigen.
Fragen Sie, welche Informationen zum gelieferten Stand Sie erhalten. Eine nachvollziehbare Zuordnung von eigener Software, verwendeten Bestandteilen und benötigten Diensten erleichtert die spätere Betreuung. Der Umfang sollte zum tatsächlichen Projekt passen. Für eine begrenzte Anwendung benötigen Sie nicht automatisch eine große zusätzliche Verwaltungsplattform. Sie brauchen aber genug verlässliche Information, um notwendige Pflege und eine spätere Übergabe an eine andere berechtigte Fachperson organisieren zu können.
Besprechen Sie einen möglichen Ausfall oder Wechsel eines externen Dienstes. Welche Funktionen hängen davon ab und welche Information erhält Ihr Team, wenn die Voraussetzung nicht mehr erfüllt ist? Eine Anwendung sollte in Ihrem Auftrag nicht nur für die erste Vorführung beschrieben sein. Die zuständigen Fachpersonen können relevante Abhängigkeiten und einen passenden weiteren Entscheidungsweg festhalten. So wird der spätere Betriebsbedarf bei der Auswahl der technischen Lösung sichtbar.
Prüfungen und Befunde als Projektleistung erhalten
Lassen Sie Sicherheitsprüfungen mit ihrem jeweiligen Ziel benennen. Welche Funktionen, Rollen und Schnittstellen werden betrachtet und welcher Stand der Anwendung wird geprüft? Automatisierte Prüfungen und eine fachliche Durchsicht können unterschiedliche Fragen beantworten. Ein zusammengefasster Erfolgsstatus sagt ohne diesen Bezug wenig aus. Der Abschluss sollte erkennen lassen, was tatsächlich untersucht wurde und welche Teile außerhalb des vereinbarten Umfangs liegen.
Im SSDF beschreibt NIST unter anderem die geplante Prüfung ausführbaren Codes sowie die Dokumentation und Bearbeitung gefundener Probleme. Nutzen Sie dies als Anlass, einen nachvollziehbaren Befundweg zu vereinbaren. Welche Abweichungen müssen vor der Bereitstellung behoben werden und wer bewertet verbleibende Einschränkungen? Die Antwort wird am tatsächlichen Risiko und am bestätigten Projektziel festgelegt. Die pauschale Aussage, es seien keine Fehler bekannt, ist keine umfassende Sicherheitsgarantie.
Fragen Sie, wie eine Korrektur nachgewiesen wird. Die Mitteilung behoben sollte auf den betroffenen Softwarestand und eine geeignete erneute Prüfung bezogen sein. Gleichzeitig muss nicht nach jeder kleinen unabhängigen Änderung jede frühere Untersuchung vollständig wiederholt werden. Lassen Sie den erforderlichen Prüfumfang fachlich begründen. Ihr Unternehmen benötigt eine belastbare Aussage zur konkreten Korrektur und zur Wirkung auf die bereits bestätigten relevanten Ergebnisse.
Die produktive Übergabe mit dem Betreiber abstimmen
Benennen Sie, wer die Anwendung nach Projektende betreibt. Diese Rolle sollte rechtzeitig wissen, welche Voraussetzungen die neue Software benötigt und welche Aufgaben bei der Übergabe anfallen. Eine fertige Anwendung kann ohne abgestimmten Betriebsweg noch nicht sinnvoll genutzt werden. Der Auftrag sollte deshalb eine nachvollziehbare Übergabe zwischen Entwicklung und Betreuung enthalten, einschließlich bekannter Einschränkungen und der für den Betrieb notwendigen Unterlagen.
Vereinbaren Sie einen kontrollierten Start mit den erforderlichen Freigaben. Wer entscheidet über den Zeitpunkt, wer begleitet die Einführung und wie wird bei einer unerwarteten Störung vorgegangen? Die tatsächliche Bereitstellung sollte an einem bezeichneten Softwarestand hängen. Eine erfolgreiche Vorführung einer älteren Zwischenversion bestätigt nicht automatisch die später ausgelieferte Kombination. Lassen Sie offene Änderungen vor dem Start erkennbar abschließen oder ausdrücklich als verbleibende Entscheidung behandeln.
Auch Rückmeldungen der Nutzer gehören in einen bekannten Bearbeitungsweg. Nicht jede Beobachtung ist eine neue Funktionsanforderung; manche weist auf eine Abweichung des vereinbarten Ablaufs hin. Lassen Sie erklären, wie solche Hinweise eingeordnet werden und wer die fachliche Priorität bestätigt. Damit kann Ihr Unternehmen zwischen notwendiger Korrektur und gewünschter Erweiterung unterscheiden, ohne jede Rückmeldung entweder pauschal zurückzuweisen oder ungeprüft den Projektumfang zu vergrößern.
Pflege und späteren Anbieterwechsel vorab klären
Besprechen Sie den Umgang mit Sicherheitsmeldungen nach der Übergabe. NIST behandelt im SSDF auch die Aufnahme und Bearbeitung von Schwachstellenhinweisen. Für Ihre Anwendung zählt, welcher Ansprechpartner diese Aufgabe tatsächlich übernimmt und welche Unterstützung vereinbart ist. Eine abgeschlossene Entwicklung bedeutet nicht automatisch eine unbegrenzte laufende Pflege. Stellen Sie die erforderlichen Leistungen deshalb im Angebot neben die erstmalige Erstellung und den produktiven Start.
Klären Sie abschließend, welche Projektunterlagen und berechtigten Zugänge für eine spätere Weiterbetreuung verfügbar sind. Dazu kann je nach vereinbartem Modell auch die geordnete Übergabe des relevanten Quellcodes gehören. Die geschäftlichen und rechtlichen Vereinbarungen dazu werden gesondert geprüft. Technisch sollte erkennbar sein, wie ein berechtigter Nachfolger den gelieferten Stand nachvollziehen kann. So bleibt die entwickelte Anwendung über das einzelne Projektteam hinaus betreubar.
Sicherheitsleistungen für die Entwicklung anfragen
Beschreiben Sie in der Anfrage auf der Startseite die geplante Anwendung, ihre wichtigsten Datenwege und die vorhandene Betriebsbetreuung. Vertrauliche Originaldaten oder Zugangsmittel sind für diese erste Beschreibung nicht erforderlich. Welche Entwicklungsbegleitung und Prüfleistungen passen, vereinbaren Sie anschließend mit dem jeweiligen Anbieter.