Sicherheitsfragen an einen Softwareentwicklungspartner – und welche Nachweise gute Antworten belegen

Dieser Leitfaden richtet sich an Gründer, CTOs, Sicherheitsverantwortliche und Einkaufsteams, die einen Partner in die engere Auswahl nehmen, der Code für sie schreiben soll. Unser Leitfaden zum Outsourcing der Softwareentwicklung behandelt Kosten, Teammodelle und die allgemeine Lieferantencheckliste; diese Seite vertieft einen Punkt daraus: die Sicherheit. Es handelt sich um allgemeine Orientierung, nicht um ein Sicherheits-Audit.

In diesem Leitfaden

• Warum ein Entwicklungspartner andere Fragen erfordert
• Zwölf Fragen und die einzufordernden Nachweise
• Was Zertifikate belegen – und was nicht
• So führen Sie die Sicherheitsprüfung durch
• Warnsignale
• KI-Coding-Tools: drei weitere Fragen
• Alternativen und Auswahlkriterien
• Wie Netbase diese Fragen beantwortet
• Welche Liefernachweise existieren – und welche nicht
• Was sind die Grenzen dieses Leitfadens?
• Häufig gestellte Fragen
• Nächster Schritt

Warum ein Entwicklungspartner andere Fragen erfordert

Ein Softwareanbieter verkauft Ihnen ein fertiges Produkt. Ein Entwicklungspartner baut Ihr Produkt gemeinsam mit Ihnen – das verschiebt die Risikolage grundlegend. Seine Ingenieure pushen Code in Ihre Repositories, deployen in Ihre Cloud-Konten, lesen Ihre Spezifikationen und sehen manchmal Produktionsdaten. Ihre Laptops, Konten und Tools werden Teil Ihrer Angriffsfläche, und der Code, den sie schreiben, wird zur Sicherheit Ihres Produkts.

Eine Partnerprüfung hat daher zwei Hälften. Die erste ist Enterprise-Sicherheit: wie das Unternehmen sich selbst, seine Mitarbeiter und seine Systeme schützt. Die zweite ist Produktsicherheit: wie die Software, die es für Sie entwickelt, konzipiert, geprüft, getestet und gewartet wird. CISA und das FBI treffen dieselbe Unterscheidung in ihrem Secure by Demand Guide für Softwarekäufer und betonen die Produktsicherheit – nicht nur die eigenen Kontrollen des Lieferanten. Die meisten allgemeinen Lieferantenfragebögen decken die erste Hälfte gut ab und die zweite schlecht.

Zwölf Fragen und die einzufordernden Nachweise

Zwei Punkte auf dieser Liste sind neuer als die meisten Fragebögen. Zu Komponenten: CISA, die NSA, das FBI und internationale Partner veröffentlichten am 29. Juli 2026 die 2026 Minimum Elements for a Software Bill of Materials und ersetzten damit die NTIA-Elemente von 2021; die Anforderung eines SBOM ist heute ein Standard-Request, kein exotischer. Zu KI-Tools: siehe den Abschnitt weiter unten.

Was Zertifikate belegen – und was nicht

ISO-27001-Zertifizierung und ein SOC-2-Bericht sind nützliche Signale, beantworten aber engere Fragen als Käufer oft annehmen.

• Sie decken das Unternehmen ab, nicht Ihr Produkt. Ein Informationssicherheits-Managementsystem oder ein Satz geprüfter Kontrollen gibt Auskunft darüber, wie der Lieferant sich selbst führt. Es zertifiziert nicht die Anwendung, die der Lieferant für Sie entwickelt, oder Ihr Hosting.
• Der Geltungsbereich ist entscheidend. Fragen Sie, welche Einheiten, Standorte und Dienste das Zertifikat oder der Bericht abdeckt – und ob Ihr Lieferteam innerhalb dieses Geltungsbereichs arbeitet.
• Der Typ ist bei SOC 2 entscheidend. Der illustrative SOC-2-Type-2-Bericht der AICPA zeigt, dass ein Type-2-Bericht die Tests der Kontrollen durch den Prüfer und deren Ergebnisse über einen Zeitraum enthält – nicht nur eine Beschreibung der Kontrollen.
• Daten sind entscheidend. Ein Zertifikat läuft ab und ein Bericht deckt einen vergangenen Zeitraum ab; fordern Sie das aktuelle Dokument an.

Ein Partner ohne Zertifikat kann Sicherheit dennoch gut praktizieren, und ein zertifizierter Partner kann dennoch unsicheren Code liefern. Nutzen Sie Zertifikate, um die Prüfung zu verkürzen – niemals, um die Produktfragen zu überspringen.

Warnsignale

• Antworten, die Tools benennen, aber deren Output nicht zeigen können.
• Gemeinsam genutzte Logins oder Zugänge, die nie entzogen werden.
• Ihr Code liegt in den Repositories und Konten des Lieferanten, nicht in Ihren.
• Kein schriftlicher Prozess für Sicherheitsvorfälle – oder niemand, der dafür verantwortlich ist.
• Echte Kundendaten werden standardmäßig in Testumgebungen kopiert.
• Sicherheitstests werden nur als optionales Extra am Ende angeboten.
• Ein Zertifikat wird so präsentiert, als würde es Ihr Produkt abdecken.

KI-Coding-Tools: drei weitere Fragen

KI-gestütztes Engineering ist inzwischen normal – auch bei Netbase – und wirft drei Fragen auf. Erstens: Welche Tools dürfen Ihren Code einsehen, und sind sie so konfiguriert, dass Ihre Eingaben nicht zum Training gemeinsam genutzter Modelle verwendet werden? Zweitens: Wird jede KI-vorgeschlagene Änderung von einem namentlich bekannten Ingenieur geprüft und denselben Tests und Scans unterzogen wie menschlicher Code? Drittens: Können Sie die KI-Unterstützung für sensible Repositories abschalten? Ein Partner, der diese Fragen nicht klar beantworten kann, hat sich keine Gedanken darüber gemacht, wohin Ihr Code geht. Netbase arbeitet mit den wichtigsten kommerziellen und Open-Source-KI-Tools und -Modellen – projektbezogen ausgewählt –, und jede KI-gestützte Änderung bleibt unter menschlicher Prüfung. Zum Design des Checkpoint-Prozesses selbst siehe unser Security Review Gate für KI-generierten Code.

Alternativen und Auswahlkriterien

Treffen Sie Ihre Wahl anhand von vier Kriterien: der Sensibilität der Daten, die das Team berühren wird, ob der Lieferant auf die Produktion zugreift, dem Umfang und der Laufzeit des Vertrags sowie den eigenen Regeln Ihrer Branche.

Wie Netbase diese Fragen beantwortet

Die Sicherheitspraktiken von Netbase umfassen: sicheres Code-Review und Versionskontrolle, TLS in der Übertragung und AES im Ruhezustand, rollenbasierte Zugriffskontrolle, MFA für Admin-Dashboards, Schwachstellen-Scanning und Penetrationstests sowie Disaster Recovery. Mitwirkende arbeiten unter NDA; NDAs, Auftragsverarbeitungsverträge und SLAs stehen Kunden auf Anfrage zur Verfügung. Netbase folgt der DSGVO-Ausrichtung für den Datenschutz in Europa, HIPAA-konformen Methoden für den Umgang mit Gesundheitsdaten und CCPA-Compliance-Praktiken für Kunden mit US-amerikanischer Kundenbasis.

Netbase richtet sich nach ISO 27001 und SOC 2 Type II. Beide decken den eigenen Betrieb von Netbase ab – nicht das Produkt oder Hosting eines Kunden –, und Zertifikatsdetails werden im Rahmen der Due Diligence geteilt, nicht veröffentlicht. Bei der Individualentwicklung durch Netbase gehört das für einen Kunden erstellte geistige Eigentum dem Kunden; Netbase-Produktmodule und Produkte der Business Division werden lizenziert, nicht übertragen; unser Leitfaden zum Schutz von IP beim Outsourcing behandelt diese Klauseln. Die meisten Netbase-Projekte werden zu Festpreisen abgewickelt, die nach der Discovery-Phase vereinbart werden; dieselben Sicherheitsbedingungen gelten für dedizierte Entwicklungsteams; die Abwägungen erläutert dediziertes Team vs. Festpreis. Die vollständige Erklärung finden Sie unter Sicherheit und Compliance.

Welche Liefernachweise existieren – und welche nicht

• Was existiert. Seit 2020 ist Netbase als Offshore-Entwicklungs- und Managing-Partner an einer mandantenfähigen Cloud-ERP-Plattform für einen US-Kunden beteiligt, die als SaaS an kleine und mittelständische Unternehmen verkauft wird; der öffentliche Datensatz enthält den Namen des Kunden nicht. Netbase entwickelt und betreibt außerdem seine eigene SaaS-Lösung, Printcart.
• Was nicht existiert. Kein veröffentlichter Netbase-Datensatz enthält Penetrationstest-Ergebnisse, Incident-Historie, Audit-Befunde oder Reaktionszeiten – und keiner der oben genannten Datensätze ist ein Nachweis für eine bestimmte Kontrolle. Netbase veröffentlicht keine Zertifikatsnummern, -daten, Prüfer oder Geltungsbereiche.

Was sind die Grenzen dieses Leitfadens?

• Er hilft Ihnen bei der Auswahl eines Partners; er testet nicht Ihre Anwendung. Dafür siehe Application Security Assurance.
• Regulierte Branchen wie Zahlungsverkehr oder Gesundheitswesen stellen eigene Anforderungen; holen Sie Fachberatung ein.
• Standards ändern sich: Prüfen Sie ASVS, SSDF und SBOM-Leitlinien am Tag Ihrer Prüfung auf dem aktuellen Stand.
• Für die sprinterweise Steuerung der Sicherheit nach Projektstart siehe Software-Qualitäts-Governance für ausgelagerte Lieferung und die Release-Readiness-Checkliste; Quality Engineering und Testing betreibt beides.

Nächster Schritt

Senden Sie uns Ihren Sicherheitsfragebogen oder die oben genannten Fragen, und wir vereinbaren einen Solution-Review, um unsere Antworten gemeinsam mit dem Ingenieur durchzugehen, der Ihr Projekt leiten würde. Sie können auch weitere Netbase Insights durchstöbern.

Verwandte Leistungen und Lösungen