Beispieldokument: Diese Regelung beschreibt den Sollprozess für die fiktive „Muster GmbH“. Reale Entwicklungsprojekte, Anwendungen, Repositories, Komponenten, Build- und Deploymentwege, Sicherheitsanforderungen, Testabdeckungen, Freigaben, Schwachstellen und Wirksamkeitsnachweise sind noch nicht vollständig erfasst oder bestätigt. Die Seite allein belegt keinen wirksamen sicheren Entwicklungslebenszyklus.
Nachweisregel: Ein erfolgreicher Build, ein grüner Pipeline-Status, ein automatischer Scan oder eine Freigabe im Ticketsystem belegt nicht automatisch, dass Sicherheitsanforderungen vollständig, Befunde behandelt und genau das geprüfte Artefakt unverändert produktiv eingesetzt wurden. Anforderungen, Änderungen, Tests, Entscheidungen, Artefakte und Deployment müssen nachvollziehbar verbunden sein.
TISAX-Hinweis: Die Kontrollfragen zu Systembeschaffung, Anforderungsmanagement und Entwicklung sind Bestandteil der 46 Informationssicherheitsfragen. Alle 46 Fragen werden umgesetzt und bewertet; eine individuelle Auswahl „anwendbar/nicht anwendbar“ wie in der Statement of Applicability ist nicht vorgesehen. Diese Spezialregelung unterstützt mehrere Kontrollfragen, ersetzt aber nicht deren einzelne Bewertung in der VDA-ISA-Selbsteinschätzung.
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-MA-04-07 |
| Dokumentenart | Regelung / Sicherer Entwicklungslebenszyklus |
| Wiki.js-Pfad | /ISMS/04-Sicherheitsregelungen/Sichere-Entwicklung |
| Verantwortlich | Entwicklungsleitung |
| Fachlich geprüft durch | ISMS-Beauftragte/r, IT-Leitung, Architektur, Betrieb, Datenschutz, Einkauf sowie betroffene Product-, Application- und Information Owner |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – Entwicklungsbestand, Security Gates und Wirksamkeit nicht bestätigt |
| Version | 0.1 |
| Stand | 23.07.2026 |
| Gültig ab | Nach Freigabe |
| Nächste Prüfung | Spätestens zwölf Monate nach Freigabe sowie anlassbezogen |
| Schutzklasse | Intern; Quellcode-, Architektur-, Schwachstellen-, Schlüssel- und Pipelineinformationen Vertraulich bis Streng vertraulich |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Annex A 5.8, A 5.19 bis A 5.23, A 8.4 und A 8.25 bis A 8.33 |
| VDA-ISA-Bezug | ISA 6.0.3, insbesondere Kapitel 5.3 Systembeschaffung, Anforderungsmanagement und Entwicklung; Schnittstellen zu 1.3, 1.4, 1.5, 4.2, 5.1, 5.2 und 6.1 |
Diese Regelung legt fest, wie Informationssicherheit und Datenschutz in Planung, Anforderung, Architektur, Entwicklung, Beschaffung, Test, Freigabe, Bereitstellung, Betrieb, Wartung und Außerbetriebnahme von Software und Systemen integriert werden.
Sie soll insbesondere sicherstellen, dass:
Die Regelung gilt für:
Der konkrete Umfang wird mit Geltungsbereich und Standorte, Asset-Inventar, Prozesslandkarte und Lieferanten und Dienstleister abgeglichen.
| Begriff | Bedeutung in dieser Regelung |
|---|---|
| SDLC | Lebenszyklus von Planung und Anforderung bis Wartung und Außerbetriebnahme |
| Secure by Design | Sicherheit wird als Entwurfsanforderung berücksichtigt und nicht nur nachträglich getestet |
| Secure by Default | Standardkonfiguration bietet einen angemessenen sicheren Ausgangszustand |
| Security Requirement | Prüffähige funktionale oder nichtfunktionale Sicherheitsanforderung |
| Threat Modeling | Strukturierte Ermittlung von Schutzobjekten, Vertrauensgrenzen, Bedrohungen und Gegenmaßnahmen |
| Security Gate | Entscheidungspunkt mit Mindestkriterien für den Übergang in die nächste Phase |
| SAST | Statische Analyse von Quellcode oder Artefakten |
| DAST | Dynamische Prüfung einer laufenden Anwendung |
| SCA | Analyse eingesetzter Dritt- und Open-Source-Komponenten |
| SBOM | Strukturierte Komponentenliste einer Software einschließlich Versionen und Beziehungen |
| CI/CD | Automatisierter Integrations-, Build-, Test- und Bereitstellungsprozess |
| Artefakt | Erzeugtes Softwarepaket, Image, Binärdatei oder Deploymentobjekt |
| Provenienz | Nachvollziehbare Herkunft und Erzeugung eines Artefakts oder einer Komponente |
| Secret | Passwort, Token, privater Schlüssel oder andere vertrauliche Authentisierungsinformation |
| Security Debt | Bekannte, noch nicht behandelte Sicherheitslücke oder unsichere Altlast |
| Rolle | Verantwortung |
|---|---|
| Geschäftsführung | Ressourcen und wesentliche Restrisiken entscheiden |
| Entwicklungsleitung | sicheren Entwicklungsprozess, Rollen, Werkzeuge, Gates und Kompetenz verantworten |
| Product-/Projektverantwortung | Geschäftsziel, Scope, Anforderungen, Termine und Freigaben koordinieren |
| Product-/Application Owner | Schutzbedarf, Lebenszyklus, Restrisiken, Wartung und Abnahme verantworten |
| Information Owner | Klassifizierung, Zugriff, Nutzung, Aufbewahrung und Löschung festlegen |
| Security-/Softwarearchitektur | Bedrohungsmodell, Vertrauensgrenzen und Sicherheitsarchitektur gestalten |
| Entwicklung | Anforderungen sicher umsetzen, Änderungen dokumentieren und Befunde behandeln |
| Peer Reviewer | Code und Änderungen angemessen unabhängig prüfen |
| Test-/Qualitätssicherung | technische, sicherheitsbezogene und fachliche Kriterien prüfen |
| DevOps/Plattformteam | Repository, Pipeline, Build, Artefakte und Deployment betreiben |
| Informationssicherheitsfunktion | Methodik, Risiko, Ausnahmen und Wirksamkeitskontrollen prüfen |
| Datenschutz | Privacy by Design, Datenminimierung und Testdaten beraten |
| IT-/OT-Betrieb | Betriebsanforderungen, Monitoring, Patchfähigkeit und Übergabe prüfen |
| Einkauf/Lieferantenmanagement | externe Entwicklung, Komponenten, Verträge und Nachweise steuern |
| Interne Revision/Audit | Prozess, Stichproben und Wirksamkeit prüfen |
Bei kritischen Änderungen darf dieselbe Person nicht ohne begründete Kompensation allein entwickeln, prüfen, freigeben und produktiv setzen.
| Phase | Sicherheitsaktivitäten | Gate-Ergebnis |
|---|---|---|
| Idee und Bedarf | Zweck, Daten, Scope, Kritikalität und Risiken erfassen | Sicherheitsrelevanz bestimmt |
| Anforderungen | Sicherheits-, Datenschutz-, Kunden- und Betriebsanforderungen definieren | prüfbare Baseline freigegeben |
| Architektur | Bedrohungsmodell, Vertrauensgrenzen und Kontrollen festlegen | Architekturentscheidung freigegeben |
| Umsetzung | sichere Programmierung, Review, Komponenten- und Secret-Steuerung | Änderungen geprüft |
| Build und Test | vertrauenswürdiger Build, automatisierte und manuelle Tests | Kriterien erfüllt oder Abweichung entschieden |
| Abnahme und Release | Risiken, Befunde, Artefakt, Rückfall und Betrieb prüfen | Releaseentscheidung dokumentiert |
| Deployment und Betrieb | kontrollierte Bereitstellung, Monitoring und Verifikation | produktiver Sollstand bestätigt |
| Wartung | Schwachstellen, Komponenten, Änderungen und Support steuern | unterstützter sicherer Zustand |
| Außerbetriebnahme | Migration, Daten, Zugänge und Abhängigkeiten bereinigen | sicherer Abschluss nachgewiesen |
Ein Gate ist nur passiert, wenn Scope, Kriterien, offene Abweichungen und befugte Entscheidung nachvollziehbar sind.
| Feld | Mindestinhalt |
|---|---|
| ID und Zweck | Eindeutige Referenz und Geschäftsnutzen |
| Owner | Product-, Application-, Information- und technische Verantwortung |
| Status | Planung, Entwicklung, Test, Betrieb, Wartung oder Ende |
| Technologie | Plattform, Sprache, Framework und Betriebsmodell |
| Daten | Kategorien, Klassifizierung und Personen-/Kunden-/Prototypenbezug |
| Exposition | Internet, Partner, intern, OT oder isoliert |
| Kritikalität | Schutzbedarf, Geschäfts- und Sicherheitswirkung |
| Entwicklungsmodell | intern, extern, Open Source, Standardsoftware oder Kombination |
| Repositories/Pipelines | geschützte Referenzen |
| Abhängigkeiten | Komponenten, Dienste, Lieferanten und Plattformen |
| Security Level | festgelegte Prüftiefe |
| Release/Support | Rhythmus, Updatefähigkeit und EOL |
| ID | Anwendung/Projekt | Owner | Kritikalität | Exposition | Modell | Security Level | Status |
|---|---|---|---|---|---|---|---|
| DEV-001 | Noch zu erfassen | Noch zu benennen | Nicht bewertet | Nicht erhoben | Nicht bestätigt | Nicht festgelegt | Offen |
Der Beispieleintrag stellt kein reales Produkt und keine durchgeführte Bewertung dar.
Die Prüftiefe berücksichtigt:
| Level | Typische Einordnung | Mindesttiefe im Entwurf |
|---|---|---|
| SL1 Basis | geringe Kritikalität und begrenzte Exposition | Anforderungen, Peer Review, Komponenten- und Basistests |
| SL2 Erhöht | sensible Daten, kritische Prozesse oder relevante externe Schnittstellen | Bedrohungsmodell, vertiefte Reviews, automatisierte und manuelle Tests, Security-Abnahme |
| SL3 Hoch | Internetexposition, Privilegien, besonders sensible Daten, Produktion/Safety oder hohe Schadenswirkung | unabhängige Architekturprüfung, vertiefte Tests, Penetrationstest und strenge Release-Gates |
Statushinweis: Das Levelmodell ist ein nicht freigegebener Organisationsentwurf und keine automatische Übernahme einer OWASP-, ISO- oder TISAX-Stufe.
Sicherheitsanforderungen werden aus Schutzbedarf, Risiko, Recht, Vertrag und Kundenanforderungen abgeleitet, mit eindeutiger ID und Owner dokumentiert, mit Akzeptanzkriterien versehen und Architektur, Umsetzung sowie Tests zugeordnet.
| Anforderungs-ID | Quelle | Anforderung | Priorität | Akzeptanzkriterium | Umsetzung | Test | Status |
|---|---|---|---|---|---|---|---|
| SEC-REQ-001 | [Risiko/Vertrag/Standard] |
[Prüfbare Anforderung] |
[Muss/Soll] |
[Messbares Kriterium] |
[Design/Komponente] |
[Test-ID] |
Offen |
Typische Felder sind:
Bereits in Anforderung und Design werden Zweck, Datenminimierung, Rechtsgrundlage, Empfänger, Aufbewahrung, Löschung, Betroffenenrechte, internationale Übermittlungen, Kunden- und Prototypenschutz sowie Testdaten geprüft.
Die Einstufung erfolgt über Informationsklassifizierung. Produktivdaten werden nur nach dokumentierter Notwendigkeit, Freigabe und angemessenen Schutzmaßnahmen für Tests verwendet.
Bedrohungsmodelle werden für neue, wesentliche oder hochriskante Entwicklungen erstellt und bei relevanten Änderungen aktualisiert.
| Feld | Inhalt |
|---|---|
| Scope | System, Version, Umgebung und Grenzen |
| Schutzobjekte | Daten, Funktionen, Identitäten, Schlüssel und Dienste |
| Akteure | Nutzende, Admins, Dienste, Lieferanten und mögliche Angreifer |
| Datenflüsse/Vertrauensgrenzen | Quellen, Ziele, Protokolle und Übergänge |
| Angriffsflächen | Eingaben, Dateien, APIs, Adminwege und Lieferkette |
| Bedrohungen | Missbrauchs- und Angriffsszenarien |
| Kontrollen/Restrisiken | Prävention, Erkennung, Behandlung und Owner |
| Annahmen/Review | Gültigkeitsgrenzen, Beteiligte und Aktualisierung |
| Threat-ID | Schutzobjekt/Datenfluss | Szenario | Auswirkung | Kontrolle | Maßnahme | Owner | Status |
|---|---|---|---|---|---|---|---|
| THR-001 | [Objekt/Fluss] |
[Missbrauchsszenario] |
[Schutzziel/Geschäft] |
[Kontrolle] |
[Behandlung] |
[Rolle] |
Offen |
Ein Diagramm ohne bewertete Bedrohungen, Maßnahmen und Owner ist kein vollständiges Bedrohungsmodell.
Architekturentscheidungen berücksichtigen:
| Entscheidungs-ID | Kontext | Optionen | Sicherheitswirkung | Entscheidung | Restrisiko | Review |
|---|---|---|---|---|---|---|
| SEC-ADR-001 | [Auslöser] |
[Optionen] |
[Risiken/Kontrollen] |
[Lösung] |
[Bewertung] |
[Datum] |
Anwendungen berücksichtigen eindeutige Identitäten, angemessene starke Authentisierung, serverseitige Autorisierung, Minimalrechte, standardmäßig verweigerten Zugriff, Mandanten- und Objekttrennung, sichere Sitzungen, risikobasierte erneute Authentisierung und geschützte Kontowiederherstellung.
Die übergreifende Steuerung erfolgt über Zugriff und Berechtigungen.
Sichere Verarbeitung umfasst:
Clientseitige Prüfungen ersetzen keine serverseitige Kontrolle.
Es gelten:
Die Steuerung erfolgt über Kryptografie und Schlüssel.
Im Design wird festgelegt, welche Sicherheits-, Administrations- und Geschäftsereignisse erforderlich sind, welche Kontextdaten benötigt werden, wie Manipulation verhindert, sensible Inhalte vermieden, Fehler sicher behandelt, Alarme angebunden sowie Aufbewahrung und Löschung geregelt werden.
Passwörter, Tokens, private Schlüssel und besonders sensible Nutzdaten werden nicht unkontrolliert protokolliert.
Für Dritt- und Open-Source-Komponenten werden:
Eine Komponentenfreigabe gilt nur für Zweck, Version, Quelle und geprüften Kontext.
Je nach Kritikalität, Kundenanforderung und Lieferkettenrisiko wird eine aktuelle Komponentenliste beziehungsweise SBOM erzeugt.
| Artefakt | Komponente | Version | Quelle/Hash | Lizenz | Beziehung | Support/EOL | Schwachstellenstatus | Freigabe |
|---|---|---|---|---|---|---|---|---|
| Noch zu erfassen | Noch zu erfassen | Nicht bestätigt | Nicht geprüft | Nicht bewertet | Nicht erhoben | Nicht geprüft | Nicht bewertet | Offen |
Eine SBOM allein belegt keine sichere Lieferkette. Aktualität, Provenienz, Schwachstellenbewertung und Behandlung bleiben erforderlich.
Repositories werden durch eindeutige Identitäten, MFA, Minimalrechte, geschützte Haupt- und Release-Branches, verpflichtende Reviews, kontrollierte Tokens, Protokollierung, Backup, Berechtigungsreviews und geregelte Archivierung geschützt.
Direkte unkontrollierte Änderungen am freigegebenen Release-Stand werden verhindert oder als Notfalländerung nachbearbeitet.
Entwicklungsgeräte und Werkzeuge werden inventarisiert, gehärtet, aktualisiert, gegen Schadsoftware und Verlust geschützt sowie mit getrennten Entwicklungs-, Test- und Produktivzugängen betrieben.
Persönliche Geräte oder nicht freigegebene Dienste dürfen nicht ohne dokumentierte Bewertung für vertraulichen Quellcode oder Kundendaten genutzt werden.
Build- und Deploymentprozesse stellen sicher:
Je nach Risiko werden kontrollierte Builds, eindeutige Build-IDs, Hashes oder Signaturen, geschützte Artefaktablagen, Zuordnung zu Commit und Komponenten sowie Integritätsprüfung beim Deployment eingesetzt.
Eine digitale Signatur ersetzt weder Sicherheitsprüfung noch sichere Schlüssel- und Buildprozesse.
Entwicklung, Test, Abnahme, Staging und Produktion werden durch unterschiedliche Rollen, Secrets, Schlüssel, Zertifikate, Datenflüsse und kontrollierte Artefaktübergaben angemessen getrennt.
Produktivdaten und direkte Produktivänderungen werden nicht automatisch freigegeben. Die Schnittstelle wird in IT-Betrieb und Änderungen gesteuert.
Synthetische oder anonymisierte Daten werden bevorzugt. Produktivdaten benötigen dokumentierte Notwendigkeit, Freigabe, Klassifizierung, Zugriffsschutz, Datenminimierung, begrenzte Testdauer und sichere Löschung.
Maskierung wird auf Re-Identifikations- und Rückschlussmöglichkeiten geprüft.
Technologiebezogene Regeln behandeln mindestens:
Reviews prüfen Anforderungsbezug, fachliche Korrektheit, Sicherheit, Datenschutz, Architektur, Berechtigungen, Datenflüsse, Fehler, Logs, Komponenten, Secrets und Tests.
| Änderung/Commit | Anforderung | Prüfer/in | Prüfumfang | Feststellungen | Behandlung | Ergebnis | Datum |
|---|---|---|---|---|---|---|---|
[Referenz] |
[Ticket] |
[Rolle] |
[Scope] |
[Befunde] |
[Änderung] |
Offen | [Datum] |
Ein pauschales „LGTM“ ohne erkennbaren Prüfumfang ist für kritische Änderungen kein ausreichender Nachweis.
| Prüfart | Ziel | Typische Grenze |
|---|---|---|
| SAST | unsichere Codekonstrukte und Datenflüsse erkennen | Fehlalarme und begrenzter Laufzeitkontext |
| DAST | laufende Anwendung prüfen | interne Codepfade nicht vollständig sichtbar |
| SCA | Komponenten und bekannte Schwachstellen erkennen | Nutzungskontext kann fehlen |
| Secret Scan | gespeicherte Geheimnisse finden | offengelegte Secrets müssen widerrufen werden |
| IaC-/Konfigurationsscan | unsichere Infrastrukturdefinitionen erkennen | reale Drift kann fehlen |
| Container-/Image-Scan | Pakete und Konfiguration prüfen | Laufzeitkontext begrenzt |
| API-/Fuzz-Test | unerwartete Eingaben und Zustände prüfen | benötigt geeigneten Scope |
| Lizenzprüfung | unzulässige Komponenten erkennen | rechtliche Bewertung nicht voll automatisierbar |
Ergebnisse werden validiert, priorisiert, Ownern zugewiesen und bis zur verifizierten Behandlung verfolgt.
Manuelle Tests prüfen komplexe Berechtigungen, Geschäftslogik und Angriffsketten. Penetrationstests werden autorisiert, mit Scope und Abbruchkriterien geplant, durch qualifizierte Personen durchgeführt und in Maßnahmen sowie Wiederholungstests überführt.
Ein Penetrationstest gilt nur für geprüfte Version, Umgebung, Scope und Zeitpunkt.
Für relevante Releases werden Sicherheitsanforderungen, positive und negative Testfälle, Umgebung, Daten, Methoden, erwartete Ergebnisse, Fehlalarme, Wiederholung nach Korrektur und erforderliche Unabhängigkeit festgelegt.
| Test-ID | Anforderung/Threat | Methode | Version/Umgebung | Erwartung | Ergebnis | Befund | Nachweis |
|---|---|---|---|---|---|---|---|
| SEC-TST-001 | [SEC-REQ/THR] |
[SAST/DAST/manuell] |
[Build/Umgebung] |
[Kriterium] |
Nicht durchgeführt | – | – |
Traceability verbindet Anforderung, Bedrohung, Codeänderung, Test, Befund, Korrektur, Artefakt und Release.
| Befundklasse | Typische Releaseentscheidung |
|---|---|
| Akut/Kritisch | keine reguläre Freigabe; unverzügliche Behandlung oder besonders autorisierte Notfallentscheidung |
| Hoch | vor Release behandeln; Ausnahme nur mit belastbarer Risikoentscheidung |
| Mittel | risikobasiert behandeln oder befristet mit Owner und Termin steuern |
| Niedrig | geplant behandeln und überwachen |
| False Positive/Nicht betroffen | technisch reproduzierbar begründen und gegenprüfen |
Die Priorität wird nach Schwachstellen- und Patchmanagement bestimmt.
| Gate-Kriterium | Nachweisstatus |
|---|---|
| Scope, Version und Owner eindeutig | Nicht bestätigt |
| Sicherheitsanforderungen erfüllt | Nicht bewertet |
| Bedrohungsmodell und Architektur aktuell | Nicht vorgelegt |
| Reviews und Sicherheitstests abgeschlossen | Keine vollständige Stichprobe |
| Komponenten/SBOM aktuell | Nicht vollständig |
| offene Befunde bewertet | Nicht vollständig erhoben |
| Datenschutz und Kundenanforderungen geprüft | Nicht bestätigt |
| Betrieb, Monitoring und Recovery vorbereitet | Nicht geprüft |
| Deployment und Rückfall getestet | Nicht nachgewiesen |
| Artefaktintegrität und Provenienz bestätigt | Nicht nachgewiesen |
| Feld | Eintrag |
|---|---|
| Release-/Build-ID | [Eindeutige Version] |
| freigegebenes Artefakt | [Hash/Signatur/Repository] |
| erfüllte Gates | [Referenzen] |
| offene Befunde/Restrisiken | [IDs/Genehmigung] |
| Deployment/Rückfall | [Change/Runbook] |
| technische, Sicherheits- und Fachfreigabe | [Rollen/Datum] |
Die Produktivsetzung eines anderen als des geprüften Artefakts macht die Freigabe ungültig.
Deployment erfolgt aus freigegebener Ablage, mit minimal berechtigten Zugängen, kontrolliertem Change, geprüftem Rückfall und Monitoring.
Danach werden eingesetzte Version und Hash, sichere Konfiguration, wesentliche Kontrollen, Schnittstellen, Datenmigration, Logging und das Fehlen unzulässiger Debug- oder Standardzugänge geprüft.
Bei dringenden Hotfixes dürfen Prüfungen nur reduziert werden, wenn Bedrohung und Zeitkritikalität dokumentiert, eine befugte Rolle entscheidet, Mindesttests stattfinden, Rückfall vorbereitet und ausgelassene Kontrollen terminiert nachgeholt werden.
Ein dauerhaft genutzter Hotfix ohne Integration in den regulären Code-, Build- und Teststand ist eine Abweichung.
Für freigegebene Software werden Hersteller-, CERT-, Komponenten- und Forschungsmeldungen überwacht, betroffene Produkte ermittelt, Korrekturen erstellt, sicher verteilt und verifiziert.
Eine Korrektur gilt erst als umgesetzt, wenn sie im freigegebenen Artefakt enthalten, produktiv beziehungsweise beim Empfänger verfügbar und geprüft ist.
Geregelt werden ein geschützter Meldekanal, Triage, Validierung, vertrauliche Kommunikation, Korrektur, koordinierte Veröffentlichung und Übergang zu Incident Response bei Ausnutzung oder Kompromittierungsverdacht.
Externe Entwicklung wird durch Vertragsanforderungen, Quellcode- und Nutzungsrechte, Geheimhaltung, Qualifikation, Unterauftragnehmersteuerung, kontrollierte Zugriffe, Komponenteninformationen, Tests, Schwachstellenmeldung, Übergabe, Support, EOL und Exit gesteuert.
Interne Owner bleiben für Anforderungen, Abnahme, Restrisiko und Betriebsübergabe verantwortlich.
Geprüft werden Sicherheitsfunktionen, sichere Konfiguration, Authentisierung, Logging, Schnittstellen, Entwicklungs- und Lieferkettennachweise, Schwachstellenmeldung, Support/EOL, Datenschutz, Mandantentrennung, Backup, Export und Integrität von Updates.
Marketingaussagen oder Zertifikate werden entsprechend Risiko verifiziert.
APIs und Integrationen benötigen dokumentierte Owner, Datenflüsse, starke Identitäten, serverseitige Autorisierung, Eingabeprüfung, Rate Limits, Protokollierung und Lebenszyklussteuerung.
Für Cloud, Container und IaC werden Accounts, Regionen, Baselines, Rollen, State-Dateien, Secrets, Basisimages, Registries, Netzwerke, Logging, Policy-as-Code, Drift und Providerverantwortung geprüft.
Ein bestandener IaC-Scan beweist nicht, dass die reale Umgebung dem Sollstand entspricht.
Zusätzlich werden Safety, lange Lebenszyklen, sichere Boot- und Updateverfahren, Debugzugänge, Hardwareabhängigkeiten, Signierung, Feld-Update, Rückfall, Toolchain, physische Manipulation und Lieferkette berücksichtigt.
Technische Einschränkungen begründen keine automatische Dauerfreigabe.
Bei Codeassistenten werden Dienstfreigabe, zulässige Daten, Speicherung, Training, Rechte, Lizenzen, Herkunft, unsichere Vorschläge, erfundene Paketnamen, menschliches Review, Tests und Exit geprüft.
KI-generierter Code wird wie nicht vertrauenswürdiger Fremdcode behandelt, bis Review, Tests, Komponentenprüfung und Freigabe erfolgt sind.
Repositories, Pipelinekonfigurationen, Artefakte, IaC, SBOM, Release- und Signaturnachweise werden nach Datensicherung und Wiederherstellung geschützt.
Vor Betriebsübergabe sind Owner, Inventar, Anforderungen, Architektur, Baseline, Deployment, Monitoring, Backup, Schwachstellenverfahren, Support und offene Risiken dokumentiert.
Bei Außerbetriebnahme werden Daten, Konten, Tokens, Schlüssel, Zertifikate, Repositories, Pipelines, Schnittstellen, DNS, Lieferantenzugänge und Inventar kontrolliert behandelt.
Mindestens aufbewahrt werden:
Sensible Schwachstellen, Quellcode, Architektur und Secrets werden geschützt abgelegt.
| Kennzahl | Berechnung/Interpretation |
|---|---|
| Portfolioabdeckung | bewertete Anwendungen/Projekte / bestätigter Bestand |
| Anforderungsabdeckung | geprüfte Sicherheitsanforderungen / freigegebene Anforderungen |
| Bedrohungsmodellabdeckung | aktuelle Modelle / hierfür vorgesehene Entwicklungen |
| Reviewabdeckung | Änderungen mit erforderlichem Review / reviewpflichtige Änderungen |
| Komponentenabdeckung | Releases mit aktuellem Register/SBOM / hierfür vorgesehene Releases |
| Gate-Erfüllung | Releases mit belegten Gates / freigegebene Releases |
| offene Befunde | validierte Befunde nach Schwere und Alter |
| Ausnahmebestand | offene Ausnahmen nach Alter und Ablauf |
| Produktivverifikation | Deployments mit bestätigtem Artefakt / produktive Deployments |
| EOL-Bestand | Anwendungen oder Komponenten ohne Ablöseplan |
| Kennzahl | Stand Entwurf |
|---|---|
| bestätigtes Portfolio | Nicht vollständig erfasst |
| Security-Level-/Bedrohungsmodellabdeckung | Nicht berechenbar |
| Review- und Testabdeckung | Nicht organisationsweit erhoben |
| Komponenten-/SBOM-Abdeckung | Nicht berechenbar |
| Gate-Erfüllung und Produktivverifikation | Nicht nachgewiesen |
| offene Befunde und Ausnahmen | Nicht vollständig erhoben |
Die Regelung behandelt insbesondere RIS-2026-001, RIS-2026-005, RIS-2026-010, RIS-2026-012 und RIS-2026-013.
RIS-2026-013 und M-013 bleiben offen, bis Komponenten und Lieferanten zugeordnet, Herkunft und Integrität geprüft, Schwachstellen behandelt und wirksame Entwicklungs- sowie Lieferkettenkontrollen nachgewiesen sind.
Die Steuerung erfolgt im Risikoregister, Risikobehandlungsplan und gegebenenfalls über Ausnahmen und Risikoakzeptanzen.
Für TISAX gilt:
| TISAX-Prüfaspekt | Nachweisstatus |
|---|---|
| Kapitel 5.3 einzeln bewertet | Nein; 0 von 4 Kontrollfragen |
| Entwicklungs-/Anwendungsbestand bestätigt | Nein |
| Anforderungen und Security Levels freigegeben | Nein |
| Architektur-, Review- und Testnachweise vorhanden | Nicht vollständig |
| Komponenten und Lieferkette gesteuert | Nicht nachgewiesen |
| externe Entwicklung kontrolliert | Nicht vollständig bewertet |
| Gesamtumfang Informationssicherheit | 0 von 46 Fragen bewertet |
Die Regelung unterstützt Annex A 8.25 bis A 8.33 sowie verbundene Controls zu Projekten, Lieferanten, Quellcodezugriff, Kryptografie, Schwachstellen und Änderungen.
Die Statement of Applicability dokumentiert Anwendbarkeit und Umsetzungsstatus der Annex-A-Controls, ersetzt aber keine Projekt-, Test-, Komponenten- und Release-Nachweise.
| Kontrolle | Prüfinhalt | Status |
|---|---|---|
| Portfolioabgleich | Anwendungen, Projekte, Owner und Status | Nicht durchgeführt |
| Security-Level-Review | Kritikalität, Exposition und Prüftiefe | Nicht nachgewiesen |
| Anforderungen/Threat Model | Prüfbarkeit, Bedrohungen und Traceability | Nicht vollständig |
| Repository/Pipeline | Rechte, Branches, Tokens, Gates und Provenienz | Nicht geprüft |
| Komponenten/SBOM | Herkunft, Version, Lizenz, Schwachstellen und EOL | Nicht vollständig |
| Reviews/Tests | Code Review, automatisierte und manuelle Prüfungen | Keine vollständige Stichprobe |
| Release/Deployment | Befunde, Artefakt, Freigabe und Produktivverifikation | Nicht nachgewiesen |
| Lieferanten/EOL | Vertrag, Übergabe, Wartung und Ablösung | Nicht vollständig |
Geeignete Auditstichproben sind ein Projekt vom Security Level bis Release, eine Anforderung bis Produktivtest, ein Repository, ein Artefakt mit Provenienz, eine Komponente bis zur Schwachstellenbehandlung, ein Secret-Fund, eine Gate-Ausnahme, eine externe Entwicklung und ein Hotfix.
Audits erfolgen über Auditprogramm und Interne Audits.
Abweichungen sind beispielsweise fehlende Portfolioeinträge, unprüfbare Anforderungen, veraltete Bedrohungsmodelle, umgangene Gates, offengelegte Secrets, unklare Komponentenherkunft, formale Reviews ohne Prüftiefe, unbehandelte Befunde, abweichende Produktivartefakte oder ungesteuertes EOL.
Sie werden über Abweichungen und Korrekturmaßnahmen behandelt. Ursache und ähnliche Produkte werden mitgeprüft.
| Offener Punkt | Verantwortung | Status |
|---|---|---|
| Entwicklungs- und Anwendungsportfolio erfassen | Entwicklung / IT | Offen |
| Security-Level- und Gate-Kriterien freigeben | Geschäftsführung / Entwicklung / ISMS | Offen |
| Anforderungsregister und Traceability einrichten | Product Owner / Entwicklung | Offen |
| Bedrohungsmodell und Architekturverfahren operationalisieren | Architektur / ISMS | Offen |
| sichere Programmierregeln freigeben | Entwicklungsleitung | Offen |
| Repository-, Pipeline- und Artefaktschutz nachweisen | DevOps / IT | Offen |
| Komponentenregister/SBOM und Lizenzprüfung einführen | Entwicklung / Einkauf / Recht | Offen |
| Teststrategie und Freigabeschwellen festlegen | Entwicklung / Test / ISMS | Offen |
| Release- und Produktivverifikation einrichten | Entwicklung / Betrieb | Offen |
| Testdaten- und Datenschutzverfahren prüfen | Datenschutz / Fachbereiche | Offen |
| externe Entwicklung und KI-Werkzeuge bewerten | Einkauf / Entwicklung / ISMS | Offen |
| RIS-2026-013 und M-013 bearbeiten | Entwicklung / Einkauf / IT | Offen |
| Kapitel 5.3 kontrollfragenbezogen bewerten | TISAX / Entwicklung / ISMS | Offen |
| Wirksamkeitsstichprobe durchführen | Interne Audits | Offen |
| Prüffrage | Status Entwurf |
|---|---|
| Sind alle Entwicklungen, Anwendungen und Owner bekannt? | Nein |
| Sind Kritikalität, Security Levels und Gates bestätigt? | Nein |
| Sind Anforderungen prüfbar und nachvollziehbar? | Keine vollständige Stichprobe |
| Sind Bedrohungsmodelle und Architekturentscheidungen aktuell? | Nicht nachgewiesen |
| Sind Repositories, Pipelines und Artefakte geschützt? | Nicht vollständig geprüft |
| Sind Secrets und Schlüssel angemessen gesteuert? | Nicht nachgewiesen |
| Sind Komponenten, Herkunft, Lizenzen und Schwachstellen transparent? | Nicht vollständig |
| Ergänzen sich automatisierte und manuelle Tests? | Nicht organisationsweit belegt |
| Werden Befunde bis in die Produktivversion verifiziert? | Nicht nachgewiesen |
| Ist das Produktivartefakt dem geprüften Build zugeordnet? | Nicht nachgewiesen |
| Sind externe Entwicklung, Cloud, OT und KI einbezogen? | Teilweise als Soll beschrieben |
| Sind alle vier Kontrollfragen aus Kapitel 5.3 bewertet? | Nein; 0 von 4 |
| Sind alle 46 Informationssicherheitsfragen berücksichtigt? | Ja als Sollumfang; 0 von 46 bewertet |
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 23.07.2026 | Regelung für Anforderungen, Architektur, Code, Komponenten, Build, Tests, Release und Wartung angelegt | Entwicklungsleitung / ISMS | Ausstehend | – |
| Funktion | Name | Entscheidung | Datum |
|---|---|---|---|
| Geschäftsführung | – | Ausstehend | – |
| Entwicklungsleitung | – | Fachliche Prüfung ausstehend | – |
| IT-/Betriebsverantwortliche/r | – | Betriebsprüfung ausstehend | – |
| ISMS-Beauftragte/r | – | Sicherheitsprüfung ausstehend | – |
| Datenschutz/Einkauf | – | Datenschutz- und Lieferkettenprüfung ausstehend | – |
Maßgeblich bleiben die lizenzierten Normtexte, die für das konkrete Assessment gültige offizielle ISA-Arbeitsmappe, der bestätigte TISAX Assessment Scope sowie die freigegebenen Rechts-, Vertrags-, Kunden-, Datenschutz-, Produkt-, Betriebs- und Sicherheitsanforderungen.