OPSWAT Secure SDLC-Rahmenwerk:Ein Bekenntnis zu Widerstandsfähigkeit und Defense-in-Depth-Sicherheit

Böswillige Akteure haben es auf Systeme abgesehen, um Profit zu machen oder sie zu stören, was zu Kosten, Geschäftsrisiken und Rufschädigung für Unternehmen führt. 

Einer kürzlich durchgeführten Umfrage zufolge sind die Kosten für die Behebung eines Sicherheitsfehlers 30 Mal höher, wenn er in der Produktion entdeckt wird, als in der Analyse- und Anforderungsphase.

Das Secure SDLC Framework von OPSWATdefiniert strukturierte Methoden und Sicherheitsprinzipien, die die sichere Softwareentwicklung leiten. 

OPSWAT folgt dem Agile Software Development Lifecycle. Um den Anforderungen unserer Kunden in vollem Umfang gerecht zu werden, haben wir das Secure SDLC Framework an die gesetzlichen Anforderungen und internationalen Standards angepasst. Dieser Ansatz unterstreicht unser Engagement für kontinuierliche Verbesserung und Widerstandsfähigkeit in einer sich weiterentwickelnden Cybersicherheitslandschaft.

Das Secure SDLC Framework von OPSWATbaut auf dem NIST SP 800-218 SSDFSecure Software Development Framework) auf und gewährleistet, dass die Sicherheit strukturiert, messbar und in allen Phasen des Softwareentwicklungsprozesses einheitlich angewendet wird.  

Durch die Integration bewährter SSDF-Praktiken sorgt OPSWAT für eine proaktive Sicherheitshaltung und integriert Sicherheit in jede Phase der Softwareentwicklung - von der Planung und dem Entwurf bis zur Implementierung, Verifizierung und kontinuierlichen Überwachung. 

Die Bescheinigung der Konformität einzelner Produkte wird unseren Kunden der US-Bundesregierung auf Anfrage zur Verfügung gestellt. Siehe die nachstehenden Kontaktinformationen.

Da sich die Vorschriften zur Cybersicherheit ständig weiterentwickeln, ist OPSWAT weiterhin bestrebt, sein Secure SDLC Framework an die globalen gesetzlichen Anforderungen anzupassen, angefangen beim EU Cyber Resilience Act und der NIS2-Richtlinie. Durch die proaktive Anpassung an aufkommende Standards stellt OPSWAT sicher, dass sein Secure SDLC in einem zunehmend komplexen regulatorischen Umfeld umfassend, konform und widerstandsfähig bleibt.

Die Aufrechterhaltung einer robusten Informationssicherheit ist sowohl für die betriebliche Integrität als auch für die Einhaltung gesetzlicher Vorschriften entscheidend. Das Secure SDLC Framework von OPSWAT umfasst die Grundsätze des ISMS (Information Security Management System) nach ISO 27001 und stellt sicher, dass Sicherheitskontrollen, Risikomanagementstrategien und Compliance-Maßnahmen nahtlos in den Betrieb unserer Cloud-Produkte integriert werden. 

Sowohl als Anbieter als auch als Nutzer unserer Sicherheitslösungen wendet OPSWAT intern durchgesetzte Sicherheitsrichtlinien des Unternehmens an und stellt sicher, dass unsere zertifizierten Produkte vor dem Einsatz die Sicherheitserwartungen von Unternehmen erfüllen.  

Weitere Einzelheiten finden Sie unter Konformität und Zertifizierungen.

Um die höchsten Standards der Softwarequalität zu gewährleisten, ist das Secure SDLC Framework von OPSWATin das ISO 9001 QMS (Qualitätsmanagementsystem) integriert. Das QMS legt geprüfte Qualitätskontrollen für Governance, Änderungsmanagement und funktionsübergreifende Prozesse fest, die die Definition, das Design, die Entwicklung, die Produktion und die Wartung des Produkts und der Supportangebote unterstützen und sich über die F&E hinaus auf Bereiche wie Vertrieb, Kundensupport, Informationstechnologie und Personalwesen erstrecken.  

Dieser Ansatz unterstreicht unser Engagement für einen strukturierten, risikobasierten Ansatz für das Qualitätsmanagement und stellt sicher, dass die Anwendungssicherheit ein integraler Bestandteil aller Geschäftsfunktionen ist.

Weitere Einzelheiten finden Sie unter Konformität und Zertifizierungen.

Das OWASP Software Assurance Maturity Model (SAMM) ist ein umfassendes Rahmenwerk, das Unternehmen dabei helfen soll, effektive Softwaresicherheitsstrategien innerhalb ihres bestehenden SDLC zu bewerten, zu formulieren und umzusetzen.

Als Open-Source-Framework profitiert SAMM von globalen Beiträgen und gewährleistet so einen gemeinschaftlichen, sich ständig weiterentwickelnden Ansatz für die Anwendungssicherheit. Die strukturierte Methodik bietet Unternehmen eine effektive und messbare Möglichkeit zur Analyse und Verbesserung ihres Entwicklungslebenszyklus. SAMM unterstützt den gesamten Entwicklungslebenszyklus. SAMM ist technologie- und prozessunabhängig. SAMM ist entwicklungs- und risikoorientiert. Durch den Einsatz von SAMM erhalten Teams verwertbare Erkenntnisse über Sicherheitslücken und können ihre Sicherheitslage während des gesamten Entwicklungslebenszyklus systematisch verbessern.

Der OWASP Application Security Verification Standard (ASVS) ist ein weltweit anerkanntes Rahmenwerk, mit dem ein strukturierter, messbarer und umsetzbarer Ansatz für die Sicherheit von Webanwendungen geschaffen werden soll. Er bietet Entwicklern und Sicherheitsteams eine umfassende Reihe von Sicherheitsanforderungen und Verifizierungsrichtlinien, um sicherzustellen, dass Anwendungen die Best Practices der Branche erfüllen. 

Als Open-Source-Framework profitiert ASVS von den Beiträgen der weltweiten Sicherheitsgemeinschaft, so dass es immer auf dem neuesten Stand ist, was neue Bedrohungen und sich entwickelnde Sicherheitsstandards angeht.

Das Secure SDLC-Programm der OPSWAT setzt das Secure SDLC-Framework in eine strukturierte Governance um und stellt sicher, dass die Sicherheitsanforderungen dokumentiert, gewartet, gemessen und kontinuierlich verbessert werden, während gleichzeitig sichergestellt wird, dass alle beteiligten Parteien eine angemessene Schulung erhalten. Es legt Rollen, Verantwortlichkeiten und Sicherheitsmaßnahmen für Entwicklungs-, Test- und Produktionsumgebungen sowie die Pipeline-Sicherheit fest, definiert die Secure Entwicklungsumgebung und schreibt die Anwendung von Sicherheitsrichtlinien innerhalb des Secure SDLC-Prozesses vor.

Hochrangige Führungskräfte - Chief Product Officer (CPO)

Der Chief Product Officer (CPO) ist für die strategische Überwachung und Durchsetzung des Secure SDLC-Programms in allen Produktteams sowie für andere Forschungs- und Entwicklungsprogramme wie das Quality Assurance (QA)-Programm und das User Experience (UX)-Programm verantwortlich und gewährleistet so einen kohärenten Ansatz für eine sichere, hochwertige und benutzerorientierte Softwareentwicklung.

Als primärer Risikoverantwortlicher für alle Produkte und F&E-Prozesse beauftragt der CPO die F&E-Abteilung mit der Durchführung des Secure SDLC-Programms und stellt sicher, dass die Produktleiter die Anwendung des Secure SDLC-Programms durchsetzen und den Secure SDLC-Prozess in den Produktteams effektiv umsetzen. In dieser Rolle genehmigt der CPO die Änderung des Secure SDLC-Programms und die Abweichungen vom Secure SDLC-Prozess.

Der CPO überwacht auch die Ergebnisse des Secure SDLC-Programms, indem er die Sicherheitsreife, Schwachstellen, die Einhaltung der Vorschriften und die Entwicklungsaktivitäten verfolgt, um die Sicherheit der Produkte zu gewährleisten.

Darüber hinaus ist der CPO für die Zuteilung und Genehmigung des F&E-Sicherheitsbudgets verantwortlich und stellt sicher, dass angemessene Ressourcen für das Secure SDLC-Programm bereitgestellt werden.

Strategische Prioritäten

Der strategische Plan der OPSWATfür die Anwendungssicherheit ist auf die geschäftlichen Prioritäten und die Risikobereitschaft abgestimmt und berücksichtigt den Reifegrad jedes Produkts und seine Gefährdung durch Sicherheitsbedrohungen. Das Hauptaugenmerk liegt auf dem Schutz von Produkten mit hohem Risiko, insbesondere solchen mit einem großen Kundenstamm, öffentlichem Einsatz oder Integration in kritische Infrastrukturen.

Im Rahmen des Secure SDLC-Programms werden zusätzlich zu den allgemeinen Sicherheitsschulungen des Unternehmens rollenspezifische Sicherheitsschulungen für alle an der sicheren Entwicklung beteiligten Mitarbeiter vorgeschrieben. Alle Schulungen werden in den Schulungstools des Unternehmens nachverfolgt. Die Schulungs- und Sensibilisierungsprogramme werden regelmäßig überprüft, um neue Sicherheitstrends zu berücksichtigen und die kontinuierliche Einhaltung der Sicherheitsstandards zu gewährleisten.

OPSWAT ist bestrebt, sein Secure SDLC-Programm durch strukturierte Leistungsmessungen, Reifegradbewertungen und regelmäßige Aktualisierungen kontinuierlich zu verbessern, um eine kontinuierliche Sicherheitseffektivität zu gewährleisten.  

Zur Aufrechterhaltung einer starken Sicherheitslage wendet OPSWAT einen systematischen Ansatz zur Verfolgung und Verbesserung der Sicherheitsleistung an. Dazu gehören vierteljährliche Bewertungen des Reifegrads der Produktsicherheit, interne Sicherheitsüberprüfungen zur Überprüfung der Einhaltung bewährter Verfahren und die Festlegung jährlicher Leistungskennzahlen (Key Performance Indicators, KPIs), die vierteljährlich gemessen werden.  

Um die Sicherheit der Anwendungen effektiv zu messen, bewertet OPSWAT die Teams anhand strukturierter Metriken. Der Reifegrad der Produktsicherheit wird für jedes Team auf der Grundlage des SAMM-Rahmens bewertet, was ein quantifizierbares Maß für den Sicherheitsfortschritt darstellt. Darüber hinaus werden die Produkte einer ASVS-Konformitätsbewertung unterzogen, um die Einhaltung der Sicherheitsanforderungen zu gewährleisten. Die Einhaltung des Secure SDLC-Prozesses wird genau überwacht und bewertet, und das Erreichen von KPI-Zielen ist evidenzbasiert, um sicherzustellen, dass die Sicherheitslage und Sicherheitsverbesserungen sowohl messbar als auch umsetzbar sind. Alle Produktteams müssen im Rahmen ihrer jährlichen Leistungsbeurteilung die Sicherheitsreifeziele erfüllen. 

Im Rahmen seiner kontinuierlichen Verbesserungsbemühungen führt OPSWAT in regelmäßigen Abständen neue Initiativen zur Produktsicherheit ein, um den Reifegrad zu erhöhen und die Anwendungssicherheit zu verbessern. Diese Initiativen umfassen die Aktualisierung von Sicherheitsrichtlinien, um neuen Bedrohungen zu begegnen, die Integration neuer Sicherheitstools für eine verbesserte Erkennung und Vorbeugung und die Erweiterung von KPI-Zielen, um den laufenden Fortschritt voranzutreiben. 

Zur weiteren Stärkung des Sicherheitsmanagements führt das OPSWAT eine jährliche Überprüfung des Secure SDLC-Rahmens durch, in die Erkenntnisse aus Ursachenanalysen vergangener Sicherheitsvorfälle, Bewertungen von Schwachstellentrends und Verfeinerungen bestehender Prozesse und Richtlinien einfließen.  

Dieser strukturierte Ansatz zur kontinuierlichen Verbesserung stellt sicher, dass OPSWAT eine proaktive und widerstandsfähige Produktsicherheitsstruktur aufrechterhält, die sich effektiv an die sich entwickelnden Cybersicherheitsherausforderungen anpasst und gleichzeitig die gesetzlichen und betrieblichen Sicherheitsziele erfüllt.

Der Secure SDLC Process operationalisiert das Secure SDLC Program weiter, indem er die Sicherheitskontrollen definiert, die die Teams befolgen müssen, einschließlich spezifischer Aktivitäten wie automatisierte Sicherheitsprüfungen und Verifizierungsmechanismen in jeder Entwicklungsphase. Dieser Prozess ist mit anderen wichtigen F&E-Programmen wie dem Qualitätssicherungsprogramm und dem Programm für Benutzerfreundlichkeit abgestimmt, um einen kohärenten Ansatz für eine sichere, hochwertige und kundenorientierte Softwareentwicklung zu gewährleisten. 

Der Secure SDLC-Prozess wird in den folgenden Abschnitten detailliert beschrieben:

• Secure Design und Risikobewertung
• Secure Implementierung, Erstellung und Bereitstellung
• Testen und Überprüfen der Anwendungssicherheit
• Secure Freigeben
• Secure Betrieb und Wartung

Der Secure SDLC Process ist ein High-Level-Prozess, Teams können ihn in einer erweiterten, angepassten Art und Weise implementieren, unter der Bedingung, dass die Sicherheit des Prozesses auf dem gleichen Niveau wie das Minimum gehalten werden muss. Abweichungen vom Secure SDLC-Prozess müssen dokumentiert und genehmigt werden.

Das Secure SDLC-Programm umfasst verschiedene Richtlinien, die von den Produktteams formell genehmigt und anerkannt werden müssen, um die Einhaltung der Anforderungen zu gewährleisten. Die Einhaltung dieser Richtlinien ist intern verpflichtend, und jedes Team ist dafür verantwortlich, sie im Rahmen seiner Entwicklungsprozesse zu prüfen, zu unterzeichnen und umzusetzen. 

Nachstehend finden Sie eine Liste der wichtigsten Politikbereiche mit ihren jeweiligen Zielen. Für Politiken mit externer Bedeutung werden zusätzliche Details in dieses Dokument aufgenommen.

Als Teil des Secure SDLC-Prozesses werden die Sicherheitsanforderungen während des gesamten Entwicklungszyklus verfolgt, dokumentiert und gepflegt. Drittanbieter müssen die ASVS anerkennen und einhalten, um die Konsistenz der Sicherheitserwartungen und die Einhaltung der Product Privacy Compliance Policy für alle Softwarekomponenten zu gewährleisten. 

Die Sicherheit ist in jeder Phase des Entwicklungslebenszyklus integriert. Es liegt in der Verantwortung der Sicherheitsverantwortlichen, die Erwartungen des Secure SDLC-Prozesses im Auge zu behalten und sie in ihren Teams zu vertreten. 

Der Anforderungssatz für Secure Design umfasst funktionale und nicht-funktionale Sicherheitsanforderungen auf der Grundlage von ASVS. Die F&E-Abteilung stellt Referenzmodelle zur Verfügung, um Entwurfsentscheidungen zu unterstützen, und nimmt bei Bedarf dokumentierte Anpassungen der ASVS-Anforderungen vor (z. B. strengere Verschlüsselungsanforderungen).

Die Bedrohungsmodellierung ist ein strukturierter Prozess zur Identifizierung von Bedrohungen und Schwachstellen in den frühesten Stadien des Entwicklungszyklus. Er ist ein integraler Bestandteil des Secure SDLC-Prozesses und wird regelmäßig durchgeführt - mindestens einmal im Jahr oder immer dann, wenn neue Funktionen oder Architekturänderungen eingeführt werden. Produktteams führen die Bedrohungsmodellierung durch, indem sie Sicherheitsziele definieren, Anlagen und Abhängigkeiten identifizieren, potenzielle Angriffsszenarien analysieren und identifizierte Bedrohungen entschärfen.  

Ein erweiterter Ansatz umfasst die Analyse des Datenflusses und bewährte Verfahren zur Modellierung von Bedrohungen (z. B. das STRIDE-Modell), um eine umfassende Bewertung aller Produkte zu gewährleisten. Bei Bedarf werden Sicherheitsüberprüfungen eingeleitet, um die Einhaltung der Sicherheitsanforderungen zu überprüfen und potenzielle Risiken proaktiv anzugehen. Entwurfsentscheidungen werden sorgfältig dokumentiert, und verbleibende Risiken werden während des gesamten Produktlebenszyklus kontinuierlich nachverfolgt.

Die Risiken für die Anwendungssicherheit werden anhand mehrerer Quellen bewertet, darunter Restbedrohungen, die bei der Bedrohungsmodellierung identifiziert wurden, weithin anerkannte Sicherheitslücken wie die der OWASP Top 10 und SANS Top 25 sowie fehlende Sicherheitskontrollen gemäß den ASVS-Richtlinien. Zu den weiteren Risikofaktoren gehören Schwachstellen in der Geheimhaltung während des gesamten Erstellungs-, Bereitstellungs- und Freigabeprozesses sowie Schwachstellen in Open-Source- und Drittanbieter-Komponenten. 

Im Anschluss an die Risikobewertung werden Pläne zur Risikominderung entwickelt, um die Schwere der ermittelten Risiken zu verringern, wobei sowohl die Auswirkungen als auch die Eintrittswahrscheinlichkeit berücksichtigt werden. Diese Pläne werden zusammen mit den entsprechenden Risiken und Abhilfemaßnahmen sorgfältig dokumentiert. 

Restrisiken werden während des gesamten Produktlebenszyklus verfolgt, regelmäßig überprüft und müssen von den Risikoverantwortlichen formell bestätigt werden. Sie werden auch in die internen Release-Berichte aufgenommen, um Transparenz und Verantwortlichkeit zu gewährleisten. 

Bei Bedarf werden Sicherheitsüberprüfungen eingeleitet, um die Einhaltung der Sicherheitsanforderungen zu gewährleisten und potenzielle Risiken proaktiv anzugehen, wodurch die allgemeine Sicherheitslage des Produkts gestärkt wird.

Als Teil des Secure SDLC-Prozesses, der die Implementierung, den Aufbau und die Bereitstellung umfasst, sollen Schwachstellen und Fehler auf der Grundlage des Secure Designs und der Risikobewertung verhindert werden. Der Anforderungskatalog enthält Erwartungen an ASVS-basierte funktionale und nicht-funktionale Sicherheitsanforderungen, sichere Entwicklungs- und Testmethodik, die sich auf die Secure Entwicklungsumgebung stützt.  

Während der Implementierung sind die Best Practices für Secure Kodierung, die Überprüfung von Secure Code und die frühzeitige Erkennung von Sicherheitslücken anzuwenden. Die Teams müssen die Sicherheitsrichtlinien für Supply Chain (einschließlich der Einbindung von Anbietern und Open-Source-Software), die Richtlinie für die KI-Nutzung und die Richtlinie für den Umgang mit Malware-Proben einhalten. Während des Builds und der Bereitstellung sind Secure Build und Deployment mit zentralisierter CI/CD-Pipeline und Aufgabentrennung erforderlich.

Die Produktteams müssen bei der Implementierung sprachunabhängige Best Practices für sichere Kodierung befolgen. Sie müssen Eingabedaten validieren, an andere Systeme gesendete Daten bereinigen, Compiler-Warnungen beseitigen, sichere Fehlermeldungen festlegen, gegebenenfalls eine Ausgabekodierung anwenden, eine sichere Protokollierung implementieren, ohne sensible Daten preiszugeben, und Richtlinien für eine ordnungsgemäße Fehlerbehandlung und Ausnahmeverwaltung befolgen. Die Teams müssen auch sicherstellen, dass die Kryptographie, sofern sie verwendet wird, auf genehmigten Algorithmen und einer sicheren Zufallszahlengenerierung beruht, und sie müssen die Systemressourcen sicher verwalten, indem sie den Speicher sicher handhaben, Wettlaufbedingungen verhindern und Deadlocks durch eine angemessene Synchronisierung vermeiden. 

Den Produktteams wird außerdem empfohlen, sprachspezifische Richtlinien für sichere Kodierung zu befolgen, die von den SAST-Tools durchgesetzt werden, wie im Folgenden dargestellt: 

Bei Java sollten die Teams sicherstellen, dass die in Vergleichsoperationen verwendeten Schlüssel unveränderlich sind, SecureRandom anstelle von Random verwenden und unsichere Deserialisierung durch Validierung oder Einschränkung von Eingabeklassen vermeiden.

In C++ wird empfohlen, Fehler bei der Speicherzuweisung zu erkennen und zu behandeln, Pufferüberläufe durch Bound-Checking und die Verwendung von intelligenten Zeigern wie std::unique_ptr() zu verhindern und unsichere Funktionen wie strcpy() und sprintf() zu vermeiden. 

Bei Python sollten Entwickler die Verwendung von Funktionen wie eval() oder exec() vermeiden, um das Risiko der Code-Injektion zu verringern, und bei der Verarbeitung nicht vertrauenswürdiger Daten sichere Serialisierungsformate wie das json-Modul gegenüber pickle vorziehen.

Als Teil der von der Richtlinie zur Überprüfung der Anwendungssicherheit geforderten Sicherheitsüberprüfungen ist die Überprüfung des sicheren Codes wichtig und wird je nach Entwicklungstechnologie mit verschiedenen Checklisten für die Überprüfung des Secure Codes auf der Grundlage derOWASP-Cheatsheet-Seriedurchgeführt.

Wie in der Richtlinie zur Überprüfung der Anwendungssicherheit gefordert, ist die frühzeitige Erkennung von Sicherheitsmängeln eine entscheidende Komponente des Entwicklungsprozesses. Um potenzielle Sicherheitsprobleme zu minimieren, ist ein "Fail to build"-Ansatz vorgeschrieben, der sicherstellt, dass unsicherer Code die Pipeline nicht durchläuft. Darüber hinaus wird ein "Fail to Merge"-Ansatz durchgesetzt, der von den Teams verlangt, alle entdeckten Probleme zu beheben, bevor die Änderungen integriert werden können. Die Behebung der entdeckten Fehler ist für die Erfüllung der Freigabekriterien unerlässlich.

Als Teil des Secure SDLC-Prozesses ist die Verwendung einer zentralisierten, orchestrierten CI/CD-Pipeline obligatorisch, um sichere Builds durchzusetzen und Angriffe auf die Lieferkette zu vermeiden. Audit-, Build- und Bereitstellungsprotokolle werden gemäß den Sicherheitsrichtlinien des Unternehmens erstellt, aufbewahrt und überprüft. 

Jedes Produktteam ist dafür verantwortlich, gegebenenfalls sichere Build- und Compiler-Konfigurationen zu verwenden. Sie müssen sichere Compiler-Optionen verwenden, Debug-Code deaktivieren, Laufzeiten für interpretierte Sprachen härten, Abhängigkeitsversionen festlegen, reproduzierbare Builds sicherstellen und Container-Images härten. Die verwendeten Konfigurationen müssen dokumentiert und in regelmäßigen Abständen überprüft werden. 

Im Einklang mit dem Grundsatz der Aufgabentrennung haben Entwickler und andere Teammitglieder, die Zugriff auf Code oder Builds haben, keinen Zugang zur Produktionsumgebung. Bei Cloud-Produkten dürfen nur die Techniker für die Zuverlässigkeit des Produkts vor Ort in der Produktionsumgebung arbeiten.

Gemäß unserer Richtlinie für die Überprüfung der Anwendungssicherheit führen wir eine formale Dokumentation und Nachverfolgung für entdeckte Probleme ein und setzen automatisierte Tools für die kontinuierliche Überprüfung ein. Als Teil des Secure SDLC-Prozesses werden Sicherheitsprüfungen in jeder Phase des SDLC durchgesetzt und nachverfolgt, um die Compliance-Anforderungen zu erfüllen. Der Zweck dieser Prüfungen besteht darin, mögliche Sicherheitslücken effizient zu finden. Die entstehenden Sicherheitsprobleme werden von den Teams untersucht und innerhalb des Zeitrahmens behoben. Die Zeitrahmen sind Teil der definierten Sicherheits-KPIs.

• Überprüfung von Architektur und Design: Erfahrene Ingenieure und Mitglieder des virtuellen Teams für Anwendungssicherheit bewerten Sicherheitsaspekte bei Entwurfsänderungen, einschließlich Verschlüsselung, Authentifizierung, Autorisierung, Auditing, Systemhärtung, System- und Netzwerkarchitektur. 
• Code-Reviews: Zusätzlich zu den regelmäßigen Code-Reviews durch Peer- und Senior-Ingenieure überprüfen Mitglieder des Application Security Virtual Teams die Änderungen, um häufige Schwachstellen wie Injektionen, Fehlerbehandlung und unsichere Konfigurationen zu verhindern.

• Secret Scanning zur Vermeidung der Exfiltration von Geheimnissen und zur Gewährleistung eines guten Designs und einer sicheren Implementierung des Umgangs mit Geheimnissen.
• SAST-Tools (Static Application Security Testing) zur Aufdeckung von Schwachstellen (z. B. SQL Injection, Buffer Overflows).
• SCA (Software Composition Analysis) wird zum Aufspüren von Open-Source-Schwachstellen verwendet.
• DAST (Dynamic Application Security Testing) wird verwendet, um Laufzeit- (z. B. Speicherfehler) und Umgebungsprobleme zu finden.

Die Tools, die im Abschnitt Frühzeitige Erkennung von Sicherheitsproblemen definiert sind, müssen in der CI/CD-Pipeline verwendet werden. Alle identifizierten Schwachstellen müssen gemäß der Richtlinie Vulnerability Management behoben werden.

Sowohl automatisierte als auch manuelle Sicherheitstests werden in Übereinstimmung mit dem Qualitätssicherungsprogramm und der Ausführung des Sicherheitstestplans durchgeführt.

• DAST-Tools werden eingesetzt, um Schwachstellen während der Laufzeit zu erkennen, Standardkonfigurationen zu testen und die Widerstandsfähigkeit des Systems nach Anwendung der Härtungsvorschläge zu prüfen. Die Tests zielen sowohl auf die Software als auch auf die zugrunde liegende Infrastruktur ab. 
• Um Rückschritte bei den Sicherheitsanforderungen und -merkmalen zu vermeiden, verwenden wir automatische Testwerkzeuge, um die Integrität der Sicherheitsmerkmale und -kontrollen kontinuierlich zu überprüfen. 
• Manuelle Tests kommen dort zum Einsatz, wo automatisierte Tools versagen, z. B. bei der Überprüfung von Kontrollen auf Informationslecks, bei der Identifizierung von Fehlern in der Geschäftslogik und bei kontextbezogenen Schwachstellen. 
• Das automatisierte Malware-Scanning von Artefakten im Entwicklungszyklus ist ebenfalls Teil der Schritte, die sich auf die Prävention von Sicherheitsproblemen konzentrieren.

Als Teil des Secure SDLC-Prozesses setzt der Freigabeprozess Freigabekriterien durch, die sowohl die Einhaltung des Secure SDLC-Prozesses als auch die Gesamtsicherheit des Produkts auf der Grundlage der Ergebnisse der Anwendungssicherheitstests und -überprüfung gewährleisten. Die Produktversionierung spielt eine entscheidende Rolle bei der Aufrechterhaltung von Sicherheitsverbesserungen über alle Releases hinweg, bei der Verhinderung von sicherheitsrelevanten Rückschritten und bei der Erhaltung der erreichten Sicherheitslage, was eine grundlegende Anforderung für jedes Release darstellt. 

Der Freigabeprozess umfasst die Erstellung interner Freigabeberichte, in denen Restrisiken und offene Sicherheitsprobleme dokumentiert werden. Diese Berichte müssen vom Produktverantwortlichen formell genehmigt werden. Darüber hinaus werden sicherheitsrelevante Änderungen und Fehlerbehebungen im Rahmen der offiziellen Produktfreigabe in externen Freigabemitteilungen bekannt gegeben. 

Bei Cloud-Produkten erfolgt die Bereitstellung nach dem Automatisierungsansatz "Fail to Deploy", der gewährleistet, dass nur sichere Builds freigegeben werden. Die Prüfung und Verifizierung der Anwendungssicherheit ist in die Bereitstellungspipeline integriert, wobei eine operative Pull-Strategie anstelle einer Push-Strategie verfolgt wird, um die Sicherheitsvalidierung vor der Produktionsbereitstellung zu verstärken. 

Gemäß der SBOM-Verwaltungsrichtlinie enthält jedes Release eine Software Bill of Materials (SBOM) ), um die Rückverfolgbarkeit der Komponentenherkunft zu gewährleisten und die Transparenz und Sicherheit der Lieferkette zu unterstützen. Alle erforderlichen Versionsdateien werden sicher archiviert, um eine langfristige Zugänglichkeit zu gewährleisten.

Gemäß der Release Integrity Policy wird zur Wahrung der Integrität und Sicherheit von Produktversionen ein strukturiertes Versionierungssystem (z. B. Semantic Versioning) angewandt, das eine klare Rückverfolgbarkeit von Änderungen und eine definierte Aufbewahrungsfrist für alle freigegebenen Artefakte, einschließlich der Dokumentation, gewährleistet. Um die Sicherheit weiter zu erhöhen, werden die Software-Artefakte unter dem Namen des Unternehmens digital signiert, mit veröffentlichten SHA-Fingerprints, die es den Benutzern ermöglichen, die Authentizität zu überprüfen und etwaige Manipulationsversuche zu erkennen. 

Jede Version wird von einer aktualisierten Dokumentation begleitet, die detaillierte Anleitungen zu Methoden der Integritätsprüfung, sicheren Installationsverfahren, bewährten Konfigurationsverfahren und Maßnahmen zur Systemhärtung enthält. Diese Ressourcen helfen den Benutzern, Sicherheitskontrollen effektiv zu implementieren und potenzielle Angriffsflächen zu reduzieren. Darüber hinaus ist die Endbenutzer-Lizenzvereinbarung (EULA) enthalten, um Compliance-Verpflichtungen festzulegen und rechtliche Transparenz zu gewährleisten. 

Die SBOM für einzelne Produkte stellen wir unseren Kunden auf Anfrage zur Verfügung. Kontaktieren Sie uns.

Entwicklungs-, Test- und Produktionsumgebungen sind sicher voneinander getrennt, um unbefugten Zugriff zu verhindern. Jede Umgebung befolgt strenge Härtungs-Baselines und Endpunkt-Sicherheitsprotokolle. Die Entwicklungsumgebungen müssen mit den Sicherheitsrichtlinien des Unternehmens übereinstimmen.

Als Teil des Endpunktschutzes werden alle OPSWAT Geräte auf Schwachstellen, installierte Software, installierte Patches und die Einhaltung der Sicherheitsrichtlinien des Unternehmens überwacht. Bei Nichteinhaltung werden restriktive Maßnahmen ergriffen, um den Zugang zu Unternehmensressourcen zu beschränken. 

Auf Ressourcen, die mit hoher Risikokategorie eingestuft sind, kann nur über kontrollierte Zugangswege (VPN) zugegriffen werden. Geräte außerhalb des Unternehmensnetzes müssen sichere Kanäle für den Zugriff auf F&E-Ressourcen nutzen.

Die Sicherheit der CI/CD-Pipeline unterliegt strengen Sicherheitsrichtlinien, um sich entwickelnde Bedrohungen abzuschwächen. Die Quelle der Bedrohungen können veraltete Infrastrukturelemente (wie Betriebssysteme, Analysetools usw.), unbefugte Zugriffe aufgrund schwacher Berechtigungskontrollen und schlecht isolierte Umgebungen sein. Die CI/CD-Infrastruktur auf dem neuesten Stand zu halten, gründlich zu überprüfen und streng zu kontrollieren, ist ein Eckpfeiler unseres sicheren SDLC. 

Regional werden Server in den USA für alle zentralen Dienste verwendet, einschließlich der Codespeicherung, der CI/CD-Pipeline, der Analyse- und Testtools und der sicheren Signierung von Artefakten. Die Konfiguration aller zentralisierten Tools unterliegt der Kontrolle von R&D Operations. 

Wir wenden starke Authentifizierungsmechanismen (Multi-Faktor-Authentifizierung - MFA) und Autorisierungskontrollen (rollenbasierte Zugriffskontrolle - RBAC) an. Least Privilege und regelmäßige Zugriffsüberprüfungen werden durchgeführt. 

Unsere Pipelines umfassen mehrere Analyse- und Testautomatisierungs-Tools, darunter Static Application Security Testing (SAST), Software Composition Analysis (SCA), Dynamic Application Security Testing (DAST), Secret Scanning und Malware Scanning. 

In unserer sicheren Code-Signierungslösung verwenden wir Hardware (HSMs), um das Schlüsselmaterial vor unbefugtem Zugriff zu schützen und die Signatur zu erzeugen. Die Signierlösung ist Teil der CI/CD-Infrastruktur, aber das Netzwerk ist segmentiert. Nur F&E Operations ist berechtigt, für kurze Zeit auf die HSMs zuzugreifen. Jede Signieraktion wird protokolliert und kann im Rahmen eines Audit-Trails überprüft werden. 

Das Toolset, das zum Erstellen, Kompilieren oder Testen der Software verwendet wird, muss über Herkunftsinformationen verfügen und aus einer validierten Quelle stammen. Die Anzahl der in der CI/CD-Pipeline verwendeten Tools ist begrenzt; es werden nur die erforderlichen Tools installiert. Für die Kompilierungs- und Build-Schritte in der Pipeline ist nur LTS-Software zugelassen. Für den Betrieb der zentralisierten Dienste sind regelmäßige Wartungs- und Schlüsselrotationsperioden festgelegt. Intern entwickelte Tools fallen unter den Secure SDLC-Prozess.

Die Härtung der Umgebung für alle zentralen Dienste erfolgt kontinuierlich, und diese Sicherheitsanforderungen werden regelmäßig überprüft. Die Härtungsrichtlinien werden den Produktteams mitgeteilt, um sicherzustellen, dass sie vorbereitet sind und ihre Entwicklungsprozesse entsprechend anpassen können. Im Falle eines Sicherheitsvorfalls wird ein RCA durchgeführt, um Präventivmaßnahmen zu ergreifen und diese Anforderungen zu aktualisieren.

Der Schutz des Quellcodes ist ein wesentlicher Bestandteil der Softwareentwicklung, um die Vertraulichkeit und Integrität des Quellcodes innerhalb des Unternehmens zu gewährleisten. 

Der Quellcode wird nach dem Prinzip der geringsten Rechte gespeichert, so dass nur befugte Personen und Werkzeuge darauf zugreifen können. Der Quellcode unterliegt der Versionskontrolle. Das Versionskontrollmanagementsystem garantiert die Rückverfolgbarkeit und Nachvollziehbarkeit von Codeänderungen. Der Quellcode wird mit FIPS 140-3-konformer Kryptographie verschlüsselt und mit einer angemessenen Schlüssellänge geschützt.

Die Einhaltung dieser Politik ist für alle internen Teams verbindlich. Dieses Dokument ist den Unternehmensrichtlinien untergeordnet, was bedeutet, dass im Falle von Widersprüchen die Unternehmensrichtlinien Vorrang haben und befolgt werden müssen. 

Eskalationsprozess für Verstöße gegen Secure SDLC: Verstöße gegen diese Richtlinie werden intern behandelt, beginnend mit R&D Operations und bei Bedarf bis zum Chief Product Officer (CPO) eskalierend.

Von Anbietern, die Komponenten oder Dienstleistungen für Produkte bereitstellen, die in den Geltungsbereich von ISO 27001, SOC2 und NIST SSDF fallen, wird erwartet, dass sie die unten aufgeführten Anforderungen des Secure SDLC Framework erfüllen. Die Einhaltung unterliegt regelmäßigen Sicherheitsprüfungen, Bewertungen durch Dritte und den Verpflichtungen jeder Partei aus den abgeschlossenen Verträgen. 

Alle Anbieter sind verpflichtet, Informationen zur Herkunft und Integrität zusammen mit der entsprechenden Dokumentation gemäß dem Abschnitt über die Integrität der Freigabe bereitzustellen. 

Die Anbieter von Produktkomponenten und Bibliotheken müssen Entwicklungsumgebungen einrichten, die mit unseren Praktiken übereinstimmen, wie im Abschnitt Secure Entwicklungsumgebung beschrieben. Sie müssen Sicherheitstests für ihre Komponenten und Bibliotheken durchführen, wie im Abschnitt "Testen und Verifizieren der Anwendungssicherheit" beschrieben. 

Die Anbieter von Pipeline-Komponenten müssen auch Entwicklungsumgebungen einrichten, die mit unseren Praktiken übereinstimmen, wie im Abschnitt " Secure Entwicklungsumgebung" beschrieben. Außerdem müssen ihre Entwicklungsprozesse mit dem Secure SDLC-Prozess von OPSWATübereinstimmen. 

Von den Dienstleistern wird erwartet, dass sie in den USA ansässige Umgebungen nutzen, die eine mit den OPSWATvergleichbare Sicherheitslage bieten. Ihr Secure SDLC muss sowohl ein Secure SDLC-Programm als auch einen Secure SDLC-Prozess umfassen, die den Erwartungen der OPSWATentsprechen.