Entwicklung & Code
Von Bitnami müssen wir uns allerdings verabschieden
Ende August werden große Teile des Bitnami-Katalogs kostenpflichtig und über Arrow teuer vermarktet. Kunden befürchten Kosten von 50.000 US-Dollar im Jahr und mehr. Die jetzige Sammlung wandert in einen Legacy-Katalog, den Broadcom aber nicht mehr pflegen wird. Anwenderinnen und Anwender müssen nach Alternativen suchen.
Johannes Kleinlercher ist Senior Cloud-Native Platform Engineer bei der Firma suXess-it in Österreich und berät gerne Kunden im Bereich Kubernetes, Cloud-Native und Platform-Engineering. Mit der Internal Developer Platform Distribution kubriX bietet suXess-it eine Out-Of-The-Box IDP auf Basis von Kubernetes an, um schnell und unkompliziert eigene Self-Service-Plattformen aufzubauen.
heise developer spricht mit dem Cloud-native-Experten Johannes Kleinlercher darüber, wie Anwender sich behelfen können, welche Alternativen es gibt und welche Perspektiven sich für die Open-Source-Community ergeben.
Manche Images und Charts bleiben bei Bitnami ja offen. Aber welche für Developer wichtigen hat Broadcom konkret hinter die Paywall geschoben?
Welche Bitnami-Images weiterhin offen bleiben, sieht man jetzt schon vorab unter https://hub.docker.com/u/bitnamisecure. Für Helm-Charts ist das hingegen gar nicht so leicht offiziell herauszufinden. Bitnami erwähnt nur das populäre Chart sealed-secrets. Das heißt, man muss davon ausgehen, dass mehr oder weniger alle anderen nicht mehr frei zur Verfügung stehen.
Der Sourcecode der Helm-Charts bleibt allerdings unter der Apache-2.0-Lizenz frei zur Verfügung, nur die gebauten und versionierten OCI-Artefakte verschwinden hinter der Paywall. Um herauszufinden, welche Images ein Helm-Chart heranziehen, empfehle ich das Plug-in helm-images. Und um alle transitiven Abhängigkeiten von Helm-Charts ausgeben zu lassen, das Plugin helm cascade.
In meiner Firma suXess-it verwendeten wir bis vor Kurzem für die Internal Developer Platform kubriX die Charts von Keycloak und PostgreSQL. Gerade das Keycloak-Chart von Bitnami ist bei sehr vielen Entwicklerinnen und Entwicklern beliebt, weil das offizielle Keycloak-Projekt zwar einen Operator für Kubernetes zur Verfügung stellt, aber kein Helm-Chart für diesen oder für eine klassische Keycloak-Installation.
Aber auch bei anderen Applikationen wie Kafka findet man bei einer Suche an erster Stelle immer das Bitnami-Chart. Bitnami hat in seinem Repository 118 Helm-Charts, wie ArgoCD, verschiedene Grafana-Projekte, Nginx, RabbitMQ, Kafka, Gitea, WildFly, Tomcat, WordPress und so weiter. Alle 118 sind je nach Branche mehr oder weniger populär. Viele Firmen verlassen sich auf Bitnami-Charts und -Images, weil sie sehr gut gehärtet und laufend aktualisiert werden.
Welche Folgen ergeben sich für die Projekte, die auf Bitnami bauen?
Die müssen nun aufpassen, ob nicht Helm-Charts als Abhängigkeit – auch indirekte – irgendwo auf ein Bitnami-Chart verweisen, ohne es wirklich zu wissen. Sehr spannend ist auch, dass populäre Helm-Charts wie Kyverno und Velero immer noch in ihrer aktuellsten Version das kubectl-Image von Bitnami integrieren und erst neue Releases herausbringen müssen, wo sie auf Alternativen umstellen, wie die beiden Issues von Kyverno und Velero zeigen. Vermutlich gibt es noch einige andere Charts, die ähnliche Themen haben.
Durch die Umstellung von Broadcom können also tatsächlich viele Probleme entstehen. Ich sehe den Vorfall auch als Weckruf, sich mehr um die Cloud-native Supply Chain zu kümmern und nicht unbedacht Charts oder Images in Projekte zu integrieren. Wichtig ist, die Abhängigkeiten zu verstehen und ordentlich zu managen.
Wie stark ist die Abhängigkeit der Entwicklungs-Branche von Bitnami? Können die Nutzer als Konsequenz einfach auf andere Anbieter umsteigen oder selbst etwas aufsetzen?
Wie bereits erwähnt, nutzten viele Personen oder Firmen in der Vergangenheit Bitnami-Images oder -Charts, weil sie sehr sicher und aktuell gehalten wurden. Dafür muss man sich bei Bitnami bedanken, aber auch bei allen freiwilligen, externen Contributoren, die dazu beigetragen haben.
Bei einigen Charts wie Keycloak gab es auch gar keine Alternative. Ich schätze die generelle Abhängigkeit in der Industrie deshalb als sehr hoch ein. In meiner Firma haben wir mit Keycloak die Erfahrung gemacht, dass wir nicht ohne Weiteres auf einen anderen Anbieter umsteigen können oder sollten. Wenn man irgendwo im Internet eine Alternative findet, muss man sich viele Fragen stellen:
- Wie sicher und vertrauenswürdig ist die Quelle?
- Welche Maintainer stecken dahinter?
- Unter welcher Lizenz wird das Chart oder das Image angeboten?
- Wann wurde das Projekt das letzte Mal aktualisiert?
- Entspricht der Code gängigen Security-Best-Practices?
Natürlich kann man auch immer selbst die Images und Helm-Charts pflegen, aber bei Software, die sich laufend weiterentwickelt, darf man den Wartungsaufwand nicht unterschätzen. Auch die Frage „Was muss ich für die neue Keycloak-Version im Dockerfile oder Helm-Chart anpassen?“ stellt sich dann laufend. Aus diesem Grund entstehen oft Open-Source-Projekte. Nicht weil alles gratis ist, sondern weil man gemeinsam einen Mehrwert für viele schafft, der sonst für einzelne fast unmöglich zu erarbeiten wäre.
Es gibt auch gute Gründe, keine Charts aus der Community zu verwenden. Wenn eine Firma zum Beispiel komplett unabhängig sein will oder eine konkret auf die eigene Umgebung abgestimmte Lösung benötigt.
Für Keycloak gibt es ja erste Überlegungen, eine Alternative ins Leben zu rufen. Wie reagiert die Open-Source-Community auf die neue Paywall?
Für uns in der Firma war klar, dass wir eine nachhaltige Lösung für uns, aber auch für die Community suchen wollen. Ich habe deshalb über LinkedIn und Github-Issues in den jeweiligen Projekten versucht, gemeinsam mit der Community mögliche Alternativen zu finden. Es hat sich herausgestellt, dass die beste Alternative wäre, ein Helm-Chart so nahe wie möglich bei den Keycloak-Maintainern zu entwickeln. Das steigert den Wert des Projekts selbst und macht auch eine halbwegs effiziente Wartung möglich.
Einige Keycloak-Maintainer und -Contributoren stehen dem auch sehr offen gegenüber, wenngleich auch deren Kapazitäten knapp sind. Es geht jetzt also darum, das Ganze wirklich als Gemeinschaftsprojekt zu sehen, und nicht einfach jemandem die Aufgabe zu übergeben und dann nur zu konsumieren. Ob sich das bis zur Einführung der Paywall am 28. August noch ausgeht, steht leider noch nicht fest.
Was können Keycloak-Anwender jetzt tun?
Derzeit empfehle ich allen, die jeweiligen Kubernetes-Manifeste des Keycloak-Operators in der passenden Version ins eigene Helm-Chart zu integrieren und eine eigene Keycloak-CustomResource zu definieren. Wenn eine neue Version des Keycloak-Operators erscheint, muss man entsprechend die Kubernetes-Manifeste aus dem oben erwähnten Git-Repository beim neuen Versions-Tag herunterladen und bei sich integrieren.
Sobald dann ein offizielles Helm-Chart für den Keycloak-Operator zur Verfügung steht, wird dieses Vorgehen mit einem Update der Helm-Chart-Version um einiges komfortabler und Entwickler können es mit dem populären Tool renovate einfacher managen.
Unser Open-Source-Projekt kubriX wird auf jeden Fall nach der Umstellung am 28. August keine Bitnami-Images oder Helm-Charts mehr benötigen.
Eins ist mir noch wichtig festzuhalten: Es steht jeder Firma natürlich frei, ihr Geschäftsmodell rund um ihre Open-Source-Projekte so zu wählen, wie es ihr gefällt. Und jedem muss klar sein, dass Firmen auch im Open-Source-Umfeld Geld verdienen müssen. Sonst überlebt das beste Projekt nicht. Allerdings sind die kolportierten Preismodelle von Broadcom wohl nicht darauf ausgelegt, die breite Masse anzusprechen, obwohl sehr viele Contributoren in der Vergangenheit zur Qualität der Bitnami-Charts und -Images beigetragen haben.
Dementsprechend bin ich gespannt, wo sich das Bitnami-Projekt hinbewegt. Wir unterstützen auf jeden Fall weiterhin diverse Open-Source-Projekte und -Organisationen, von Bitnami müssen wir uns allerdings verabschieden.
Johannes, vielen Dank für das Gespräch!
(who)
Entwicklung & Code
KI Navigator #12: Ist das Kunst oder kann das KI-Bild weg?
Willkommen zur zwölften Ausgabe der KI-Navigator-Kolumne der DOAG KI Community!
Verena Barth setzt sich als Expertin und Speakerin im Bereich Explainable AI (XAI) leidenschaftlich für ethische KI und die Verständlichkeit von komplexen ML-Systemen ein, um eine nachvollziehbare und gewissenhafte Anwendung zu ermöglichen. In industriellen ML-Projekten war sie als IT-Consultant im Bereich Data Science und MLOps tätig, bevor sie 2024 “Business Buddy AI” mitgründete, das personalisiertes Business Coaching mithilfe von affektiver KI skalierbar anbietet.
Neulich zeigte mein Bruder mir eine Illustration eines Sonnenuntergangs am Strand, die angeblich komplett von einer Maschine gemacht wurde. Ein interessanter Stil, eine surreale Landschaft, leuchtende Farben, fantastische Details. Mein erster Impuls: Staunen. Mein zweiter: Skepsis.
Kann KI Kunst? Ein heißes Thema, zu dem ich meinen metaphorischen Senf dazugeben möchte – nicht als neutrale Beobachterin, sondern als jemand, der mitten im Spannungsfeld steht: Ich bin KI-Expertin und Künstlerin.
In Gesprächen mit Kunstschaffenden weltweit begegnen mir immer wieder dieselben Ängste bezüglich KI: kopiert, ausgebeutet und ersetzt zu werden. Was folgt, ist meine persönliche Sicht – subjektiv, ehrlich und frei von akademischem Kunst- oder Philosophieballast.
Was ist Kunst – und wer darf sie machen?
Laut Wikipedia ist Kunst ein kulturelles Ausdrucksmittel des Menschen, das Ergebnisse kreativer Prozesse in Form von Werken hervorbringt, die nicht primär durch Funktionalität, sondern durch Ausdruck, Gestaltung und Bedeutung geprägt sind. Tatsächlich war ich überrascht, wie oft und explizit darauf hingewiesen wird, dass sie aus einer menschlichen Tätigkeit/Arbeit resultiert. Das dient nicht der Differenzierung zwischen Mensch und KI (die auch ein Produkt menschlicher Arbeit ist), sondern zur Natur (natürlich – künstlich).
(Bild: DOAG)
Die Konferenz KI Navigator zeigt am 19. und 20. November in Nürnberg die konkrete Anwendung von KI in den Bereichen IT, Wirtschaft und Gesellschaft. Die von DOAG, heise conferences und de’ge’pol ausgerichtete Veranstaltung bietet gut 100 Sessions in sechs Tracks. Bis zum 1. Oktober sind Tickets zum vergünstigten Frühbucherpreis von 990 Euro (zzgl. MwSt.) verfügbar.
Hier beziehe ich mich auf den enger gefassten Begriff von Kunst im Sinne der sogenannten schönen Künste, primär die Bildende Kunst, nicht auf die Kunst als Handwerk, Technik, Wissen oder bloße Fertigkeit.
Die Kunst wandelt sich mit der Zeit. Sie spiegelt Gesellschaft, Geschichte und Identität, reagiert auf Umbrüche, stellt Fragen und erfindet sich immer wieder neu. Wenn Kunst ein sich ständig veränderndes kulturelles Ausdrucksmittel ist und mit der Zeit geht, warum sollte sie dann nicht auch durch neue Werkzeuge oder gar neue Akteure entstehen? Die zentrale Frage, die sich mir und vielen anderen stellt: Darf etwas als Kunst gelten, das kein fühlender Mensch erschaffen hat?
Zwischen Impulsgeber und Identitätsdiebstahl
Natürlich kann man KI als weiteres kreatives Tool wie Photoshop oder die Kamera sehen. Künstlerinnen oder Künstler geben Prompts ein, wählen aus, verfeinern. Doch generative KI geht weiter: Sie schlägt selbst vor – gelernt von Millionen Bildern und Stilen, ohne Rücksicht auf Grenzen zwischen Inspiration und (urheberrechtsverletzender) Kopie.
Neulich habe ich mit einer Kundin ChatGPT zur Ideenfindung und für das Generieren von Referenzbildern verwendet. Dabei habe ich überraschend inspirierende Impulse erhalten. Ersetzt hat mich das in diesem Fall zwar nicht, aber es hat mir gezeigt, wie viel Zeitersparnis KI bei konzeptioneller Arbeit bringen kann, etwa bei der Suche nach Referenzbildern mit korrekter Perspektive oder gewünschter Lichtführung.
Wenn KI Routineaufgaben und Generisches übernimmt, bleibt mehr Raum für das Echte, Spontane, Spaßige, Unvollkommene – das, was keine Maschine nachbilden kann. Trotzdem habe ich Hemmungen, ihr meine eigenen Werke anzuvertrauen. Ich fürchte, meinen Stil zu verlieren – das, was mich ausmacht. Theoretisch könnte jemand mithilfe weniger Bilder ein Werk in meinem Stil erzeugen, ohne dass ich es je erfahre oder dafür (zumindest mit Anerkennung) entlohnt werde. Ein kostengünstiges, effizientes, aber leeres Echo meiner Arbeit.
Es fehlt das Erlebnis, das Ringen mit der Idee, die Emotionen – das Menschliche. Reicht technische Raffinesse und cleveres Kombinieren, oder braucht es für echte Kunst einen fühlenden Menschen als Schöpfer?
Kann KI fühlen – und muss sie das überhaupt?
Um einen großen Aufschrei zu vermeiden: KI kann nicht fühlen, aber sie imitiert meisterhaft. Für viele lebt Kunst vom Ausdruck, dem Prozess, dem Kontext und der Intention der Kunstschaffenden – nicht nur von Form und Ästhetik. Deshalb beeinflusst der Name der Künstlerin oder des Künstlers den Preis eines Werks oft mehr als die Ausdruckskraft des Bildes. In dieser Hinsicht bleiben KI-Werke oberflächlich und letztlich auch gefühllos.
Allerdings ist diese Ansicht auch das, was Kunst teilweise elitär macht und viele meiner nicht kunstaffinen Freunde abstößt: Weil sie glauben, es gäbe die eine richtige Deutung oder Interpretation, weil abstrakte Werke oft unzugänglich wirken und weil Kunst zu oft in komplizierten Worten statt in echten Gefühlen vermittelt wird.
Auch wenn die Einschätzung eines Bildes mit Kenntnis der Künstlerbiografie vielleicht anders ausfallen würde, darf man dennoch seine eigene Wahrnehmung ernst nehmen und sich einfach fragen: „Was sehe ich? Was fühle ich? Und warum?“
Persönliches Fazit: Kann KI Kunst?
Was KI kann, liegt nicht nur in ihr, sondern auch in dem, was wir in ihr sehen – oder sehen wollen.
Wenn wir Kunst allein als Ergebnis eines kreativen Prozesses betrachten – als Werk mit Ausdruck, Form und Wirkung – dann kann KI Kunst erzeugen. Beeindruckend, effizient und manchmal sogar berührend. Doch sobald wir Kunst als bewusste, intentionale Handlung verstehen – als Ausdruck von Erfahrung, Identität, Haltung – stoßen wir an eine Grenze: KI bietet kein Wollen, kein Fühlen, kein echtes Bewusstsein.
Und trotzdem kann sie Bedeutung erzeugen. Nicht aus sich selbst heraus, sondern durch den Menschen, der mit ihr interagiert. Sie kann nicht begreifen, aber berühren. Keine Absicht haben, aber inspirieren.
Vielleicht liegt genau darin die neue Rolle der Kunst: Nicht in der Frage, ob etwas Kunst ist, sondern im menschlichen Blick darauf, in dem, was wir daraus machen. In Zeiten von KI liegt die Kunst vielleicht nicht mehr nur im bewussten Produzieren, sondern im bewussten Konsumieren: im Erkennen, im Reagieren, im In-Beziehung-Treten. Der Mensch als fühlender, bedeutungsgebender und denkender Bezugspunkt bleibt dann immer noch das Subjekt der Kunst – nicht die Maschine.
(rme)
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
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)
-
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