Das Secure Framework OPSWAT:
Ein Bekenntnis zu Resilienz und mehrschichtiger 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 Framework“ OPSWATdefiniert strukturierte Methoden und Sicherheitsgrundsätze, die als Leitlinien für die sichere Softwareentwicklung dienen. 

OPSWAT dem agilen Software . Um den Anforderungen unserer Kunden in vollem Umfang gerecht zu werden, haben wir das Secure an die regulatorischen Vorgaben und internationalen Standards angepasst. Dieser Ansatz unterstreicht unser Engagement für kontinuierliche Verbesserung und Widerstandsfähigkeit in einer sich ständig weiterentwickelnden Cybersicherheitslandschaft.

Das Secure Framework“ OPSWATbasiert auf dem NIST SP 800-218 SSDF (Secure Software Framework) und gewährleistet, dass die Sicherheit strukturiert, messbar und in allen Phasen des Softwareentwicklungsprozesses einheitlich umgesetzt 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.

Angesichts der sich ständig weiterentwickelnden Vorschriften im Bereich der Cybersicherheit OPSWAT bestrebt, sein Secure Framework“ an globale regulatorische Anforderungen anzupassen, angefangen beim EU-Cyberresilienzgesetz und der NIS2-Richtlinie. Durch die proaktive Anpassung an neue Standards OPSWAT , dass sein Secure in einem zunehmend komplexen regulatorischen Umfeld umfassend, konform und widerstandsfähig bleibt.

Die Gewährleistung einer robusten Informationssicherheit ist sowohl für die operative Integrität als auch für die Einhaltung gesetzlicher Vorschriften von entscheidender Bedeutung. Das Secure Framework“ OPSWAT basiert auf den Grundsätzen des Informationssicherheits-Managementsystems (ISMS) nach ISO 27001 und stellt sicher, dass Sicherheitskontrollen, Risikomanagementstrategien und Compliance-Maßnahmen nahtlos in den Betrieb unserer Cloud-Produkte integriert sind. 

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 höchste Standards bei der Softwarequalität zu gewährleisten, ist Secure Framework“ OPSWATin das Qualitätsmanagementsystem (QMS) nach ISO 9001 integriert. Das QMS legt geprüfte Qualitätskontrollen für Governance, Änderungsmanagement und funktionsübergreifende Prozesse fest und unterstützt die Definition, Konzeption, Entwicklung, Produktion und Wartung des Produkts sowie der Supportangebote. Dabei erstreckt es sich über den Bereich Forschung und Entwicklung hinaus auf Bereiche wie Vertrieb, Kundensupport, Informationstechnologie und Personalwesen.  

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.

Secure OPSWAT setzt das Secure in strukturierte Steuerungsmechanismen um und stellt sicher, dass Sicherheitsanforderungen dokumentiert, gepflegt, gemessen und kontinuierlich verbessert werden, während gleichzeitig gewährleistet wird, dass alle Beteiligten eine angemessene Schulung erhalten. Es legt Rollen, Verantwortlichkeiten und Sicherheitsmaßnahmen für Entwicklungs-, Test- und Produktionsumgebungen sowie für die Pipeline-Sicherheit fest, definiert die Secure Environment“ und schreibt die Anwendung von Sicherheitsrichtlinien innerhalb des Secure vor.

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

Der Chief Product Officer (CPO) ist für die strategische Leitung und Umsetzung des Secure in allen Produktteams sowie für weitere Forschungs- und Entwicklungsprogramme (F&E) wie das Qualitätssicherungsprogramm (QA) und das User-Experience-Programm (UX) verantwortlich und sorgt so für einen einheitlichen Ansatz bei der Entwicklung sicherer, hochwertiger und nutzerorientierter Software.

Als Hauptverantwortlicher für alle Produkte und F&E-Prozesse beauftragt der CPO den Bereich F&E-Operations mit der Leitung des Secure Programms und stellt sicher, dass die Produktverantwortlichen die Anwendung des Secure durchsetzen und den Secure Prozess in den Produktteams effektiv umsetzen. In dieser Funktion genehmigt der CPO Änderungen am Secure sowie Abweichungen vom Secure “-Prozess.

Der CPO überwacht zudem die Ergebnisse Secure und verfolgt dabei den Reifegrad der Sicherheit, Schwachstellen, die Einhaltung von Vorschriften sowie Entwicklungsaktivitäten, um ein hohes Sicherheitsniveau der Produkte zu gewährleisten.

Darüber hinaus ist der CPO für die Zuweisung und Genehmigung der Mittel für die Sicherheit im Bereich Forschung und Entwicklung zuständig und stellt sicher, dass dem Secure “-Programm ausreichende Ressourcen zur Verfügung stehen.

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 sind zusätzlich zu den allgemeinen Schulungen zur Sensibilisierung für Sicherheitsfragen des Unternehmens rollenspezifische Sicherheitsschulungen für alle Mitarbeiter vorgeschrieben, die an der sicheren Softwareentwicklung beteiligt sind. Alle Schulungen werden in den Schulungstools des Unternehmens erfasst. Die Schulungs- und Sensibilisierungsprogramme werden regelmäßig überprüft, um neue Sicherheitstrends zu berücksichtigen und die kontinuierliche Einhaltung der Sicherheitsstandards sicherzustellen.

OPSWAT zum Ziel OPSWAT , sein Secure “-Programm durch strukturierte Leistungsmessungen, Reifegradbewertungen und regelmäßige Aktualisierungen kontinuierlich zu verbessern, um eine dauerhafte 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 den Sicherheitsstatus von Anwendungen effektiv zu messen, OPSWAT die Teams anhand strukturierter Kennzahlen. Die Sicherheitsreife der Produkte wird pro Team auf der Grundlage des SAMM-Rahmenwerks bewertet, wodurch sich der Fortschritt im Bereich Sicherheit quantifizieren lässt. Darüber hinaus durchlaufen die Produkte eine ASVS-Konformitätsprüfung, um die Einhaltung der Anforderungen an die Sicherheitsüberprüfung sicherzustellen. Die Einhaltung des Secure wird genau überwacht und bewertet, und die Erreichung der KPI-Ziele erfolgt auf der Grundlage von Belegen, wodurch sichergestellt wird, dass sowohl der Sicherheitsstatus als auch die Sicherheitsverbesserungen messbar und umsetzbar sind. Alle Produktteams sind verpflichtet, im Rahmen ihrer jährlichen Leistungsbeurteilung die Ziele zur Sicherheitsreife zu erreichen. 

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. 

Um die Sicherheitssteuerung weiter zu stärken, OPSWAT eine jährliche Überprüfung des Secure OPSWAT , bei der Erkenntnisse aus Ursachenanalysen vergangener Sicherheitsvorfälle, Bewertungen von Schwachstellentrends sowie Verbesserungen 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 setzt das Secure weiter in die Praxis um, indem er die Sicherheitskontrollen definiert, die die Teams befolgen müssen, darunter konkrete Maßnahmen wie automatisierte Sicherheitsprüfungen und Verifizierungsmechanismen in jeder Entwicklungsphase. Dieser Prozess ist auf andere wichtige F&E-Programme abgestimmt, wie beispielsweise das Qualitätssicherungsprogramm und das User-Experience-Programm, und gewährleistet so einen einheitlichen Ansatz für eine sichere, qualitativ hochwertige und kundenorientierte Softwareentwicklung. 

Der Prozess Secure wird in den folgenden Abschnitten näher erläutert:

• Secure und Risikobewertung
• Secure , Erstellung und Bereitstellung
• Testen und Überprüfen der Anwendungssicherheit
• Secure
• Secure und Wartung

Der Secure Prozess ist ein übergeordneter Prozess; Teams können ihn in erweiterter, individuell angepasster Form umsetzen, sofern die Sicherheit des Prozesses mindestens auf dem gleichen Niveau gewährleistet bleibt. Abweichungen vom Secure “-Prozess müssen dokumentiert und genehmigt werden.

Das Secure umfasst verschiedene Richtlinien, die von den Produktteams offiziell genehmigt und bestätigt werden müssen, um die Einhaltung der entsprechenden Anforderungen sicherzustellen. Die Einhaltung dieser Richtlinien ist intern verbindlich, 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.

Im Rahmen des Secure werden Sicherheitsanforderungen während des gesamten Entwicklungszyklus nachverfolgt, dokumentiert und gepflegt. Drittanbieter sind verpflichtet, die ASVS anzuerkennen und einzuhalten, um die Einheitlichkeit der Sicherheitsanforderungen und die Einhaltung der Datenschutzrichtlinie für Produkte bei allen Softwarekomponenten sicherzustellen. 

Sicherheit ist in jede Phase des Entwicklungslebenszyklus integriert. Es liegt in der Verantwortung der Sicherheitsbeauftragten, die Anforderungen des Secure im Blick zu behalten und diese in ihren Teams zu vertreten. 

Der Anforderungskatalog Secure umfasst funktionale und nicht-funktionale Sicherheitsanforderungen auf Basis des ASVS. Zur Unterstützung von Entwurfsentscheidungen stellt die Abteilung „R&D Operations“ Referenzmodelle zur Verfügung, gegebenenfalls ergänzt durch dokumentierte Anpassungen der ASVS-Anforderungen (z. B. strengere Verschlüsselungsanforderungen).

Die Bedrohungsmodellierung ist ein strukturierter Prozess zur Identifizierung von Bedrohungen und Schwachstellen in den frühesten Phasen des Entwicklungslebenszyklus. Sie ist ein integraler Bestandteil des Secure und wird regelmäßig durchgeführt – mindestens einmal jährlich oder immer dann, wenn neue Funktionen oder architektonische Änderungen eingeführt werden. Produktteams führen die Bedrohungsmodellierung durch, indem sie Sicherheitsziele definieren, Ressourcen und Abhängigkeiten identifizieren, potenzielle Angriffsszenarien analysieren und identifizierte Bedrohungen mindern.  

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.

Im Rahmen des Secure , der die Phasen Implementierung, Erstellung und Bereitstellung umfasst, sollen auf der Grundlage des Secure und der Risikobewertung Schwachstellen und Fehler verhindert werden. Der Anforderungskatalog enthält Vorgaben zu funktionalen und nicht-funktionalen Sicherheitsanforderungen gemäß ASVS sowie zu Methoden für sichere Entwicklung und Tests, die auf der Secure basieren.  

Bei der Implementierung sind bewährte Verfahren Secure , Secure und die frühzeitige Erkennung von Sicherheitslücken anzuwenden. Die Teams müssen sich an die Richtlinie Supply Chain (einschließlich der Themen Lieferanten-Onboarding und Open-Source-Software), die Richtlinie zur Nutzung von KI sowie die Richtlinie zum Umgang mit Malware-Beispielen halten. Bei der Erstellung und Bereitstellung sind Secure und Bereitstellung unter Verwendung einer zentralisierten CI/CD-Pipeline sowie die Trennung von Aufgaben 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.

Im Rahmen der gemäß der Richtlinie zur Überprüfung der Anwendungssicherheit vorgeschriebenen Sicherheitsüberprüfungen spielt die Überprüfung auf sicheren Code eine wichtige Rolle. Diese wird je nach Entwicklungstechnologie durchgeführt, wobei verschiedene Checklisten zur Überprüfung Secure auf der Grundlageder OWASP-Cheatsheet-Reiheangewendet werden.

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.

Im Rahmen des Secure ist der Einsatz einer zentralisierten, koordinierten CI/CD-Pipeline zwingend erforderlich, um sichere Builds zu gewährleisten und Angriffe auf die Lieferkette zu verhindern. 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 zur Überprüfung der Anwendungssicherheit führen wir eine formelle Dokumentation und Nachverfolgung der festgestellten Probleme durch und setzen automatisierte Tools zur kontinuierlichen Überprüfung ein. Im Rahmen des Secure werden in jeder Phase des SDLC Sicherheitsprüfungen durchgeführt und nachverfolgt, um die Compliance-Anforderungen zu erfüllen. Ziel dabei ist es, mögliche Sicherheitslücken effizient aufzudecken. Die auftretenden Sicherheitsprobleme werden von den Teams untersucht und innerhalb der vorgegebenen Fristen behoben. Die Fristen 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 sorgt der Release-Prozess für die Einhaltung der Release-Kriterien, wodurch sowohl die Einhaltung des Secure als auch die Gesamtsicherheit des Produkts gewährleistet werden – basierend auf den Ergebnissen der Anwendungssicherheitstests und -überprüfungen. Die Produktversionierung spielt eine entscheidende Rolle bei der Aufrechterhaltung von Sicherheitsverbesserungen über verschiedene Releases hinweg, bei der Verhinderung sicherheitsrelevanter Regressionen und bei der Wahrung des erreichten Sicherheitsniveaus als grundlegende Anforderung für jedes Release. 

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 notwendigen Tools installiert. Für die Kompilierungs- und Erstellungsschritte in der Pipeline ist ausschließlich LTS-Software zulässig. Für den Betrieb der zentralisierten Dienste sind regelmäßige Wartungs- und Schlüsselrotationszeiträume festgelegt. Intern entwickelte Tools unterliegen dem Secure .

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. 

Eskalationsverfahren bei Verstößen Secure : Verstöße gegen diese Richtlinie werden intern behandelt, beginnend bei der Abteilung „R&D Operations“ und bei Bedarf bis hin zum Chief Product Officer (CPO) eskaliert.

Von Anbietern, die Komponenten oder Dienstleistungen für Produkte im Geltungsbereich von ISO 27001, SOC 2 und NIST SSDF bereitstellen, wird erwartet, dass sie die nachstehend aufgeführten Anforderungen des Secure Framework“ erfüllen. Die Einhaltung dieser Anforderungen unterliegt regelmäßigen Sicherheitsaudits, Bewertungen durch Dritte sowie den Verpflichtungen der jeweiligen Parteien im Rahmen der abgeschlossenen Verträge. 

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. 

Anbieter von Produktkomponenten und Bibliotheken müssen Entwicklungsumgebungen einrichten, die unseren im Abschnitt Secure “ beschriebenen Vorgehensweisen entsprechen. Sie müssen ihre Komponenten und Bibliotheken Sicherheitsprüfungen unterziehen, wie im Abschnitt „Sicherheitsprüfungen und -verifizierung von Anwendungen“ beschrieben. 

Anbieter von Pipeline-Komponenten müssen zudem Entwicklungsumgebungen einrichten, die unseren im Abschnitt Secure “ beschriebenen Vorgehensweisen entsprechen. Darüber hinaus müssen ihre Entwicklungsprozesse mit dem Secure Process“ OPSWATübereinstimmen. 

Von Dienstleistern wird erwartet, dass sie in den USA ansässige Umgebungen nutzen, deren Sicherheitsstandard mit dem der Dienste OPSWATvergleichbar ist. Ihr Secure muss sowohl ein Secure Programm als auch einen Secure Prozess umfassen, die den Erwartungen OPSWATentsprechen.