Security by Design
Sichere Softwareentwicklung
Wir entwickeln und warten Anwendungen in einem nach dem Nationalen Sicherheitsschema (ENS) Kategorie MITTEL zertifizierten System. Jede Änderung durchläuft automatische Sicherheitsanalysen, bevor sie in Produktion geht: Das ist die Qualitätsgarantie unserer Individualsoftware und unserer Produkte.
Ansatz
Sicherheit als Teil des Entwicklungszyklus
Unsere ENS-Zertifizierung umfasst genau die Informationssysteme, die die Entwicklung und Wartung von Softwareanwendungen unterstützen. Sicherheit wird nicht erst am Ende geprüft: Sie wird bei jeder Änderung automatisch kontrolliert und hinterlässt auditierbare Nachweise.
- Sicherheitsanforderungen ab dem Design: Zugriffskontrolle, Aktivitätsprotokollierung und Schutz der Informationen.
- Automatische Analysen, die die Integration blockieren, wenn sie schwerwiegende Probleme finden.
- Ergebnisse werden bei jedem Review veröffentlicht, Berichte als Nachweis aufbewahrt.
- Was nicht analysiert werden konnte, wird ausdrücklich ausgewiesen – und nicht als in Ordnung gewertet.
- Mit KI-Unterstützung geschriebener Code wird von einem Entwickler geprüft und durchläuft dieselben Analysen (sicherer KI-Einsatz).
Sicherheits-Pipeline
Was wir bei jeder Änderung prüfen
Die Analysen laufen in unseren CI-Pipelines. Erreicht eine Analyse ihren Schwellenwert nicht, wird die Änderung erst integriert, wenn sie korrigiert oder begründet ist.
-
Prüfung
Geprüfte Änderung
Jede Änderung kommt über einen Pull Request, in dem die Analysen laufen und ihre Ergebnisse veröffentlicht werden.
Ohne Review und Analysen wird nichts integriert.
-
SAST
Statische Analyse mit Semgrep
Regeln für Code, Compliance, Infrastruktur und Secrets sowie eigene Regeln mit Bezug auf Maßnahmen des ENS und der ISO/IEC 27001.
Blockiert Befunde mit hohem Schweregrad.
-
SCA
Abhängigkeiten und Images mit Trivy
Sucht nach bekannten CVEs in den Paketen und Container-Images, die in Produktion gehen.
Blockiert hohe oder kritische CVEs, für die ein Fix verfügbar ist.
-
DAST
Dynamische Tests mit OWASP ZAP
Testet die laufende Anwendung ohne Zugangsdaten (Blackbox) und authentifiziert (Graybox).
Blockiert Befunde mit hohem Risiko.
Aktive dynamische Scans laufen nur gegen kurzlebige oder Vorproduktionsumgebungen, deren Daten verloren gehen dürfen – nie gegen echte Kundendaten. Ausnahmen für eine CVE ohne kompatiblen Fix werden nur mit dokumentierter Begründung akzeptiert.
Sichere Konfiguration
Header, Richtlinien und Infrastruktur
Webanwendungen werden mit restriktiven Sicherheits-Headern veröffentlicht. Auch diese Website wird damit ausgeliefert – und ohne Ressourcen von Drittanbietern.
- Strikte Content Security Policy (CSP), ohne Inline-Skripte oder -Styles
- HTTPS verpflichtend mit HSTS
- Schutz vor Einbettung in Frames fremder Websites
- Eingeschränkte Browserberechtigungen (Kamera, Mikrofon, Standort, Zahlungen)
- Referrer-Policy und Cross-Origin-Isolation
- Kontrolle des Inhaltstyps (nosniff)
Geprüfte Infrastructure as Code
Auch die Deployment-Dateien durchlaufen die statische Analyse, mit eigenen Regeln, die sich an den ENS-Maßnahmen zur Sicherheitskonfiguration orientieren: Images mit fester Version, Secrets außerhalb des Codes, keine exponierten Datenbanken, Container ohne Privilegien und verschlüsselte interne Netze.
In Produkten wie CIGES ist die Anmeldung über einen Unternehmensverzeichnisdienst (LDAP) oder Single Sign-on und Zwei-Faktor-Authentifizierung möglich; in ACAE werden zudem die Aktionen jedes Nutzers protokolliert.
Schwachstellenmanagement
Schwachstellen mit CVE-Kennung
Wir sind CVE Numbering Authority (CNA) unter Aufsicht von INCIBE. Wird in einem unserer Produkte eine Schwachstelle entdeckt, beheben wir sie, benachrichtigen die betroffenen Kunden vor der öffentlichen Bekanntgabe und veröffentlichen sie mit ihrer CVE-Kennung und der Version, die sie behebt.
Häufige Fragen
Fragen zur sicheren Entwicklung
Was ist der Unterschied zwischen SAST, SCA und DAST?
SAST analysiert den Quellcode, ohne ihn auszuführen; SCA prüft Bibliotheken und Images von Drittanbietern auf bekannte Schwachstellen (CVE); DAST greift die laufende Anwendung so an, wie es ein externer Nutzer tun würde. Sie ergänzen sich: Jedes Verfahren erkennt Probleme, die die anderen nicht sehen.
Welche ENS-Maßnahmen deckt die sichere Entwicklung ab?
Vor allem die zum Schutz von Softwareanwendungen: Anwendungsentwicklung (mp.sw.1) sowie Abnahme und Inbetriebnahme (mp.sw.2), dazu die Sicherheitskonfiguration und das Schwachstellenmanagement aus dem operativen Rahmen. In ISO/IEC 27001:2022 entsprechen ihnen die Controls zu sicherem Entwicklungslebenszyklus, sicherer Programmierung und Sicherheitstests.
Was passiert, wenn in einem Ihrer Produkte eine Schwachstelle entdeckt wird?
Sie wird bewertet und behoben, und die betroffenen Kunden werden vor der öffentlichen Bekanntgabe benachrichtigt, gemäß unserer Richtlinie zur Offenlegung von Schwachstellen. Als CVE Numbering Authority weisen wir ihr eine CVE-Kennung zu und veröffentlichen sie in der Liste der Schwachstellen.
Können Sie diesen Prozess auf eine Individualentwicklung für meine Organisation anwenden?
Ja. Projekte für Individualsoftware werden mit demselben Prozess entwickelt, im Rahmen unserer ENS-Zertifizierung der Kategorie MITTEL.
Brauchen Sie sichere Software für Ihre Organisation?
Wir entwickeln Individualanwendungen in einem nach ENS Kategorie MITTEL zertifizierten System.
