Herstellerleitfaden für langfristige Android-Sicherheit

In diesem Leitfaden werden von Google empfohlene Best Practices für die Anwendung von Sicherheitspatches beschrieben, die von der Android Compatibility Test Suite (CTS) bewertet werden. Es richtet sich an Hersteller von Android-kompatiblen OEM-Geräten (Herstellern), die länger als drei Jahre unterstützt werden, wie z. B. Fahrzeuge, Fernseher, Set-Top-Boxen und Haushaltsgeräte. Dieses Handbuch richtet sich nicht an Endbenutzer (z. B. Fahrzeugbesitzer).

Danksagungen und Haftungsausschluss

Dieser Leitfaden stellt keine rechtliche oder vertragliche Bindung für Google oder andere Hersteller dar und stellt keine Anforderungen dar. Vielmehr handelt es sich bei diesem Leitfaden um eine Lehrhilfe, die empfohlene Vorgehensweisen beschreibt.

Rückmeldung

Dieser Leitfaden erhebt keinen Anspruch auf Vollständigkeit; Weitere Überarbeitungen sind geplant. Senden Sie Feedback anmakers-guide-android@googlegroups.com.

Glossar

Über Android OS

Android ist ein vollständiger Open-Source-Software-Stack auf Linux-Basis, der für eine Vielzahl von Geräten und Formfaktoren entwickelt wurde. Seit seiner ersten Veröffentlichung im Jahr 2008 hat sich Android zum beliebtesten Betriebssystem (OS) entwickelt und läuft auf über 1,4 Milliarden Geräten weltweit (2016). Ungefähr 67 % dieser Geräte verwenden Android 5.0 (Lollipop) oder neuer (Stand März 2017) (aktuellere Zahlen sind im Android Dashboard verfügbar). Während es sich bei der überwiegenden Mehrheit der Geräte um Mobiltelefone und Tablets handelt, ist Android bei Smartwatches, Fernsehern und IVI-Geräten (In-Vehicle Infotainment) auf dem Vormarsch.

Die Anzahl der im Google Play Store verfügbaren Android-Apps hat 2,2+ Millionen erreicht (2016). Die Entwicklung von Android-Apps wird durch das Android-Kompatibilitätsprogramm unterstützt, das eine Reihe von Anforderungen über das Compatibility Definition Document (CDD) definiert und Testtools über die Compatibility Test Suite (CTS) bereitstellt. Die Android-Kompatibilitätsprogramme stellen sicher, dass jede Android-App auf jedem Android-kompatiblen Gerät ausgeführt werden kann, das die erforderlichen Funktionen für die App unterstützt.

Google veröffentlicht regelmäßig neue Betriebssystemversionen, Betriebssystem-Sicherheitsupdates und Informationen zu entdeckten Schwachstellen. Das Android-Sicherheitsbulletin sollte von den Herstellern auf die Anwendbarkeit dieser Updates auf von Android-Betriebssystemen unterstützte Produkte überprüft werden. Eine Übersicht über Android-Sicherheit, Kompatibilität und Build-Systeme finden Sie hier:

• Sichern Sie ein Android-Gerät
• Sicherheitsupdates und Ressourcen
• Kompatibilitätstestsuite
• Codenamen, Tags und Build-Nummern

Über vernetzte Fahrzeuge (kanonische langlebige Produkte)

Mit der Einführung des AM-Radios in den 1920er Jahren begann die Vernetzung von Fahrzeugen. Von da an begann die Zahl externer physischer und drahtloser Verbindungen zu wachsen, da Regulierungsbehörden und Automobilhersteller sich der Elektronik zuwandten, um Diagnose und Wartung zu vereinfachen (z. B. OBD-II-Anschluss), die Sicherheit zu verbessern (z. B. TPMS) und Kraftstoffverbrauchsziele zu erreichen . Die darauffolgende Konnektivitätswelle führte Komfortfunktionen für den Fahrer ein, wie z. B. einen schlüssellosen Fernzugang, Telematiksysteme und erweiterte Infotainmentfunktionen wie Bluetooth, Wi-Fi und Smartphone-Projektion. Heute unterstützen integrierte Sensoren und Konnektivität (z. B. GPS) Sicherheit und halbautonome Fahrsysteme.

Mit zunehmender Anzahl der Fahrzeugverbindungen vergrößert sich auch die Fläche der potenziellen Fahrzeugangriffsfläche. Verbindungen bringen ähnliche Bedenken hinsichtlich der Cybersicherheit mit sich wie bei Unterhaltungselektronik. Doch während Neustarts, tägliche Patch-Updates und unerklärliches Verhalten bei Unterhaltungselektronik die Norm sind, sind sie bei Produkten mit sicherheitskritischen Systemen wie Fahrzeugen uneinheitlich.

Hersteller müssen einen proaktiven Ansatz verfolgen, um den dauerhaften Sicherheitsstatus eines Produkts im Feld sicherzustellen. Kurz gesagt, Hersteller müssen sich bekannter Sicherheitslücken im Produkt bewusst sein und einen risikobasierten Ansatz zur Behebung dieser Schwachstellen verfolgen.

Sorgen Sie für langfristige Sicherheit

Ein vernetztes Fahrzeug verfügt häufig über eine oder mehrere elektronische Steuereinheiten (ECUs), die mehrere Softwarekomponenten wie Betriebssystem, Bibliotheken, Dienstprogramme usw. umfassen. Hersteller sollten solche Komponenten verfolgen und bekannte veröffentlichte Schwachstellen durch proaktive Analysen identifizieren, einschließlich:

• Regelmäßige Evaluierung des Produkts anhand der CVE-Datenbank (Common Vulnerabilities and Exposures).
• Sammeln von Informationen zu produktbezogenen Sicherheitslücken.
• Sicherheitstests.
• Aktive Analyse von Android-Sicherheitsbulletins.

Beispielhafte Betriebssystem- und Sicherheitspatch-Updates (IVIs mit Android):

Abbildung 1. Beispiel für die Einführung wichtiger Betriebssystem- und Sicherheitsupdates im Laufe der Fahrzeuglebensdauer.

Best Practices für die Sicherheit

Um Sicherheitsgefährdungen zu erschweren, empfiehlt und wendet Google die Verwendung allgemein anerkannter Best Practices für Sicherheit und Softwareentwicklung an, wie unter „Implementierung von Sicherheit“ beschrieben.

Sicherheitsrichtlinien

Zu den empfohlenen Sicherheitspraktiken gehören:

• Verwenden Sie die neuesten Versionen externer Bibliotheken und Open-Source-Komponenten.
• Integrieren Sie keine aufdringliche Debug-Funktionalität in Release-Versionen des Betriebssystems.
• Entfernen Sie ungenutzte Funktionen (um unnötige Angriffsfläche zu reduzieren).
• Nutzen Sie das Prinzip der geringsten Rechte und andere Best Practices für die Entwicklung von Android-Apps .

Richtlinien zur Softwareentwicklung

Zu den empfohlenen Praktiken für eine sichere Softwareentwicklung für den Lebenszyklus des Systems gehören:

• Führen Sie eine Bedrohungsmodellierung durch, um Vermögenswerte, Bedrohungen und potenzielle Gegenmaßnahmen einzustufen und zu identifizieren.
• Führen Sie eine Architektur-/Designprüfung durch, um ein sicheres und solides Design zu gewährleisten.
• Führen Sie regelmäßige Codeüberprüfungen durch, um Anti-Patterns und Fehler so schnell wie möglich zu identifizieren.
• Entwerfen, implementieren und führen Sie Komponententests mit hoher Codeabdeckung durch, darunter:
  • Funktionstests (einschließlich negativer Testfälle)
  • Regelmäßige Regressionstests (um sicherzustellen, dass behobene Fehler nicht wieder auftauchen)
  • Fuzz-Tests (als Teil der Unit-Test-Suite)
• Verwenden Sie statische Quellcode-Analysetools (Scan-Build, Lint usw.), um potenzielle Probleme zu identifizieren.
• Verwenden Sie dynamische Quellcode-Analysetools wie AddressSanitizer, UndefinedBehaviorSanitizer und FORTIFY_SOURCE (für native Komponenten), um potenzielle Probleme während der Systementwicklung zu identifizieren und zu entschärfen.
• Verfügen Sie über eine Verwaltungsstrategie für Software-Quellcode und Release-Konfiguration/-Version.
• Verfügen Sie über eine Patch-Management-Strategie für die Generierung und Bereitstellung von Software-Patches.

Sicherheits-Backport-Richtlinie

Google bietet derzeit drei (3) Jahre lang ab der öffentlichen Veröffentlichung auf API-Ebene aktive Unterstützung für Sicherheits-Backports entdeckter und gemeldeter Sicherheitslücken. Die aktive Unterstützung umfasst Folgendes:

1. Erhalten und untersuchen Sie Schwachstellenberichte.
2. Erstellen, testen und veröffentlichen Sie Sicherheitsupdates.
3. Stellen Sie wiederkehrende Veröffentlichungen von Sicherheitsupdates und Details zu Sicherheitsbulletins bereit.
4. Führen Sie eine Schweregradbeurteilung gemäß den festgelegten Richtlinien durch.

Drei Jahre nach dem öffentlichen Veröffentlichungsdatum der API-Ebene empfiehlt Google die folgenden Richtlinien:

• Verwenden Sie einen Drittanbieter (z. B. einen SoC-Anbieter oder einen Kernel-Anbieter) für die Backport-Unterstützung für Betriebssystem-Sicherheitsupdates, die älter als drei Jahre nach der API-Veröffentlichung sind.
• Beauftragen Sie einen Drittanbieter mit der Durchführung von Codeüberprüfungen mithilfe der öffentlich bereitgestellten ASBs. Während ASBs Schwachstellen für die aktuell unterstützte Version identifizieren, kann ein Hersteller die bereitgestellten Informationen verwenden, um die neu veröffentlichten Updates mit früheren Versionen zu vergleichen. Diese Daten können verwendet werden, um eine Auswirkungsanalyse durchzuführen und möglicherweise ähnliche Patches für Betriebssystemversionen zu generieren, die älter als drei Jahre nach der API-Veröffentlichung sind.
• Laden Sie gegebenenfalls Sicherheitsupdates in das Android Open Source Project (AOSP) hoch.
• Der Hersteller muss den Umgang mit Sicherheitsupdates für herstellerspezifischen Code (z. B. proprietären gerätespezifischen Code) koordinieren.
• Der Hersteller sollte der Benachrichtigungsgruppe „NDA Android Security Bulletin Partner Preview“ beitreten (erfordert die Unterzeichnung rechtlicher Vereinbarungen wie der Entwickler-NDA). Bulletins sollten Folgendes enthalten:
  • Ankündigungen
  • Zusammenfassung der Probleme nach Patch-Level, einschließlich CVE und Schweregrad
  • Gegebenenfalls Einzelheiten zur Sicherheitslücke

Zusätzliche Referenzen

Anweisungen zu sicheren Codierungs- und Softwareentwicklungspraktiken finden Sie hier:

• Motor Industry Software Reliability Association (MISRA) .
• Tools und Methoden des Software Engineering Institute (SEI) .
• Nationales Institut für Standards und Technologie (NIST).

Empfohlene Produktpraktiken

Google empfiehlt die Verwendung der folgenden empfohlenen Vorgehensweisen.

Allgemeine Einführungsrichtlinien

Generell wird empfohlen, jedes angeschlossene Produkt mit der neuesten Betriebssystemversion zu starten, und ein Hersteller sollte versuchen, die neueste Betriebssystemversion zu verwenden, bevor er das Produkt auf den Markt bringt. Während das Sperren der Version notwendig ist, um die Stabilität vor dem Testen und der Validierung zu erhöhen, muss der Hersteller die Produktstabilität, die er von älteren Betriebssystemversionen erhält, mit neueren Betriebssystemversionen ausgleichen, die weniger bekannte Sicherheitslücken und verbesserte Sicherheitsschutzmaßnahmen aufweisen.

Zu den empfohlenen Richtlinien gehören:

• Aufgrund der mit dem Fahrzeugentwicklungsprozess verbundenen langen Entwicklungsvorlaufzeiten müssen Hersteller möglicherweise mit der Betriebssystemversion n-2 oder älter starten.
• Sorgen Sie mit einer Over-the-Air-Kampagne (OTA) für die Konformität mit der Android-Kompatibilität für jede veröffentlichte Android-Betriebssystemversion.
• Implementieren Sie das Produkt Android Firmware-over-the-Air (FOTA)-fähig für schnelle, kundenfreundliche Updates. FOTA sollte unter Verwendung bewährter Sicherheitspraktiken wie Code-Signierung und TLS-Verbindung zwischen Produkt und IT-Backoffice erfolgen.
• Senden Sie unabhängig identifizierte Android-Sicherheitslücken an das Android-Sicherheitsteam.

Hinweis: Google hat über gerätetyp- oder branchenspezifische Benachrichtigungen in den Android-Sicherheitsbulletins nachgedacht. Da Google jedoch den Kernel, die Treiber oder Chipsätze für ein bestimmtes Gerät (Fahrzeug, Fernseher, Wearable, Telefon usw.) nicht kennt, verfügt Google nicht über eine deterministische Möglichkeit, ein bestimmtes Sicherheitsproblem einem Gerätetyp zuzuordnen .

Richtlinien zum Produktzyklus

Der Hersteller sollte bei Produktzyklusverbesserungen stets versuchen, die neueste Betriebssystemversion oder Sicherheitsupdates für die verwendete Version zu verwenden. Aktualisierungen können im Rahmen wiederkehrender regelmäßiger Produktaktualisierungen oder für Hotfixes zur Behebung von Qualitäts- und/oder anderen Problemen durchgeführt werden. Zu den empfohlenen Vorgehensweisen gehören:

• Erstellen Sie einen Plan zur Bewältigung von Treiber-, Kernel- und Protokollaktualisierungen.
• Nutzen Sie eine branchengerechte Methode zur Bereitstellung von Updates für eingesetzte Fahrzeuge.

Kompatibilitätsdefinitionsdokument (CDD)

Das Compatibility Definition Document (CDD) beschreibt Anforderungen, damit ein Gerät als Android-kompatibel gilt. Das CDD ist öffentlich und für jedermann zugänglich. Sie können CDD-Versionen von Android 1.6 bis zur neuesten Version von source.android.com herunterladen.

Um diese Anforderungen an ein Produkt zu erfüllen, sind die folgenden grundlegenden Schritte erforderlich:

1. Der Partner unterzeichnet das Android Compatibility Commitment (ACC) mit Google. Anschließend wird ein Technical Solution Consultant (TSC) als Leitfaden eingesetzt.
2. Der Partner schließt die CDD-Überprüfung für die Android-Betriebssystemversion des Produkts ab.
3. Der Partner führt die CTS-Ergebnisse (unten beschrieben) aus und übermittelt sie, bis die Ergebnisse für die Android-Kompatibilität akzeptabel sind.

Kompatibilitätstest-Suite (CTS)

Das Testtool Compatibility Test Suite (CTS) überprüft, ob eine Produktimplementierung mit Android kompatibel ist und ob die neuesten Sicherheitspatches enthalten sind. CTS ist öffentlich, Open Source und für jedermann verfügbar; Sie können CTS-Versionen von Android 1.6 bis zur neuesten Version von source.android.com herunterladen.

Für jede für die Öffentlichkeit freigegebene Version von Android-Software (Images zur Werksinstallation und Feldaktualisierung) muss die Android-Kompatibilität anhand von CTS-Ergebnissen nachgewiesen werden. Wenn auf dem Gerät beispielsweise Android 7.1 ausgeführt wird, sollte beim Erstellen und Testen eines Release-Intent-Build-Images auf die neueste entsprechende Version von CDD 7.1 und CTS 7.1 verwiesen werden. Herstellern wird dringend empfohlen, CTS frühzeitig und häufig zu nutzen, um Probleme zu erkennen und zu beheben.

CTS-Workflow

Der CTS-Workflow umfasst das Einrichten der Testumgebung, das Ausführen von Tests, das Interpretieren der Ergebnisse und das Verstehen des CTS-Quellcodes. Die folgenden Richtlinien sollen CTS-Benutzern (z. B. Entwicklern, Herstellern) helfen, das CTS effektiv und effizient zu nutzen.

• Führen Sie häufig Tests durch . CTS ist als automatisiertes Tool konzipiert, das in Ihr Build-System integriert werden kann. Durch die häufige Ausführung von CTS können Sie Fehler schnell und frühzeitig erkennen, wenn Softwareverschlechterungen oder Regressionen auftreten.
• Laden Sie den CTS-Quellcode herunter und prüfen Sie ihn . Der vollständige CTS-Quellcode ist Open-Source-Software, die jeder herunterladen und verwenden kann (heruntergeladener Quellcode ist vollständig erstellbar und lauffähig). Wenn ein Test auf dem Gerät fehlschlägt, kann die Untersuchung des entsprechenden Abschnitts des Quellcodes dabei helfen, die Ursache herauszufinden.
• Holen Sie sich das neueste CTS . Neue Android-Versionen können das CTS mit Fehlerbehebungen, Verbesserungen und neuen Tests aktualisieren. Überprüfen Sie die CTS-Downloads regelmäßig und aktualisieren Sie Ihr CTS-Programm bei Bedarf. Der Hersteller und Google vereinbaren, dass die CTS-Version zur Produkteinführung zugelassen wird, da das Produkt irgendwann eingefroren werden muss, während das CTS weiterhin aktualisiert wird.

Bestehen Sie das CTS

Bei einem Android-kompatiblen Produkt stellt Google sicher, dass die CTS- und CTS-Verifier-Berichtstestergebnisse des Geräts akzeptabel sind. Grundsätzlich müssen alle Prüfungen bestanden werden. Ein Test, der jedoch aus anderen Gründen als der Tatsache, dass das Gerät die Android-Kompatibilitätsanforderungen nicht erfüllt, fehlschlägt, muss von Google überprüft werden. Während dieses Vorgangs:

1. Der Hersteller stellt Google die vorgeschlagenen CTS-Patches, Patch-Validierungen und Begründungen zur Verfügung, um das Argument zu beweisen.
2. Google prüft das eingereichte Material und aktualisiert bei Annahme die relevanten CTS-Tests, damit das Gerät die nächste Überarbeitung des CTS bestehen kann.

Wenn ein CTS-Test nach der Anwendung eines Sicherheitspatches plötzlich fehlschlägt, muss der Hersteller den Patch so ändern, dass die Kompatibilität nicht beeinträchtigt wird ODER nachweisen, dass der Test falsch ist, und eine Korrektur für den Test bereitstellen (wie oben beschrieben).

Das CTS bleibt für Überprüfungen von Testfixes offen. Beispielsweise akzeptiert Android 4.4 weiterhin Korrekturen (siehe https://android-review.googlesource.com/#/c/273371/ ).

Häufig gestellte Fragen (FAQs)

F: Wer ist für die Anwendung von Sicherheitsupdates auf eine bestimmte Android-Implementierung verantwortlich?

A: Verantwortlich ist der Hersteller, der das Gerät direkt bereitstellt. Bei diesem Unternehmen handelt es sich nicht um Google, das Sicherheitsupdates im AOSP und nicht für ein bestimmtes Gerät (z. B. ein Fahrzeug) veröffentlicht.

F: Wie geht Google mit Sicherheitsproblemen in Android um?

A: Google untersucht kontinuierlich Probleme und entwickelt potenzielle Lösungen, die Google im Rahmen regelmäßiger Sicherheitsaktualisierungen allen unterstützten API-Ebenen zur Verfügung stellt. Seit August 2015 veröffentlicht Google in regelmäßigen Abständen Bulletins und Links zu Updates auf source.android.com . Google veröffentlicht im Rahmen wichtiger Betriebssystemversionen auch Sicherheitsupdates. Siehe auch die Sicherheits-Backport-Richtlinie .

F: Wenn ein Hersteller alle AOSP-Patches von einem ASB integriert hat, aber keine Patches des im selben Bulletin genannten BSP-Anbieters integriert hat, kann er dann trotzdem die Sicherheitsstufe erhöhen (z. B. den entsprechenden Patch auf Plattform/Build anwenden)?

A: Um ein Android-Sicherheitspatch-Level (SPL) zu deklarieren, muss ein Hersteller alle erforderlichen Probleme angehen, die im Android-Sicherheitsbulletin ( einschließlich früherer Bulletins ) veröffentlicht und einem bestimmten Android-SPL zugeordnet sind. Beispielsweise hat ein Hersteller, der das Sicherheitsbulletin vom März 2017 (SPL vom 01.03.2017) verwendet, alle erforderlichen Probleme behoben, die im Bulletin vom März 2017 für dieses SPL dokumentiert sind, sowie alle vorherigen Updates, einschließlich gerätespezifischer Updates für alle früheren Android-Sicherheitsbulletins, einschließlich die gerätespezifischen Updates im Zusammenhang mit der SPL vom 05.02.2017.

F: Was passiert, wenn der Hersteller mit den vom BSP-Anbieter bereitgestellten Sicherheitsupdates nicht einverstanden ist ODER wenn von einem ASB vorgeschriebene Sicherheitsupdates nicht von den Anbietern bereitgestellt werden?

A: Ein ASB beschreibt Sicherheitslücken (aufgezählt durch eine Liste von CVEs) und bietet häufig entsprechende Sicherheitstests. Ziel ist es, sicherzustellen, dass die aufgeführten Schwachstellen nicht mehr auf einem Gerät reproduziert werden können und dass das Gerät die zugehörigen Sicherheitstests bestehen kann. Es geht also nicht darum, ein von Google oder einem Drittanbieter bereitgestelltes Sicherheitsupdate zu installieren, sondern darum, dass der Hersteller bestätigt, dass das Gerät nicht für die Liste der CVEs im ASB anfällig ist. Dem Hersteller steht es frei, die bereitgestellten Sicherheitsupdates zu verwenden oder, wenn er eine Änderung hat, die für sein Gerät besser geeignet ist, stattdessen diese Änderung zu verwenden.

Stellen Sie sich beispielsweise einen Fall vor, in dem Google eine AOSP-Sicherheitslücke durch eine Codeänderung behebt, die es der Komponente ermöglicht, voll funktionsfähig und mit der CDD kompatibel zu bleiben. Wenn der Hersteller feststellt, dass die Komponente auf dem Gerät nicht benötigt wird oder nicht durch die CDD (oder entsprechende Zertifizierungstests) vorgeschrieben ist, kann der Hersteller die Komponente entfernen, um den zukünftigen Wartungsbedarf zu reduzieren und die Angriffsfläche zu verringern. Obwohl der Hersteller das bereitgestellte Sicherheitsupdate nicht verwendet hat, hat er sichergestellt, dass das Gerät nicht für das im Sicherheitsbulletin dokumentierte CVE anfällig ist. Wenn der Hersteller jedoch vom empfohlenen Sicherheitsupdate abweicht, geht er das Risiko ein, das Problem falsch anzugehen, neue Sicherheitslücken einzuführen oder die Funktionalität des endgültigen Builds auf andere Weise zu beeinträchtigen.

Während wir mit allen SoC-Partnern zusammenarbeiten, um sicherzustellen, dass für alle Probleme in einem ASB Lösungen vorhanden sind, empfehlen wir den Herstellern, einen Wartungsvertrag mit ihren SoC-Anbietern für den Lebenszyklus eines Geräts abzuschließen. SoCs stellen die Wartung eines Chipsatzes möglicherweise früher als gewünscht ein. Daher ist die Festlegung von Vereinbarungen vor der Auswahl des Geräte-Chipsatzes ein wichtiger Teil des Geräteeinführungsprozesses.

Schließlich könnte ein Hersteller in Fällen, in denen es unmöglich ist, direkt einen Fix für ein in einem ASB dokumentiertes Problem zu erwerben oder unabhängig zu erstellen, die vorherige Android-SPL beibehalten und dennoch die neuen verfügbaren Fixes zum Build hinzufügen. Diese Praxis wird jedoch letztendlich zu Problemen bei der Build-Zertifizierung führen (da Android sicherstellt, dass auf zertifizierten Geräten die neueste Sicherheitspatch-Stufe verfügbar ist). Google empfiehlt, im Voraus mit Ihrem SoC zu arbeiten, um diese Praxis zu vermeiden.

F: Wenn der Hersteller feststellt, dass ein ASB-Artikel für sein Produkt nicht geeignet ist, muss der Artikel trotzdem angewendet oder gepatcht werden, um die anderen Google-Anforderungen zu erfüllen oder CTS zu bestehen?

A: Wir verlangen keine Patches, um eine Android-Sicherheitspatchstufe (SPL) zu deklarieren; Wir verlangen jedoch, dass der Hersteller bestätigt, dass sein Build nicht anfällig für das Problem ist.

Ein Beispiel wäre, wenn eine Komponente, die gepatcht werden soll, im System des Herstellers nicht vorhanden ist oder eine Komponente aus dem System des Herstellers entfernt wird, um ein Problem zu beheben. In diesem Fall kann das System konform sein, ohne dass der Hersteller einen Patch durchführen muss.

Dies unterscheidet sich grundlegend von einem Hersteller, der beispielsweise nur kritische Patches reparieren möchte, andere anwendbare Patches jedoch nicht übernimmt, was dazu führen würde, dass ein Sicherheitstest fehlschlägt. In diesem Fall wird davon ausgegangen, dass der SPL nicht eingehalten wurde.