Entwicklung & Code
Cyber Resilience Act: Initiative der Eclipse Foundation hilft bei Compliance
Die Eclipse Foundation hat den Start des OCCTET-Projekts bekannt gegeben: Hinter dem Namen „Open Source Compliance: Comprehensive Techniques and Essential Tools“ verbirgt sich eine von der Europäischen Kommission finanzierte Initiative zum Thema Cyber Resilience Act (CRA). Sie bringt ein Konsortium aus Industriegrößen, Cybersecurity-Experten und Open-Source-Vertretern zusammen – mit dem Ziel, kleinen und mittleren Unternehmen (KMU) sowie Entwicklerinnen und Entwicklern die Compliance ihrer Open-Source-Software (OSS) mit dem CRA zu vereinfachen. Dazu stellt sie ein Toolkit an Ressourcen zur Verfügung.
Unternehmen müssen jetzt handeln – OCCTET kann unterstützen
Wie Mike Milinkovich, Executive Director der Eclipse Foundation, in der OCCTET-Ankündigung betont, ist die Compliance mit dem CRA eine mehrjährige Reise, die Unternehmen jetzt priorisieren müssen. Doch selbst solchen, die die Dringlichkeit verstehen, mangele es häufig an in-House-Expertise.
Dort setzt die neue Initiative an: Das bald erscheinende OCCTET Toolkit soll umfassende Ressourcen bereitstellen, die sich speziell an KMU richten. Dazu zählen unter anderem eine CRA-Compliance-Checkliste, Konformitäts-Assessment-Spezifikationen, automatisierte Evaluierung von Methoden und Tools und eine föderierte Datenbankplattform, um OSS-Komponenten-Assessments zu veröffentlichen und Beiträge mehrerer Stakeholder zu ermöglichen. Weiterführende Details zu den Inhalten des Toolkits liefert die OCCTET-Website, und zusätzlich ist eine Mailingliste verfügbar.
(Bild: Brigitte Pica2/Shutterstock)
Am 23. und 24. September feiert die Beyond IoT ihre Premiere in Köln. Die von iX und dpunkt.verlag ausgerichtete Konferenz für IIoT und Digitalisierung bringt Vorträge zu Themen wie CRA, Zeitreihenanalyse, UNS und Web of Things.
ORC Working Group: Neue Mitglieder und erste Ressourcen
OCCTET ist nicht die einzige Initiative der Eclipse Foundation in Bezug auf den CRA. Auch die Open Source Regulatory Compliance Working Group (ORC Working Group) bietet nun erste Ressourcen an, um die CRA-Implementierung und -Compliance zu unterstützen. Zudem hat die Working Group einen Zuwachs vorzuweisen: Als strategische Mitglieder sind jetzt Microsoft und Red Hat mit an Bord, als weitere Mitglieder Google, exkide und Open Source Matters.
Die ORC Working Group besteht seit September 2024 und soll insbesondere vor dem Hintergrund des Cyber Resilience Act die Relevanz und Compliance von Open-Source-Software sicherstellen. Sie steht unter der anbieterneutralen Verwaltung der Eclipse Foundation, der größten Open-Source-Foundation in Europa, und profitiert von ihrem offiziellen Verbindungsstatus mit dem Europäischen Komitee für Normung (CEN) und dem Europäischen Komitee für elektrotechnische Normung (CENELEC) sowie ihrer aktiven Partizipation am Europäischen Institut für Telekommunikationsnormen (ETSI) und an der CRA-Expertengruppe der Europäischen Kommission.
Bereits zum Start der Arbeitsgruppe erhielt die Eclipse Foundation Unterstützung von Industriegrößen wie Bosch, Mercedes-Benz und Siemens sowie von anderen Open-Source-Stiftungen und kann inzwischen über 50 Mitglieder vorweisen – darunter rund 20 Open-Source-Stiftungen. Wie Milinkovich im Gespräch mit heise Developer betont, sei eine solche Zusammenarbeit von zahlreichen Open-Source-Stiftungen wohl einzigartig. Nun trägt die ORC Working Group die ersten Früchte, die zur Community-Review bereit sind.
Auf GitHub hat die Working Group ein Inventar an Ressourcen öffentlich gestellt, die für das Entwickeln und Verwenden von Open-Source-Software gemäß dem Cyber Resilience Act relevant sind. Das Dokument skizziert unter anderem die Prinzipien von Security-Resilienz im Sinne des CRA und behandelt Themen wie generische Sicherheitsanforderungen, Vulnerability-Management und Software Bills of Materials (SBOMs). Das Dokument hebt hervor, dass es sich um einen Entwurf handelt, der jederzeit aktualisiert, ersetzt oder für obsolet erklärt werden könnte – auch beim Zitieren daraus ist daher darauf zu achten, dass es sich um ein „Work in Progress“ handelt.
CRA-Einführung mit Hürden
Schon im Herbst 2023 sprach heise Developer mit Mike Milinkovich über den CRA – der damals die Welt der Open-Source-Software in Atem hielt, da er dramatische Auswirkungen darauf hätte haben können. Der CRA hat seit den ersten Entwürfen bis zur finalen Version dahingehend Änderungen durchlaufen: Verantwortlich für die Compliance sind nun nicht die Open-Source-Projekte, die im kommerziellen Umfeld genutzt werden, sondern die Unternehmen, die diese Software verwenden. Die Änderungen gehen nicht zuletzt auf Bemühungen von Open-Source-Organisationen wie der Eclipse Foundation und ihrer Stakeholder in der Industrie zurück. Wie Mike Milinkovich in einem erneuten Gespräch mit heise Developer sagt, sei dies das erste Mal, dass irgendwo auf der Welt bei einem Gesetz eine neue Form des ökonomischen Akteurs namens „Open Source Software Steward“ berücksichtigt wurde.
Im Grunde genommen sei der Cyber Resilience Act eine gute Sache, so Milinkovich: Der Zweck des CRA sei es, die Cybersicherheit von Produkten, die an Konsumenten und Unternehmen in Europa verkauft werden, zu verbessern – und es gebe zu viele Beispiele von Produkten, die in ihrem Design und ihrer Implementierung, aber auch in Bezug auf den Support über den Lebenszyklus des Produkts hinweg, keine guten Industriestandards für Cybersicherheit erfüllt hätten. Jedoch bringe die Komplexität der Implementierung einen Kulturschock, denn die drei Jahre dauernde Implementierungsphase zwischen Dezember 2024 und Dezember 2027 werde blitzschnell – „in the blink of an eye“ – vergehen.
(mai)
Entwicklung & Code
software-architektur.tv: KI-Architektur zwischen Hype und Realität
Diese Folge des Videocasts dreht sich um das Eichhörnchen im Kopf – die KI-Architektur zwischen Hype und Realität. Kimi 2, Grok 4, Windsurf, Metas Manhattan-große KI-Rechenzentren – jeden Tag neue KI-Tools, Ankündigungen und Versprechen. Das Eichhörnchen im Kopf springt im Sekundentakt zwischen den Themen hin und her. Wie sollen Softwarearchitektinnen und -architekten da noch den Überblick behalten und fundierte Entscheidungen treffen?
Barbara Lampl kennt dieses Problem aus erster Hand: Als KI-Expertin beobachtet sie täglich die rasante Entwicklung der KI-Landschaft und weiß, wie überwältigend die Informationsflut sein kann. In dieser Folge diskutieren Ralf D. Müller und Barbara Lampl, wie man als Architekt einen klaren Kopf behält, wenn das Eichhörnchen mal wieder Vollgas gibt.
Eine Folge für alle, die sich manchmal fragen: „Passt das alles eigentlich noch zusammen?“ – Spoiler: Ja, aber es ist komplexer, als vielen lieb ist.
Lisa Maria Schäfer malt dieses Mal keine Sketchnotes.
Livestream am 15. August
Die Ausstrahlung findet live am Freitag, 15. August 2025, 13 bis 14 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat, Bluesky, Mastodon, Slack-Workspace oder anonym über das Formular auf der Videocast-Seite einbringen.
software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.
Weitere Informationen zur Folge finden sich auf der Videocast-Seite.
(mai)
Entwicklung & Code
Nvidia: Updates gegen hochriskante Lücken in KI-Software
In diverser KI-Software von Nvidia haben die Entwickler Sicherheitslücken gefunden. Diese stellen teils ein hohes Risiko dar. Aktualisierte Software respektive Repositories stehen bereit, mit denen Betroffene die Software absichern können.
Betroffen sind die Nvidia-Projekte Apex, Isaac-GR00T, Megatron LM, Merlin Transformers4Rec, NeMo Framework sowie WebDataset. Die Schwachstellenbeschreibungen nennen als Auswirkungen der Sicherheitslücken, dass Angreifer etwa beliebigen Code ausführen, ihre Rechte ausweiten, Informationen ausspähen oder Daten manipulieren können.
Mehrere Projekte mit Sicherheitslecks
Details zu den einzelnen Lücken nennt das Unternehmen in den einzelnen Sicherheitsmitteilungen nicht, sondern erörtert lediglich, was bösartige Akteure damit anrichten können:
- Security Bulletin: NVIDIA Apex – August 2025 (CVE-2025-23295, CVSS 7.8, Risiko „hoch„)
- Security Bulletin: NVIDIA Isaac-GR00T – August 2025 (CVE-2025-23296, CVSS 7.8, Risiko „hoch„)
- Security Bulletin: NVIDIA Megatron LM – August 2025 (CVE-2025-23305, CVE-2025-23306, beide CVSS 7.8, Risiko „hoch„)
- Security Bulletin: NVIDIA Merlin Transformers4Rec – August 2025 (CVE-2025-23298, CVSS 7.8, Risiko „hoch„)
- Security Bulletin: NVIDIA NeMo Framework – August 2025 (CVE-2025-23303, CVE-2025-23304, beide CVSS 7.8, Risiko „hoch„)
- Security Bulletin: NVIDIA WebDataset – August 2025 (CVE-2025-23294, CVSS 7.8, Risiko „hoch„)
In den einzelnen Security-Advisories verweist Nvidia jedoch auf die jeweiligen Github-Repositories und die einzelnen Commits, die die aufgeführten Sicherheitslecks stopfen. IT-Verantwortliche sollten dafür Sorge tragen, dass die Aktualisierungen in der eingesetzten Software auch angewendet werden, um die Angriffsfläche zu reduzieren.
Zuletzt wurden im März Schwachstellen in KI-Software von Nvidia bekannt. Die HGX-Software „Hopper HGX for 8-GPU“ enthielt zwei Sicherheitslücken, die Angreifer zum Ausführen von Schadcode oder zum Lahmlegen der Software (DoS) missbrauchen konnten.
(dmk)
Entwicklung & Code
Künstliche Neuronale Netze im Überblick 4: Verlustfunktionen
Neuronale Netze sind der Motor vieler Anwendungen in KI und GenAI. Diese Artikelserie gibt einen Einblick in die einzelnen Elemente. Der vierte Teil der Serie stellt die gängigsten Verlustfunktionen vor, leitet ihre Gradienten ab und zeigt dann, wie man die grundlegende Gradientenabstiegs-Aktualisierungsregel und ihre komplexeren Varianten entwickelt.
Prof. Dr. Michael Stal arbeitet seit 1991 bei Siemens Technology. Seine Forschungsschwerpunkte umfassen Softwarearchitekturen für große komplexe Systeme (Verteilte Systeme, Cloud Computing, IIoT), Eingebettte Systeme und Künstliche Intelligenz.
Er berät Geschäftsbereiche in Softwarearchitekturfragen und ist für die Architekturausbildung der Senior-Software-Architekten bei Siemens verantwortlich.
Um einem neuronalen Netzwerk nützliche Aufgaben beizubringen, müssen wir quantifizieren, wie gut seine Vorhersagen mit den Zielwerten übereinstimmen. Eine Verlustfunktion ist ein skalares Maß für den Fehler, den der Trainingsprozess durch Anpassung der Netzwerkparameter minimieren soll.
Mittlerer quadratischer Fehler für Regression
Wenn die Aufgabe des Netzwerks darin besteht, kontinuierliche Größen vorherzusagen, ist der mittlere quadratische Fehler eine naheliegende Wahl. Angenommen, wir haben einen Datensatz mit N Beispielen, wobei jedes Beispiel i einen Zielwert yᵢ hat und das Netzwerk eine Vorhersage ŷᵢ liefert. Der mittlere quadratische Fehler L ist definiert durch
L(ŷ, y) = (1/N) Σᵢ (ŷᵢ − yᵢ)²
Dieser Ausdruck summiert die quadrierten Differenzen zwischen Vorhersage und Zielwert über alle Beispiele und dividiert sie durch N, um einen Durchschnitt zu erhalten. Durch die Quadrierung des Fehlers werden große Abweichungen stärker bestraft als kleine, und durch den Durchschnitt wird der Verlust unabhängig von der Größe des Datensatzes.
Um zu sehen, wie dieser Verlust die Parameteraktualisierungen beeinflusst, berechnen wir seine Ableitung in Bezug auf eine einzelne Vorhersage ŷⱼ:
∂L/∂ŷⱼ = (2/N) (ŷⱼ − yⱼ)
Während der Rückpropagation wird dieser Gradient durch das Netzwerk weitergeleitet und steuert jede Gewichtsaktualisierung in Richtung einer Verringerung des quadratischen Fehlers.
In PyTorch schreibt man:
import torch
import torch.nn as nn
# Angenommen, `model` ordnet Eingaben den Vorhersagen ŷ der Form (batch_size, 1) zu
loss_fn = nn.MSELoss() # erstellt ein Modul für den mittleren quadratischen Fehler
predictions = model(inputs) # Vorwärtsdurchlauf erzeugt ŷ
loss = loss_fn(predictions, targets)
Hier kapselt nn.MSELoss()
die obige Formel. Wenn wir später loss.backward()
aufrufen, berechnet PyTorch ∂L/∂parameters automatisch, indem es die partiellen Ableitungen durch den Berechnungsgraphen verkettet.
Kreuzentropie für die Klassifizierung
Wenn die Aufgabe die Klassifizierung in eine von C Klassen ist, gibt das Netzwerk typischerweise einen Vektor von Logits z ∈ ℝᶜ für jedes Beispiel aus. Um diese Logits in eine Wahrscheinlichkeitsverteilung p umzuwandeln, wenden wir die Softmax-Funktion an:
softmax(z)ᵢ = exp(zᵢ) / Σⱼ exp(zⱼ)
Wenn die wahre Klassenbezeichnung für Beispiel i als One-Hot-Vektor y codiert ist, wobei yᵢ = 1 und yⱼ = 0 für j ≠ i, dann ist der Kreuzentropieverlust
L(z, y) = − Σᵢ yᵢ · log( softmax(z)ᵢ )
Da nur ein Eintrag von y ungleich Null ist, vereinfacht sich dies zu der negativen Log-Wahrscheinlichkeit, die der richtigen Klasse zugewiesen wird. Bei Verwendung von PyTorch’s nn.CrossEntropyLoss
fusioniert die Implementierung die Softmax- und Log-Schritte auf numerisch stabile Weise und erwartet rohe Logits und ganzzahlige Klassenindizes:
import torch.nn as nn
loss_fn = nn.CrossEntropyLoss() # erstellt einen kombinierten Log-Softmax + NLL-Verlust
logits = model(inputs) # Form (batch_size, num_classes)
loss = loss_fn(logits, class_indices)
Im Hintergrund ist der Gradient von L in Bezug auf jedes Logit zₖ
∂L/∂zₖ = softmax(z)ₖ − yₖ,
was genau der Differenz zwischen der vorhergesagten Wahrscheinlichkeit und der tatsächlichen Beschriftung für jede Klasse entspricht.
Grundlegender Gradientenabstieg
Sobald ein Verlust festgelegt wurde, ist die einfachste Regel zur Parameteraktualisierung der Gradientenabstieg. Bezeichnen wir mit θ einen einzelnen Skalarparameter (einen Eintrag einer Gewichtungsmatrix oder eines Bias-Vektors) und mit L(θ) den Verlust als Funktion von θ. Die Gradientenabstiegsregel aktualisiert θ in Richtung des steilsten Abstiegs:
θ ← θ − η · ∂L/∂θ
Hier ist η > 0 die Lernrate, ein Hyperparameter, der die Schrittgröße steuert. Ein kleiner η-Wert führt zu einer langsamen, aber stabilen Konvergenz, während ein großer η-Wert dazu führen kann, dass der Verlust schwankt oder divergiert.
In der Praxis unterscheidet man drei Varianten: Wenn der Gradient vor jeder Aktualisierung über den gesamten Datensatz berechnet wird, spricht man von Batch-Gradientenabstieg; wenn für jede Aktualisierung nur ein einziges Beispiel verwendet wird, spricht man von stochastischem Gradientenabstieg; und wenn kleine Teilmengen von Beispielen (Mini-Batches) verwendet werden, spricht man von Mini-Batch-Gradientenabstieg. Mini-Batch-Aktualisierungen stellen einen Kompromiss zwischen verrauschten, aber schnellen stochastischen Aktualisierungen und stabilen, aber kostspieligen Batch-Aktualisierungen dar.
PyTorch bietet über das Paket torch.optim
eine einfache Möglichkeit, Gradientenabstieg mit Mini-Batches durchzuführen. Um beispielsweise den einfachen stochastischen Gradientenabstieg mit Momentum zu verwenden, schreibt man:
import torch.optim as optim
optimizer = optim.SGD(model.parameters(), lr=0.01, momentum=0.9)
# für Eingaben, Ziele in data_loader: data_loader liefert Mini-Batches
optimizer.zero_grad() # alle akkumulierten Gradienten löschen
outputs = model(inputs) # Vorwärtsdurchlauf
loss = loss_fn(outputs, targets) # Verlust berechnen
loss.backward() # Rückwärtspropagierung zur Berechnung der Gradienten
optimizer.step() # Parameter an Ort und Stelle aktualisieren
Der Aufruf von optimizer.zero_grad()
löscht die Gradientenpuffer aller Parameter, sodass sich Gradienten aus früheren Iterationen nicht ansammeln. Der Aufruf von loss.backward()
füllt das Attribut .grad
jedes Parameters mit dem berechneten ∂L/∂θ, und optimizer.step()
verwendet diese Gradienten, um die Parameter gemäß der gewählten Aktualisierungsregel zu aktualisieren.
Fortgeschrittene Optimierer: RMSProp und Adam
Während einfaches Momentum die Konvergenz in Tälern der Verlustfunktion beschleunigen kann, passen adaptive Methoden die Lernrate jedes Parameters individuell auf der Grundlage der Historie seiner Gradienten an. RMSProp behält einen exponentiell gewichteten gleitenden Durchschnitt der vergangenen quadrierten Gradienten bei:
sₜ = γ·sₜ₋₁ + (1−γ)·gₜ²
θ ← θ − (η / sqrt(sₜ + ε)) · gₜ
wobei gₜ = ∂L/∂θ zum Zeitpunkt t, γ typischerweise um 0,9 liegt und ε eine kleine Konstante für die numerische Stabilität ist. In PyTorch wird dies wie folgt konstruiert:
optimizer = optim.RMSprop(model.parameters(),
lr=0.001,
alpha=0.99,
eps=1e-8)
Adam kombiniert Momentum und RMSProp, indem es sowohl einen gleitenden Durchschnitt der Gradienten mₜ als auch der quadrierten Gradienten vₜ beibehält und eine Bias-Korrektur anwendet:
mₜ = β₁·mₜ₋₁ + (1−β₁)·gₜ
vₜ = β₂·vₜ₋₁ + (1−β₂)·gₜ²
m̂ₜ = mₜ / (1−β₁ᵗ)
v̂ₜ = vₜ / (1−β₂ᵗ)
θ ← θ − η · ( m̂ₜ / ( sqrt(v̂ₜ) + ε ) )
mit den Standardwerten β₁=0,9, β₂=0,999 und ε=1e-8.
Im Code:
optimizer = optim.Adam(model.parameters(),
lr=0.001,
betas=(0.9, 0.999),
eps=1e-8)
Jeder dieser Optimierer erfordert die Abstimmung seiner Hyperparameter – Lernrate, Abklingraten und Epsilon –, um die beste Leistung für ein bestimmtes Problem zu erzielen.
Der nächste Teil der Serie zeigt, wie diese Komponenten zu einer vollständigen Trainingsschleife zusammengesetzt werden. Anschließend untersucht er die Unterschiede zwischen dem Training mit und ohne explizite Minibatches und stellt Techniken wie Dropout und Gewichtsabnahme zur Verbesserung der Generalisierung vor.
(rme)
-
Datenschutz & Sicherheitvor 2 Monaten
Geschichten aus dem DSC-Beirat: Einreisebeschränkungen und Zugriffsschranken
-
Apps & Mobile Entwicklungvor 2 Monaten
Metal Gear Solid Δ: Snake Eater: Ein Multiplayer-Modus für Fans von Versteckenspielen
-
Online Marketing & SEOvor 2 Monaten
TikTok trackt CO₂ von Ads – und Mitarbeitende intern mit Ratings
-
Digital Business & Startupsvor 1 Monat
10.000 Euro Tickets? Kann man machen – aber nur mit diesem Trick
-
UX/UI & Webdesignvor 2 Monaten
Philip Bürli › PAGE online
-
Digital Business & Startupsvor 2 Monaten
80 % günstiger dank KI – Startup vereinfacht Klinikstudien: Pitchdeck hier
-
Social Mediavor 2 Monaten
Aktuelle Trends, Studien und Statistiken
-
Apps & Mobile Entwicklungvor 2 Monaten
Patentstreit: Western Digital muss 1 US-Dollar Schadenersatz zahlen