SAP Security Notes einspielen: vom Patch Day bis in die Produktion
Am zweiten Dienstag jedes Monats liegt ein neuer Stapel bereit. Die Arbeit beginnt danach: zuordnen, bewerten, den Umsetzungsweg je Hinweis bestimmen und den Rollout so schneiden, dass er in ein Wartungsfenster passt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Stapel ist monatlich da, der Prozess dahinter meistens nicht
In vielen Häusern sieht der Umgang mit Sicherheitshinweisen so aus: Jemand bekommt die Meldung, öffnet die Liste, sieht dreißig Einträge quer über Produkte, von denen die Hälfte gar nicht installiert ist, und legt sie zur Seite. Beim nächsten Mal ist die Liste länger, weil die vom Vormonat noch offen ist. Nach einem halben Jahr gibt es keinen Rückstand mehr, den man abarbeiten könnte, sondern nur noch ein Thema, das man vermeidet. Das ist keine Nachlässigkeit, sondern die vorhersehbare Folge einer fehlenden Zuordnung: Solange nicht klar ist, welcher Hinweis welches eurer Systeme betrifft, ist die Liste eine Nachricht und kein Arbeitsvorrat.
Der zweite Stolperstein ist die Punktzahl. CVSS beschreibt, wie schwer eine Schwachstelle im Allgemeinen wiegt, nicht wie schwer sie bei euch wiegt. Eine Lücke mit hohem Wert in einer Komponente, die ihr nicht installiert habt, ist für euch nichts wert. Eine mittlere Lücke in einem Dienst, der aus dem Internet erreichbar ist, kann dagegen der dringlichste Punkt der Liste sein. Wer streng nach Punktzahl sortiert, arbeitet eine Reihenfolge ab, die für ein Durchschnittsunternehmen gilt, und lässt genau die Fälle liegen, in denen die eigene Landschaft vom Durchschnitt abweicht.
Der dritte Punkt ist der Umsetzungsweg. Der Reflex heißt SNOTE, doch die Transaktion kann nur Hinweise umsetzen, die Korrekturen an bestimmten Repository-Objekten der ABAP Workbench enthalten. Der Blick auf einen echten Patch Day zeigt die Mischung: Am 11. August 2026 waren es 28 neue Hinweise und eine GitHub-Meldung, dazu zwei Aktualisierungen älterer Hinweise, und darunter Korrekturen an Kernel-Ständen, an ABAP-Anwendungen, an einer Cloud-Anwendung und an mitgelieferten Fremdbibliotheken. Für jede dieser Gruppen gilt ein anderer Weg, ein anderes Zeitfenster und oft eine andere Zuständigkeit.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Monatslauf, Schritt für Schritt
Sechs Schritte, die aus einer Veröffentlichung einen eingespielten Stand machen. Der Aufwand steckt nicht im Einspielen, sondern in den ersten beiden Schritten, und genau die werden gern übersprungen.
- 1
Den Stapel abholen und dem eigenen Bestand zuordnen
Die vollständige Liste steht im SAP Support Portal beziehungsweise in SAP for Me unter den Security Notes bereit, und auf der Übersichtsseite stehen auch die Termine des laufenden Jahres. Die Zuordnung übernimmt ihr nicht von Hand: Ein Werkzeug wie System Recommendations im SAP Solution Manager berechnet je System die relevanten Hinweise und unterscheidet dabei Sicherheitshinweise, HotNews, Hinweise zu gesetzlichen Änderungen und Performance-Hinweise. Ohne diesen Rechenlauf diskutiert ihr über Hinweise zu Produkten, die bei euch nicht laufen.
Geschafft, wenn: Eine Liste je System statt einer Liste je Monat, und damit ein Vorrat, der abnehmen kann.
- 2
Bewerten, statt nach Punktzahl zu sortieren
Nimm für jeden relevanten Hinweis drei Fragen dazu: Ist die betroffene Komponente überhaupt aktiviert, aus welchen Netzen ist sie erreichbar, und welche Rechte oder Daten hängen an dem System. Erst daraus entsteht eine Reihenfolge, die zu eurer Landschaft passt. Die CVSS-Zahl bleibt dabei ein wichtiger Eingangswert, und SAP selbst zieht bei 7,0 eine Linie: Ab diesem Wert gelten Hinweise als hoch priorisiert, und daran hängen andere Regeln für die Auslieferung von Korrekturen.
Geschafft, wenn: Eine begründete Reihenfolge mit Terminen, die auch jemand außerhalb des Basis-Teams nachvollziehen kann.
- 3
Den Umsetzungsweg je Hinweis bestimmen
Sortiere die Hinweise nach Weg, nicht nach Priorität. Korrekturen an ABAP-Repository-Objekten laufen über den Note Assistant, umfangreichere Korrekturen über transportbasierte Korrekturanweisungen. Hinweise, die Kernel-Komponenten nennen, werden nicht implementiert, sondern durch einen Kernel-Austausch abgedeckt. Manche Hinweise sind reine Konfigurationsänderungen, andere sind bereits in einem Support Package enthalten, das ohnehin ansteht. Diese Sortierung entscheidet über Zeitfenster und Downtime.
Geschafft, wenn: Jeder Hinweis hat einen Weg, ein Zeitfenster und eine Person, die ihn übernimmt.
- 4
Im Entwicklungssystem einspielen
Der Note Assistant lädt den Hinweis in das System, zeigt an, ob sich die Korrekturanweisungen implementieren lassen, und schreibt die Änderungen in einen Transportauftrag. Voraussetzung ist ein System, das für digital signierte Hinweise und für transportbasierte Korrekturanweisungen vorbereitet ist. Wenn eigene Änderungen an den betroffenen SAP-Objekten vorliegen, kommt der Modifikationsabgleich dazu, und der ist Handarbeit mit fachlicher Entscheidung, keine Formsache.
Geschafft, wenn: Die Korrektur liegt im Entwicklungssystem und steckt in einem Auftrag, der den üblichen Weg nehmen kann.
- 5
Im Qualitätssystem testen
Leite den Testumfang aus der Objektliste des Auftrags ab und nicht aus dem Text des Hinweises. Betroffen sind meist wenige Bausteine, und die gehören in genau den Prozessen geprüft, die sie benutzen. Bei Hinweisen mit manuellen Tätigkeiten prüft ihr zusätzlich, ob die Handarbeit im Qualitätssystem genauso dokumentiert vorliegt, wie sie später in der Produktion ausgeführt werden muss.
Geschafft, wenn: Ein Testprotokoll, das benennt, was geprüft wurde, statt nur zu bestätigen, dass geprüft wurde.
- 6
In die Produktion ausrollen und den Stand festhalten
Die Transporte gehen in derselben Reihenfolge in die Produktion wie in das Qualitätssystem. Kernel-Austausche brauchen ein eigenes Fenster, lassen sich in Landschaften mit mehreren Anwendungsservern aber rollierend fahren, sodass immer mindestens eine Instanz erreichbar bleibt. Halte fest, was eingespielt wurde und was aus welchem Grund offen bleibt, mit Frist und Verantwortung. Ohne diesen letzten Schritt beginnt der nächste Monat wieder bei null.
Geschafft, wenn: Ein dokumentierter Stand je System und eine kurze Liste bewusst offener Punkte mit Datum.
Vom Monatsstapel zum eingespielten Stand
- 01 Am zweiten Dienstag veröffentlicht SAP die Hinweise des Monats gebündelt.
- 02 Ein Abgleich mit dem Systembestand macht aus der Liste einen Arbeitsvorrat je System.
- 03 Die Bewertung ergänzt die CVSS-Zahl um Erreichbarkeit, Rechte und Datenbestand.
- 04 Je Hinweis steht der Weg fest: Note Assistant, Kernel, Support Package oder Konfiguration.
- 05 Entwicklungssystem einspielen, Qualitätssystem testen, dann erst die Produktion.
- 06 Offene Punkte bekommen eine Frist und einen Namen, keinen Vermerk auf später.
Was danach jeden Monat in derselben Reihenfolge läuft
Ein tragfähiger Prozess braucht keine zusätzliche Software, sondern eine feste Reihenfolge und klare Zuständigkeiten. Sechs Bausteine, die sich in einem Vormittag je Monat unterbringen lassen, wenn sie einmal eingerichtet sind.
Zuordnung vor Bewertung
Du lässt die Hinweise auf euren Bestand rechnen, statt sie zu lesen. Ein Werkzeug wie System Recommendations im SAP Solution Manager ermittelt je System die relevanten Hinweise und trennt dabei Sicherheitshinweise, HotNews, Hinweise zu gesetzlichen Änderungen und Performance-Hinweise.
Risiko statt Punktzahl
Du bewertest jeden relevanten Hinweis entlang von Erreichbarkeit, Rechten und Datenbestand des betroffenen Systems. Die CVSS-Zahl geht in diese Bewertung ein, entscheidet sie aber nicht allein.
Den Weg je Hinweis bestimmen
Du erkennst am Hinweis, ob er über den Note Assistant, über eine transportbasierte Korrekturanweisung, über einen Kernel-Austausch, über ein Support Package oder über eine Konfigurationsänderung umgesetzt wird. Das entscheidet über Aufwand und Zeitfenster.
Manuelle Tätigkeiten früh erkennen
Du siehst einem Hinweis an, ob er zusätzliche Handarbeit verlangt, etwa Parameteränderungen oder Nacharbeit an eigenen Objekten. Diese Hinweise gehören in die Release-Planung und nicht in den Monatslauf.
Den Testumfang aus der Objektliste ableiten
Du bestimmst, was zu testen ist, aus den geänderten Objekten und nicht aus dem Fließtext des Hinweises. Damit wird der Test überprüfbar und bleibt in vertretbarem Umfang.
Die eigene Betriebsform kennen
Du weißt, welche Schritte in eurem Vertrag beim Anbieter liegen und welche bei euch bleiben. Zwischen Eigenbetrieb, RISE-Vertrag und Public Edition liegen dabei Welten, und die Annahme, das erledige schon jemand, ist der teuerste Teil.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was am Patch Day tatsächlich veröffentlicht wird
Der Termin ist fest: SAP hat den Patch Day auf den zweiten Dienstag jedes Monats gelegt und ihn ausdrücklich mit den Terminen anderer großer Softwareanbieter abgestimmt, damit Wartungsfenster planbar bleiben. Auf der Übersichtsseite im Support Portal stehen die Termine des laufenden Jahres, dazu die Bulletins der einzelnen Monate. Die vollständige Liste aller Hinweise erreicht ihr über SAP for Me. Ein Bulletin enthält je Eintrag die Hinweisnummer, den Titel mit der CVE-Kennung, das betroffene Produkt samt Versionsständen, die Priorität und die CVSS-Zahl.
SAP unterscheidet dabei zwei Sorten. Patch Day Security Notes sind die Korrekturen, auf die ihr am Patch Day schauen sollt. Support Package Security Notes werden ohnehin mit dem nächsten Support Package eingespielt und sollen euch am Patch Day nicht binden. Diese Trennung ist der Grund, warum eine Monatsliste kürzer sein kann, als der Gesamtbestand vermuten lässt, und warum ein Support-Package-Zyklus einen Teil der Arbeit stillschweigend erledigt.
Wie groß ein Monat ausfällt, schwankt. Der 11. August 2026 brachte 28 neue Sicherheitshinweise und eine GitHub-Meldung, dazu zwei Aktualisierungen zuvor veröffentlichter Hinweise. Vier Einträge waren als kritisch eingestuft, der höchste mit einer CVSS-Zahl von 10,0. Betroffen waren an dem Tag unter anderem Kernel-Stände des Application Server ABAP, ABAP-Entwicklungswerkzeuge, eine Cloud-Anwendung und mitgelieferte Fremdbibliotheken. Genau diese Streuung ist der Grund, warum ein einheitlicher Umsetzungsweg für alle Hinweise nicht funktioniert.
Wie lange SAP eine Korrektur überhaupt liefert
Ein Punkt, der in der Diskussion über Patchstände regelmäßig fehlt: Ob es für euren Stand überhaupt eine Korrektur gibt, hängt davon ab, wie alt euer Support Package ist. Seit dem 11. Juni 2019 gilt die Regel, dass SAP Korrekturen für neue Sicherheitshinweise mit hoher oder sehr hoher Schwere für die Support Packages der jeweils letzten 24 Monate liefert, sofern der Produktstand noch in der Mainstream- oder erweiterten Wartung ist. Vorher waren es 18 Monate.
Für Hinweise mit niedriger oder mittlerer Priorität ist die Zusage schmaler: Sie enthalten Korrekturen mindestens für das jeweils neueste Support Package der Releases in Mainstream- und erweiterter Wartung. Wer mehrere Support Packages hinter dem aktuellen Stand liegt, bekommt für diese beiden Stufen also in der Regel keine eigene Korrektur mehr, sondern zieht sie mit dem nächsten Support Package nach. Eine Randnotiz ist das nicht: Am 11. August 2026 entfielen 19 der 31 Einträge auf die Stufen mittel und niedrig.
Und für Releases, die in die kundenspezifische Wartung übergehen, gilt in der Regel: In den ersten zwölf Monaten werden Hinweise mit hoher Priorität, also mit einer CVSS-Zahl ab 7,0, berücksichtigt, ebenfalls im Rahmen der 24-Monats-Regel für Support Packages. Damit ist die Patch-Frage direkt an die Wartungsfrage gekoppelt. Wer den Wartungsstand seines Systems nicht kennt, kann den eigenen Sicherheitsstand nicht beurteilen, weil er nicht weiß, was er überhaupt bekommen würde.
Nicht jeder Hinweis läuft über SNOTE
Der Note Assistant, erreichbar über die Transaktion SNOTE, ist das Werkzeug für den größten Teil der ABAP-seitigen Arbeit. Er lädt einen Hinweis in das System, zeigt an, ob sich die enthaltenen Korrekturanweisungen implementieren lassen, und spielt sie auf Wunsch automatisch ein. Die Einschränkung steht deutlich in der SAP-Dokumentation: Implementieren lassen sich nur Hinweise, die Korrekturen an bestimmten Repository-Objekten der ABAP Workbench enthalten. Alles andere braucht einen anderen Weg.
Für umfangreichere Korrekturen gibt es transportbasierte Korrekturanweisungen, kurz TCI. Damit können Hinweise auch Objekte mitbringen, die sich nicht als reine Quelltextänderung beschreiben lassen. Das System muss dafür einmalig vorbereitet werden, im SAP-Sprachgebrauch heißt das Bootstrapping des Note Assistant, und dazu gehört auch die Umstellung auf digital signierte Hinweise. Wenn bei euch die Umsetzung eines Hinweises regelmäßig daran scheitert, dass er sich nicht implementieren lässt, ist diese Vorbereitung meistens die Ursache.
Der dritte große Block sind Kernel-Hinweise. Wenn ein Hinweis Komponenten wie KERNEL oder KRNL64UC mit Versionsständen aufführt, wird er nicht in SNOTE eingespielt, sondern durch den Austausch des Kernels abgedeckt. Das ist ein anderer Vorgang mit anderem Risiko und anderem Zeitfenster, dafür deckt ein Austausch viele Hinweise auf einmal ab. Daneben bleiben Hinweise, die reine Konfigurationsarbeit verlangen, etwa geänderte Profilparameter oder Berechtigungen, und Hinweise mit ausdrücklich manuellen Tätigkeiten, die ihr Schritt für Schritt nachvollziehen müsst.
Betriebsformen: wer patcht was
Im Eigenbetrieb liegt alles bei euch: die Zuordnung, die Bewertung, das Einspielen, der Test und der Rollout. Das gilt unverändert auch dann, wenn die Maschinen bei einem Hyperscaler stehen, denn der Betreiber der Infrastruktur kümmert sich nicht um SAP-Hinweise.
In der SAP S/4HANA Cloud Private Edition, also im RISE-Vertrag, ist die Aufteilung im Dokument Roles and Responsibilities festgeschrieben, und sie ist feiner, als die meisten erwarten. Das System zu analysieren und die relevanten Sicherheitshinweise zu ermitteln, ist Standardleistung, allerdings ausdrücklich beschränkt auf kritische Hinweise für den ABAP-Stack. Sicherheitshinweise für SAP Basis ohne manuelle Tätigkeiten werden ebenfalls als Standardleistung in den Entwicklungssystemen eingespielt, und dort endet die Leistung: Für den Transport dieser Hinweise in Qualitäts- und Produktivsysteme und für den zugehörigen Test seid ihr zuständig. Anwendungsbezogene Sicherheitshinweise und alle Hinweise mit manuellen Tätigkeiten stehen unter den Aufgaben, die ihr selbst übernehmt, wenn ihr nicht zusätzlich SAP Cloud Application Services beauftragt. Patches für Software auf Betriebssystemebene, etwa den SAP-Kernel, und Datenbank-Patches sind dagegen wieder Standardleistung, wobei der rollierende Kernel-Wechsel mindestens zwei Anwendungsserver voraussetzt.
In der SAP S/4HANA Cloud Public Edition entfällt die Frage weitgehend, weil SAP die technische Basis betreibt und Korrekturen im Rahmen des Dienstes einspielt. Ihr entscheidet dort nicht über einzelne Hinweise, dafür entscheidet ihr auch nicht über den Zeitpunkt. Was bleibt, ist der Teil, der immer bei euch liegt: eigene Erweiterungen, Berechtigungen und die Frage, welche Schnittstellen ihr geöffnet habt.
Was den Prozess monatlich tragfähig macht
Ein Patchprozess scheitert selten an der Technik und fast immer an drei organisatorischen Punkten. Der erste ist der Termin. Wenn der Patch Day fest im Kalender steht, mit einem festen Zeitfenster für die Bewertung und einem festen Fenster für den Transport in die Produktion, wird die Arbeit planbar und klein. Ohne Termin wächst sie zu einem Projekt heran, das dann verschoben wird.
Der zweite Punkt ist die Zuständigkeit über Teamgrenzen hinweg. Ein Sicherheitshinweis, der eine Anwendung im Rechnungswesen betrifft, braucht jemanden aus dem Fachbereich, der den Test abnimmt. Ein Kernel-Austausch braucht ein Fenster, das mit dem Betrieb abgestimmt ist. Wenn beides erst im Moment der Umsetzung geklärt wird, verlängert sich jeder Monatslauf um die Zeit, die für die Abstimmung nötig ist.
Der dritte Punkt ist der Umgang mit dem, was offen bleibt. Es gibt immer Hinweise, die aus guten Gründen nicht sofort eingespielt werden, weil ein Support Package ansteht, weil eine Eigenentwicklung betroffen ist oder weil das Wartungsfenster nicht reicht. Das ist vertretbar, solange die Entscheidung mit Begründung, Frist und Namen festgehalten wird. Was nicht vertretbar ist, ist ein Rückstand ohne Liste. Er ist im Prüfungsfall nicht erklärbar und, was schwerer wiegt, im Störungsfall nicht auswertbar.
Dazu passende Kurse
Weil sich viele Hinweise erst mit dem Aufbau des Application Server erschließen, gibt es bei cmt SAP-Kurse zur Absicherung des Application Server .
Der Umgang mit Schwachstellen und Bewertungsmaßstäben ist kein SAP-Thema allein, deshalb passen IT-Security-Kurse für den monatlichen Patchprozess daneben.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Häufige Fragen
Wann veröffentlicht SAP die Sicherheitshinweise?
Was ist der Unterschied zwischen Patch Day Security Notes und Support Package Security Notes?
Reicht es, wenn wir uns an der CVSS-Zahl orientieren?
Wer spielt die Hinweise unter RISE with SAP ein?
Muss die Produktion für Sicherheitshinweise stillstehen?
Was tun mit Hinweisen, die manuelle Tätigkeiten verlangen?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem SAP-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Den Monatslauf einmal an der eigenen Landschaft aufsetzen
Welche Hinweise euch tatsächlich betreffen, welcher Weg je Hinweis der richtige ist und wie ein Rollout aussieht, der in ein Wartungsfenster passt, gehst du bei cmt an einem echten System durch.