NIS2 Art. 21 · NIST SSDF · OWASP ASVS

NIS2 Software Security Assessment

Strukturiertes Software Security Assessment für NIS2-relevante Umgebungen

Das Assessment baut auf unserem Security Code Review auf und erweitert es um einen definierten Kontrollkatalog, Evidence-Anforderungen und dokumentierte Pass-/Fail-Kriterien. So erhältst du einen nachvollziehbaren Nachweis, wie deine Software relevante NIS2-Sicherheitsanforderungen adressiert.

NIS2 Assessment anfragenSecurity Code Review ansehen

Ein Software-Assessment kann die NIS2-Konformität deines gesamten Unternehmens weder herstellen noch bestätigen.

Für wen ist das sinnvoll?

Das Assessment ist ein optionales Zusatzmodul. Du brauchst es nur, wenn du einen strukturierten Nachweis benötigst. Sonst reicht ein Security Code Review.

NIS2-relevante Unternehmen

Dein Unternehmen fällt selbst unter NIS2 und du willst die Sicherheit selbst entwickelter Software nachvollziehbar belegen.

Softwarelieferanten

Du lieferst Software an Unternehmen, die NIS2-relevant sind, und wirst nach Sicherheitsnachweisen gefragt.

Supply-Chain-Dokumentation

Du musst Abhängigkeiten, Build-Prozess und den Umgang mit Schwachstellen deiner Software dokumentieren.

Strukturierter Security-Nachweis

Du brauchst mehr als eine Findings-Liste: definierte Controls, Evidence und ein nachvollziehbares Ergebnis.

Procurement & Vendor Assessments

Deine Kunden stellen in Ausschreibungen oder Lieferantenbewertungen konkrete Anforderungen an Software-Sicherheit.

Was das Assessment vom Security Code Review unterscheidet

Der technische Security Review bleibt der Kern. Das Assessment ergänzt ihn um Struktur und Nachweisbarkeit und erfindet dabei nichts neu: Die Controls leiten sich aus NIS2 Art. 21, der Durchführungsverordnung (EU) 2024/2690 und den ENISA-Leitlinien ab und sind auf offene Standards wie NIST SSDF, OWASP ASVS und CWE abgebildet.

Definierte Controls

Geprüft wird gegen einen festen Kontrollkatalog statt nur gegen den individuell vereinbarten Scope.

Evidence-Anforderungen

Für jedes Control ist festgelegt, welche Nachweise erwartet werden, etwa Konfigurationen, Pipeline-Definitionen oder Prozessdokumente.

Dokumentierte Prüfschritte

Jeder Prüfschritt ist beschrieben und damit auch für Dritte nachvollziehbar.

Pass-/Fail-Kriterien

Klare Kriterien, wann ein Control als erfüllt gilt, statt einer reinen Einschätzung.

Supply Chain & Vulnerability Management

Neben dem Code betrachten wir Abhängigkeiten, Build-Prozess und den Umgang mit Schwachstellen über den Lebenszyklus.

NIS2 Mapping

Die Ergebnisse werden dokumentiert auf relevante Anforderungen aus NIS2 Art. 21 abgebildet, als Nachvollziehbarkeitshilfe und nicht als Nachweis, dass eine Rechtspflicht erfüllt ist.

Was wird geprüft? Die 10 Domains

NIS2 Art. 21 adressiert unter anderem die Sicherheit der Lieferkette, die Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen sowie den Umgang mit Schwachstellen. Unser Kontrollkatalog bildet die dafür relevanten Software-Sicherheitsaspekte in zehn Domains ab.

  1. 01

    Governance & Risk

    Verantwortlichkeiten, Sicherheitsanforderungen und Risikobewertung für die Software.

  2. 02

    Architecture & Threat Modeling

    Sicherheitsarchitektur, Vertrauensgrenzen und dokumentierte Bedrohungsanalyse.

  3. 03

    Secure Software Development

    Sichere Entwicklungspraktiken, Code Reviews und Coding-Richtlinien.

  4. 04

    Authentication & Authorization

    Anmeldung, Sessions, Rollen und Rechteprüfung.

  5. 05

    Cryptography & Data Protection

    Verschlüsselung, Schlüsselverwaltung und Schutz sensibler Daten, auch in Archiven, Backups und Exporten.

  6. 06

    Software Supply Chain

    Abhängigkeiten, SBOM und Herkunft von Drittkomponenten.

  7. 07

    CI/CD & Build Security

    Integrität von Pipeline, Build und Artefakten.

  8. 08

    Vulnerability Management

    Erkennung, Bewertung und Behebung von Schwachstellen.

  9. 09

    Logging, Monitoring & Incident Handling

    Sicherheitsrelevantes Logging, Monitoring und Vorbereitung auf Vorfälle.

  10. 10

    Security Testing

    Automatisierte und manuelle Sicherheitstests im Entwicklungsprozess.

Der vollständige Kontrollkatalog umfasst 71 Controls, jeweils mit Verweis auf die passende Praxis aus dem NIST Secure Software Development Framework (SSDF). Wir stellen ihn dir im Erstgespräch vor.

Ablauf des Assessments

Aufbauend auf dem Security Code Review, ergänzt um Evidence und Dokumentation.

  1. 01

    Scope & Kontext

    Wir legen Anwendung, Version, Komponenten und die für dich relevanten Anforderungen fest.

  2. 02

    Security Code Review

    Technischer Review des Source Codes als Grundlage des Assessments.

  3. 03

    Evidence Review

    Wir prüfen Nachweise zu Prozessen, Pipeline, Abhängigkeiten und Schwachstellenmanagement.

  4. 04

    Assessment Report

    Status je Control (PASS, FAIL, N/A oder NOT TESTED), Findings, Remediation, NIS2 Mapping und Gesamtergebnis.

  5. 05

    Retest

    Nach der Behebung verifizieren wir offene Controls und aktualisieren das Ergebnis.

Was du erhältst

Ein dokumentiertes Ergebnis, das du intern und gegenüber deinen Kunden verwenden kannst.

Control Assessment

Status für jedes Control (PASS, FAIL, N/A oder NOT TESTED) mit Begründung und referenzierter Evidence. N/A wird immer technisch begründet.

Findings & Remediation

Technische Findings aus dem Security Code Review mit Severity und konkreten Empfehlungen.

NIS2 Mapping

Dokumentation, welche Controls auf welche Anforderungen aus NIS2 Art. 21 einzahlen.

Assessment Statement

Ergebnisübersicht nach der Vorlage des Standards mit Assessment-ID, geprüfter Version, Gesamtergebnis sowie Ausstellungs- und Ablaufdatum.

Was das Ergebnis bedeutet und was nicht

Klare Aussagen statt Compliance-Versprechen.

Was bedeutet PASS?

PASS setzt voraus: keine offenen Critical- oder High-Findings, alle anwendbaren Mandatory Controls bestanden und keine wesentliche Einschränkung, die eine verlässliche Aussage verhindert. PASS WITH OBSERVATIONS ist möglich, wenn alle Mandatory Controls bestanden sind und nur noch Medium-, Low- oder Observation-Findings mit dokumentierter Behandlung offen sind. In allen anderen Fällen lautet das Ergebnis FAIL. Es gilt nur für die dokumentierte Assessment-Grenze aus Produkt, Version und Commit.

Welche Aussagen du treffen kannst

  • Dass deine Software einem Software Security Assessment durch vensas unterzogen wurde, mit Ergebnis und Datum.
  • Immer mit Angabe von geprüftem Produkt und Version oder mit Link auf den öffentlichen Verifikationseintrag.
  • Keine Formulierungen, die eine staatliche Genehmigung, gesetzliche Zertifizierung, Akkreditierung oder pauschale NIS2-Konformität nahelegen.

Was das Assessment nicht ist

  • Keine Zertifizierung und keine Prüfung durch eine Behörde
  • Keine Bestätigung der NIS2-Konformität deines gesamten Unternehmens
  • Kein Ersatz für organisatorische Maßnahmen wie Risikomanagement oder Meldeprozesse
  • Keine dauerhafte Aussage: Das Ergebnis bezieht sich auf Version und Zeitpunkt

Häufige Fragen

Nein. Das Ergebnis ist ein dokumentiertes Assessment auf Basis etablierter Standards wie NIS2 Art. 21, der Durchführungsverordnung (EU) 2024/2690, den ENISA-Leitlinien, NIST SSDF und OWASP ASVS, keine Zertifizierung durch eine Behörde oder eine akkreditierte Stelle.
NIS2 richtet sich an Unternehmen, nicht an einzelne Softwareprodukte. Das Assessment zeigt, wie deine Software relevante Sicherheitsanforderungen aus NIS2 Art. 21 adressiert, und ist damit ein Baustein deiner Nachweise. Die NIS2-Konformität deines Unternehmens kann es weder herstellen noch bestätigen.
Nein, das Security Code Review ist Teil des Assessments. Hast du bereits ein Review bei uns durchführen lassen, bauen wir darauf auf.
Neben Lesezugriff auf das Repository typischerweise Pipeline-Definitionen, Informationen zu Abhängigkeiten (zum Beispiel eine SBOM), Beschreibungen deiner Entwicklungs- und Schwachstellenprozesse sowie relevante Konfigurationen. Was genau benötigt wird, klären wir im Scoping.
Jedes Ergebnis hat ein Ausstellungs- und ein Ablaufdatum und gilt nur für die geprüfte Version. Wesentliche sicherheitsrelevante Änderungen, etwa an Architektur oder Authentifizierung, oder eine neu entdeckte Critical- oder High-Schwachstelle können es schon vorher ungültig machen. Wird ein Prüfzeichen vergeben, ist ein öffentlicher Verifikationseintrag vorgesehen, der den aktuellen Status zeigt (gültig, ausgesetzt, zurückgezogen oder abgelaufen).

Brauchst du einen strukturierten Security-Nachweis?

Lass uns klären, ob das NIS2 Assessment für dich sinnvoll ist oder ob ein Security Code Review bereits reicht.

NIS2 Assessment anfragen

Du brauchst keinen formalen Nachweis? Zum Code Review & Security Code Review