So arbeiten wir

Qualität und Engineering-Standards

Was der Satz „wir arbeiten auf Basis von ISO/IEC 25010, BSI und OWASP“ genau bedeutet.

Welche Normen wir anwenden, an welcher Stelle des Prozesses und womit wir ihre Anwendung belegen. Fragt Ihr Einkauf nach Lieferantenstandards, senden wir das vollständige Dokument und beantworten die konkreten Fragen.

Unverbindlich anfragen
Umfang der Zertifizierung

Wir haben kein ISO-Zertifikat

Die blue veery GmbH besitzt weder ein ISO-Zertifikat noch eine andere Sicherheitszertifizierung. Die unten genannten Normen und Leitlinien wenden wir als Bezugspunkt für den eigenen Prozess an — und wir können zeigen, an welcher Stelle jede von ihnen wirkt.

ISO/IEC 25010 ist ein Produktqualitätsmodell und keine Managementsystemnorm: Sie definiert die Merkmale, nach denen Software bewertet wird. Zertifizierbar sind Managementsystemnormen, etwa ISO 9001 oder ISO/IEC 27001. Diese besitzen wir nicht und behaupten nichts anderes.

Wird ein zertifizierter Lieferant benötigt, sollte das zu Beginn geklärt werden. Wir benennen, welche Elemente wir dokumentieren können und was sich nicht mit einem Zertifikat belegen lässt.

Bezugspunkt

Drei Bezugsdokumente und ihre Funktionen

Jedes der drei Dokumente beantwortet eine andere Frage. Wir wenden sie gemeinsam an, nicht wechselweise.

ISO/IEC 25010

Gegenstand der Bewertung

Ein Produktqualitätsmodell. Es liefert Benennung und Struktur der nichtfunktionalen Anforderungen, mit denen wir die Ziele im Vertrag beschreiben.

BSI

Organisation des Prozesses

Vorgaben des deutschen Bundesamts für einen sicheren Software-Lebenszyklus: von den Anforderungen bis zum Umgang mit Schwachstellen.

OWASP

Umfang der Code-Prüfung

Eine Liste von Risikokategorien sowie überprüfbare Verifikationsanforderungen, denen wir jede Feststellung aus dem Audit zuordnen.

KI in der Entwicklung

Normen zum Einsatz von KI in der Softwareentwicklung

Es gibt keine Norm, die mit KI entstandenen Code zertifiziert. Zertifizierbar ist ISO/IEC 42001 — eine Managementsystemnorm für künstliche Intelligenz, die Organisationen erfasst, welche KI-Lösungen bereitstellen und einsetzen; dieses Zertifikat besitzen wir nicht. Die übrigen Dokumente haben den Charakter von Leitlinien, und sie bestimmen unsere Arbeitsweise.

ISO/IEC 42001:2023Managementsystem für künstliche Intelligenz
Anforderungen an Organisationen, die KI-gestützte Lösungen bereitstellen und einsetzen. Als Managementsystemnorm ist sie zertifizierbar.Status: Das Zertifikat besitzen wir nicht.
ISO/IEC 5338:2023Lebenszyklusprozesse von KI-Systemen
Eine Erweiterung der Software-Lebenszyklusprozesse um die Besonderheiten von Systemen, die künstliche Intelligenz nutzen.Status: Leitlinie, keine Zertifizierung.
ISO/IEC 23894:2023Risikomanagement bei KI
Leitlinien zur Identifikation und Behandlung von Risiken im Zusammenhang mit künstlicher Intelligenz.Status: Leitlinie, keine Zertifizierung.
BSI und ANSSIKI-Assistenten beim Programmieren
Gemeinsame Empfehlungen des deutschen und des französischen Amtes zur Arbeit mit Code-Generatoren.Status: Grundlage unserer Richtlinie zum Einsatz von KI-Werkzeugen.
OpenSSFAnweisungen für Code-Assistenten
Empfehlungen zur Konfiguration von KI-Assistenten: Validierung der Eingabedaten, Auswahl der Abhängigkeiten, SBOM, sprachspezifische Vorgaben.Status: angewandt bei der Konfiguration der Werkzeuge in Projekten.

Alle diese Dokumente haben einen gemeinsamen Nenner: Die Verantwortung für den Code bleibt beim Ingenieur. Ein KI-Werkzeug verkürzt die Zeit, in der Code entsteht, übernimmt aber keine Verantwortung für das Ergebnis und ändert nichts am Umfang der Prüfung, der dieser Code unterliegt.

Anwendung

Wie wir sie im Projekt anwenden

ISO/IEC 25010:2023Produktqualitätsmodell
Benennung und Struktur der nichtfunktionalen Anforderungen. In der Spezifikation halten wir messbare Ziele für die im jeweiligen Projekt wesentlichen Merkmale fest.In der Praxis: die Abnahmekriterien im Vertrag — Antwortzeit, Testabdeckung, Bewertung der Wartbarkeit.
BSI TR-03185sicherer Software-Lebenszyklus
Der Aufbau des gesamten Lebenszyklus: Anforderungen, Entwurf, Entwicklung, Tests, Release, Umgang mit Schwachstellen.In der Praxis: die Prozessbeschreibung und die Checklisten, die vor Projektbeginn übergeben werden.
BSI und ANSSIgemeinsame Empfehlungen für KI-Assistenten
Die Regeln für die Arbeit mit Code-Generatoren: Prüfung jedes Abschnitts, Bewusstsein für die Risiken, Kontrolle der Abhängigkeiten.In der Praxis: unsere interne Richtlinie zum Einsatz von KI-Werkzeugen, in einem gesonderten Dokument beschrieben.
OWASP Top 10:2025Risikokategorien
Die Liste der zehn Kategorien, mit der jedes Audit beginnt und nach der wir den Bericht gliedern.In der Praxis: ein nach den Kategorien A01–A10 gegliederter Auditbericht.
OWASP ASVS 5.0.0Verifikationsanforderungen
Überprüfbare Anforderungen, die für einen einzelnen Prüfpunkt ein eindeutiges Ergebnis liefern.In der Praxis: eine Liste der Feststellungen mit Bezug auf die ASVS-Anforderungsnummern.
Risikokategorien

Die Gliederung des Berichts nach OWASP Top 10:2025

In der Ausgabe 2025 sind zwei Kategorien hinzugekommen: die Software-Lieferkette und der Umgang mit Ausnahmesituationen.

A01Broken Access Control
A06Insecure Design
A02Security Misconfiguration
A07Authentication Failures
A03Software Supply Chain Failuresneu
A08Software or Data Integrity Failures
A04Cryptographic Failures
A09Security Logging and Alerting Failures
A05Injection
A10Mishandling of Exceptional Conditionsneu

Diese Liste verwenden wir im KI-Code-Audit als Gliederung des Berichts. Jede Feststellung fällt in eine der Kategorien und, wo es begründet ist, zusätzlich auf eine konkrete ASVS-Anforderung.

Prozess

Qualitätsschranken im Entwicklungsprozess

Die Schranken sind entweder automatisch oder erfordern eine zweite Person. Keine davon ist optional.

1CodeänderungArbeitsbranch 2Reviewzweiter Ingenieur 3Testsautomatisch in der Pipeline 4Analyse und ScansCode und Abhängigkeiten 5Releasenach Passieren der Schranken Kein Codeabschnitt gelangt unter Umgehung von Review und automatischen Schranken in die Produktion.
Konsequenzen

Was daraus für das Projekt folgt

Die Qualitätsziele legen wir vor dem Start fest — welche Merkmale wir messen und mit welchen Schwellenwerten. Das ist Teil der Abnahmekriterien, keine Marketingaussage.
Jede Feststellung hat eine Adresse — eine konkrete OWASP-Kategorie und, wo begründet, auch eine ASVS-Anforderungsnummer.
Die Rohergebnisse sind verfügbar — Berichte aus der Pipeline und Scan-Ergebnisse vom Tag der Abnahme übergeben wir auf Wunsch.
Das vollständige Dokument auf Wunsch — „Qualität und Engineering-Standards“ enthält die Prozessbeschreibung und die Checklisten. Wir übergeben es vor Arbeitsbeginn.
Quellen

Quellendokumente

Jede der obigen Aussagen lässt sich an der Quelle überprüfen. Nachstehend die Dokumente, auf die wir uns berufen.

Wie das im Vertrag aussieht

Sagen Sie uns, an welches Projekt Sie denken. Das vollständige Dokument zu Qualität und Standards übergeben wir vor Arbeitsbeginn.

Unverbindlich anfragen