Cyber Resilience Act und SBOM umsetzen: Welche Architekturkompetenz Unternehmen jetzt brauchen

CRA, SBOM und DevSecOps verändern die Spielregeln in der Softwareentwicklung

Der Cyber Resilience Act (CRA) und die Software Bill of Materials (SBOM) verändern die Anforderungen an Softwareentwicklung, IT-Organisationen und technische Führung. Viele Unternehmen konzentrieren sich am Anfang auf Tools und die Einhaltung von Vorgaben. In der Praxis liegt die eigentliche Herausforderung jedoch oft woanders: Es fehlt an Architekturkompetenz, klarer Verantwortung und einem belastbaren Zusammenspiel aus Entwicklung, Sicherheit und Organisation.

Für Unternehmen entsteht damit die konkrete Entscheidungsfrage: Welche Kompetenzen müssen aufgebaut werden, damit CRA, SBOM und DevSecOps nicht als Einzelmaßnahmen verpuffen, sondern dauerhaft funktionieren?

Dieser Beitrag zeigt, welche organisatorischen Auswirkungen CRA und SBOM haben, welche Rollen dadurch kritischer werden und wie Unternehmen Architekturkompetenz strukturiert aufbauen können.

CRA und SBOM verändern Organisation und Verantwortung

Anforderungen des Cyber Resilience Act im Überblick

Der Cyber Resilience Act verpflichtet Hersteller digitaler Produkte dazu, Cybersicherheit über den gesamten Produktlebenszyklus mitzudenken. Dazu gehören sichere Entwicklung, Risikobewertung, Schwachstellenmanagement, technische Dokumentation und Meldepflichten bei aktiv ausgenutzten Schwachstellen.

Damit wird Sicherheit nicht erst am Ende eines Projekts relevant. Sie muss bereits in Architektur, Entwicklung, Betrieb und Wartung berücksichtigt werden. Weiterführende Quelle unter Cyber Resilience Act der Europäischen Kommission.

SBOM als Steuerinstrument für Software Sicherheit

Software Bill of Materials (SBOM) macht sichtbar, aus welchen Komponenten eine Software besteht. Das klingt zunächst nach einer technischen Liste. Tatsächlich ist SBOM aber ein Steuerungsinstrument für Software Supply Chain Security.

Unternehmen müssen damit nachvollziehen können:

• Welche Komponenten in Produkten verwendet werden
• Welche Abhängigkeiten sicherheitskritisch sind
• Welche Schwachstellen welche Systeme betreffen
• Welche Updates priorisiert werden müssen
• Welche Nachweise für Kunden, Auditoren oder Behörden erforderlich sind

SBOM ist deshalb kein reines Tool Thema. Ohne klare Rollen, gepflegte Prozesse und Architekturverständnis entstehen zwar Daten, aber keine belastbare Steuerung. Weiterführende Quelle zum Cyber Resilience Act unter BSI.

Verschiebung von Verantwortung in Richtung Architektur

CRA und SBOM verschieben Verantwortung früher in den Entwicklungsprozess. Architekturentscheidungen werden sicherheitsrelevant. DevSecOps beschreibt einen Ansatz der Softwareentwicklung, bei dem Sicherheit von Anfang an in Entwicklung und Betrieb integriert wird. Sicherheitsprüfungen, Risikobewertungen und Dokumentation sind dabei fester Bestandteil des Entwicklungsprozesses und nicht eine nachgelagerte Aufgabe.

Ziel ist es, Software kontinuierlich sicher, nachvollziehbar und wartbar zu entwickeln. Architekturentscheidungen werden dadurch stärker mit Sicherheitsanforderungen verknüpft. Komponentenwahl, Schnittstellen, Abhängigkeiten und Updatefähigkeit müssen bewusster gesteuert werden.

Das betrifft nicht nur einzelne Entwickler. Relevanter werden Rollen, die technische Entscheidungen, Sicherheitsanforderungen und organisatorische Verantwortung verbinden.

Dazu zählen insbesondere:

• Softwarearchitekt
• Systemarchitekt
• DevSecOps Engineer
• Security Architect
• Lead Engineer

Diese Rollen müssen nicht nur technische Lösungen verstehen. Sie müssen Risiken einordnen, Entscheidungen dokumentieren und zwischen Entwicklung, Security, Qualitätssicherung und Management vermitteln.

Typische Ausgangslagen und fehlende Kompetenzen

Typische Ausgangssituationen in IT- und Engineering-Organisationen

Viele Unternehmen starten nicht bei null. Häufig gibt es bereits Security Tools, Entwicklungsstandards, Qualitätsprozesse oder einzelne Experten. Trotzdem entstehen Lücken, sobald regulatorische Anforderungen verbindlich werden.

Typische Ausgangssituationen sind:

• Sicherheitsverantwortung ist verteilt: Mehrere Teams kümmern sich um Sicherheit, aber niemand steuert das Gesamtbild.
• Architekturkompetenz ist vorhanden, aber überlastet: Einzelne Experten tragen zentrale Verantwortung. Dadurch entstehen Engpässe und Abhängigkeiten.
• Compliance wird nachgelagert behandelt: Sicherheitsanforderungen werden erst kurz vor Release, Audit oder Kundennachweis relevant.
• SBOM wird technisch erzeugt, aber organisatorisch nicht genutzt: Eine Liste existiert, aber sie ist nicht in Entscheidungen, Prozesse oder Verantwortlichkeiten eingebunden.

Das Reifegradmodell hilft bei der schnellen Selbsteinordnung. Es zeigt, ob ein Unternehmen eher reaktiv, projektgetrieben, strukturiert oder bereits nachhaltig aufgestellt ist und welcher nächste Entwicklungsschritt sinnvoll ist.

Warum Architekturkompetenz zur Engpassressource wird

Die Umsetzung von CRA und SBOM verlangt Fähigkeiten, die selten in einer einzelnen Rolle gebündelt sind. Benötigt werden Softwarearchitektur, Systems Engineering, Security Engineering, DevSecOps Verständnis und Dokumentationsfähigkeit.

Gerade diese Kombination macht Architekturkompetenz zur Engpassressource. Sie entscheidet darüber, ob Sicherheitsanforderungen früh erkannt, sauber übersetzt und dauerhaft in Entwicklungsprozesse integriert werden.

Für Unternehmen und Fachbereiche entstehen daraus neue Aufgaben. Es geht nicht nur darum, einzelne Stellen zu besetzen. Es geht darum, eine Kompetenzstruktur aufzubauen, die regulatorische Anforderungen langfristig tragen kann.

Welche Rollen besonders kritisch werden

Die wichtigste Frage lautet nicht, wer formal zuständig ist. Entscheidend ist, wer die Anforderungen praktisch zusammenführt.

Ein Softwarearchitekt kann Sicherheitsanforderungen in technische Entscheidungen übersetzen. Ein Systemarchitekt betrachtet Schnittstellen, Abhängigkeiten und Systemverhalten. Ein DevSecOps Engineer sorgt dafür, dass Sicherheitsprüfungen in Entwicklungsprozesse integriert werden. Ein Security Architect definiert Leitplanken und bewertet Risiken.

Zur Abgrenzung dieser Rollen ist dieser weiterführende Beitrag sinnvoll: Systemarchitekt vs. Softwarearchitekt vs. Systems Engineer.

Häufige Fehler bei der Umsetzung von SBOM und DevSecOps

SBOM als reines Tool Projekt behandeln

Ein häufiger Fehler besteht darin, SBOM ausschließlich technisch zu betrachten. Unternehmen führen ein Tool ein, ohne zu klären, wer die Daten pflegt, bewertet und in Entscheidungen übersetzt.

Die Folge: Es entstehen Listen, aber keine Handlungsfähigkeit.

Verantwortung zu spät definieren

Viele Organisationen klären Verantwortlichkeiten erst, wenn Fristen, Audits oder Kundenanforderungen konkreter werden. Dann fehlt häufig die Zeit, Rollen sauber aufzubauen.

Besser ist ein frühes Verantwortungsmodell. Es sollte klären, wer Architekturentscheidungen trifft, wer Sicherheitsanforderungen bewertet und wer Nachweise verantwortet.

Sicherheit erst am Ende integrieren

Wenn Security erst kurz vor Release geprüft wird, entstehen hohe Kosten und Verzögerungen. DevSecOps verfolgt deshalb einen anderen Ansatz. Sicherheitsanforderungen werden früh in Entwicklung, Architektur und Automatisierung eingebunden.

Weiterführende Quelle unter NIST Secure Software Development Framework.

Checkliste: Ist das Unternehmen auf CRA und SBOM vorbereitet?

Diese Checkliste hilft, die eigene Ausgangslage einzuschätzen.

Organisation

• Gibt es eine klar definierte Verantwortung für sichere Softwarearchitektur?
• Ist SBOM-Verantwortung eindeutig zugeordnet?
• Sind Security, Entwicklung, Qualität und Management miteinander verbunden?
• Gibt es ein gemeinsames Verständnis von CRA relevanten Anforderungen?

Prozesse

• Werden Sicherheitsanforderungen früh in Projekten berücksichtigt?
• Sind Softwareabhängigkeiten systematisch dokumentiert?
• Werden Schwachstellen regelmäßig bewertet und priorisiert?
• Sind Nachweise für Kunden, Audits oder Behörden abrufbar?

Kompetenz

• Ist Architekturkompetenz dauerhaft verfügbar?
• Gibt es mehr als einzelne Schlüsselpersonen?
• Können Nachwuchskräfte gezielt in Architektur und Security hineinwachsen?
• Besteht ein Plan für den Kompetenzaufbau in kritischen Rollen?

Wenn mehrere Fragen mit Nein beantwortet werden, liegt der Engpass meist nicht nur in Prozessen oder Tools. Dann fehlt eine tragfähige Kompetenzbasis.

Entscheidungsrahmen: Architekturkompetenz systematisch aufbauen

Wann interne Qualifizierung sinnvoll ist

Interne Qualifizierung ist sinnvoll, wenn bereits technische Erfahrung vorhanden ist und Mitarbeiter gezielt in Architektur, Security und DevSecOps hineinwachsen können.

Das passt besonders gut, wenn Unternehmen Wissen langfristig binden möchten und genug Zeit für Entwicklung vorhanden ist.

Wann externe Rekrutierung notwendig wird

Externe Rekrutierung wird relevant, wenn kurzfristig Erfahrung fehlt oder Projekte unmittelbar abgesichert werden müssen.

Der Nachteil liegt im Marktumfeld. Erfahrene Softwarearchitekten, Systemarchitekten und Security Architekten sind schwer verfügbar. Zudem löst eine einzelne Besetzung selten den langfristigen Kompetenzbedarf.

Wann strukturierte Programme sinnvoll werden

Strukturierte Programme sind besonders sinnvoll, wenn mehrere Rollen aufgebaut werden müssen oder eine Organisation nicht dauerhaft von Einzelpersonen abhängig bleiben möchte.

Das betrifft Unternehmen, die Architekturkompetenz nicht nur einkaufen, sondern systematisch entwickeln wollen. Dazu können spezifische, gemeinsam mit dem Kunden entwickelte Traineeprogramme gehören, die technische Grundlagen, Architekturarbeit, Security Verständnis und praktische Projektanwendung verbinden.

Mehr zum Engpass rund um Softwarearchitekten: https://www.spectrum-ag.de/hr-strategy/softwarearchitekt-engpass-loesen/ Der Entscheidungsbaum unterstützt die Auswahl des passenden Kompetenzaufbaus. Er unterscheidet nach Zeitdruck, vorhandener Architekturkompetenz, Anzahl benötigter Rollen und langfristigem Bedarf.

Beispiel aus der Praxis: Wenn SBOM zwar existiert, aber nicht wirkt

Ein mittelständisches Unternehmen entwickelt industrielle Softwareprodukte für internationale Kunden. Durch neue Anforderungen rund um CRA und SBOM wird ein Tool eingeführt, das Softwarekomponenten automatisch erfassen soll.

Nach einigen Monaten zeigt sich jedoch: Die erzeugten Daten sind unvollständig, werden kaum bewertet und haben wenig Einfluss auf Architekturentscheidungen.

Das Problem liegt nicht im Tool. Es fehlt eine Rolle, die bewertet, welche Komponenten sicherheitskritisch sind, welche Abhängigkeiten relevant werden und wie die Erkenntnisse in Entwicklung, Wartung und Kundenkommunikation einfließen.

Erst durch eine klar definierte Architekturverantwortung wird SBOM nutzbar. Aus technischer Dokumentation wird eine Grundlage für bessere Entscheidungen.

Fazit & Key Takeaways

• CRA und SBOM verändern nicht nur Compliance, sondern Rollen, Prozesse und Verantwortung.
• Die größte Herausforderung liegt häufig in fehlender Architekturkompetenz.
• SBOM entfaltet nur dann Wirkung, wenn Daten bewertet und in Entscheidungen integriert werden.
• DevSecOps braucht klare Rollen und frühzeitige Einbindung von Sicherheit.
• Unternehmen sollten prüfen, ob interne Qualifizierung, externe Rekrutierung oder strukturierte Programme der passende Weg sind.

CRA und SBOM machen sichtbar, ob Unternehmen sichere Softwareentwicklung nur punktuell organisieren oder strukturell beherrschen. Tools, Dokumente und Prozesse sind wichtig, reichen aber allein nicht aus.

Entscheidend ist die Fähigkeit, technische Anforderungen, Sicherheitsrisiken und organisatorische Verantwortung zusammenzuführen. Genau dafür braucht es Architekturkompetenz.

Wer die eigene Ausgangslage prüfen oder den Aufbau entsprechender Kompetenzstrukturen besprechen möchte, kann hier den nächsten Schritt starten: https://www.spectrum-ag.de/kontakt/.

FAQ

Betrifft der Cyber Resilience Act auch mittelständische Unternehmen?

Ja. Entscheidend ist nicht nur die Unternehmensgröße, sondern ob digitale Produkte entwickelt, bereitgestellt oder in Verkehr gebracht werden. Auch mittelständische Unternehmen können direkt betroffen sein oder über Lieferketten in Nachweispflichten eingebunden werden.

Ist SBOM vor allem eine Aufgabe der IT?

Nein. Die IT kann Tools bereitstellen und technische Prozesse unterstützen. Die Verantwortung betrifft jedoch auch Entwicklung, Architektur, Security, Qualität und Management. SBOM wird erst dann wirksam, wenn sie in Entscheidungen und Verantwortlichkeiten eingebunden ist.

Welche Rolle ist für CRA und SBOM am wichtigsten?

Es gibt nicht die eine Rolle. Besonders wichtig sind Rollen, die Architektur, Security und Entwicklung verbinden. Dazu zählen Softwarearchitekt, Systemarchitekt, DevSecOps Engineer und Security Architect. Welche Rolle zentral ist, hängt von Produkt, Organisation und Entwicklungsmodell ab.