mars engineering GmbH • Agile Software Development + Automation

Du hast immer noch keine SBOM? Das ist nun wirklich ein No-Brainer, um CRA-compliant zu werden ... Ich kenne eigentlich keine einzige Software mehr, die nicht in irgendeiner Form vom Cyber Resilience Act betroffen ist. Egal, wie die vorgeschriebene Risikobewertung ausfällt, ist es immer ratsam, eine SBOM zu erstellen. Das macht man ja auch nicht mehr per Hand, sondern dafür gibt es Tools. Weil die Komplexität seiner Software hat man manuell eh nicht mehr im Griff! Mit Tools wie Trivy kann man alle Abhängigkeiten auf Sicherheitslücken monitoren, und wenn man das in seine Build-Chain integriert, hat man immer eine aktuelle Sicht auf bekannte Lücken in den benutzten Libraries. Oder blickst du noch durch, welche C-Libraries du in der Firmware hast und welche Node.js-Bibliotheken in dem Webfrontend benutzt werden und welche Sicherheitslücken es da im Moment gibt? Gerade bei Firmware muss man allerdings prüfen, ob die Tools auch wirklich alle eingebundenen Libraries erfassen. Bei uns wird alles automatisiert geprüft. Sicherheitspatches landen automatisiert auf unserem Deployment-Server, wo der Kunde sie runterladen kann, nachdem alle Tests grün sind. Wenn du das bei euch auch so aufsetzen willst, helfe ich dir gerne. Von der SBOM über die automatisierten Prüfungen bis zur Bereitstellung der Sicherheitspatches. Schreib mir einfach eine DM oder hol dir einen Termin: https://lnkd.in/evUm8MJb

Ich empfehle dir, den CRA ordentlich umzusetzen. Unabhängig von der Produktkategorie. Sonst könnte dein Geschäftsmodell dank KI bald erledigt sein. Momentan macht es auf YouTube die Runde: Leute reverse-engineeren Software mit KI. Im Moment sind es eher Spiele. Aber wer bisher gedacht hat, zur Absicherung von Firmware reicht es, den Debug-Connector nicht zu bestücken, sollte sich eines merken: Auch Hacker besitzen einen Lötkolben! Wenn jemand deine Firmware aus einem Updatepaket oder direkt aus dem Steuergerät auslesen kann, kann er sie auch reverse-engineeren. Da stecken deine Algorithmen drin. Deine Erfahrung. Jahre an Entwicklungsarbeit. Wenn du sie nicht schützt, machst du es anderen leicht, genau diese Arbeit als Vorlage für ihr eigenes Produkt zu nutzen. Und wenn deine Firmware erst einmal im Netz liegt, bekommst du sie da nicht mehr zurück. Da würde ich schon überlegen, wer die einfach auslesen darf. Also: - Firmware-Updates verschlüsseln. - Debug- und Diagnosezugänge absichern. - Den Ausleseschutz der Hardware nutzen. - Schlüssel vernünftig schützen. - Mit Signaturen und Secure Boot verhindern, dass manipulierte Firmware ausgeführt wird. Der CRA ist hier nicht nur Bürokratie, sondern verpflichtet dich, Cybersecurity systematisch in deiner Entwicklung zu berücksichtigen. Das ist ein ziemlich guter Anlass, die eigene Sicherheitsarchitektur endlich ordentlich aufzustellen. Und zu prüfen, ob die Schutzmaßnahmen tatsächlich umgesetzt und getestet sind. Wir bieten dafür einen CRA-Prozesscheck an: In einer Woche bewerten wir euren Entwicklungsprozess anhand eines ausgewählten Produkts. Du bekommst eine Bewertung, priorisierte Lücken und konkrete nächste Schritte. Wenn du hierzu mehr Infos möchtest, schreib mir eine DM oder schau hier: https://lnkd.in/eVde3xbE

Weniger Safety-Hardware? Dann sollte eure Softwarearchitektur mehr können als gut aussehen. Sonst bestimmt am Ende euer Dashboard, wann die Maschine stehen bleibt. Bosch Rexroth hat eine Safety PLC App vorgestellt. Sicherheitsfunktionen sollen direkt auf dem Multicore-Prozessor der Standardsteuerung laufen. Ohne zusätzliche Steuerungshardware. Keine Rocket Science. Machen wir in Steuergeräten in der Automobilbranche schon länger. Spart Hardware, Platz und Kosten. Gut nachvollziehbar. Aber was passiert, wenn die App fürs Dashboard die CPU auslastet? Fremden Speicher überschreibt? Oder eine gemeinsame Schnittstelle mit Daten zumüllt? Eure Safety-Funktion muss trotzdem rechtzeitig reagieren können. Oder das System rechtzeitig in einen sicheren Zustand kommen. Ihr müsst also nachweisen, dass die anderen Anwendungen eure Safety-Anteile nicht unzulässig beeinflussen. Freedom from Interference lässt grüßen. Ich mache bei meinen aktuellen Kunden eigentlich nur noch das: Safety-Architektur designen und implementieren. Und genau deshalb finde ich es immer erschreckend, wenn Architektur-Doku erst am Schluss zusammengefrickelt wird. Wie soll die Architektur eure Safety absichern, wenn sie erst beschrieben wird, nachdem schon alles implementiert ist? Das muss von Anfang an in den Entwicklungsprozess mit rein. Sonst wird die eingesparte Hardware durch die Nacharbeit an der Software schnell wieder teuer. Wenn du dabei Unterstützung brauchst: Schreib mir eine Nachricht oder trag dich hier für einen Termin ein: https://lnkd.in/euhHPuRM Wie läuft das bei euch: Wird die Architektur vor der Software gemacht oder hinterher passend gemalt?

Ich hab keine Lust mehr auf IT und Softwareentwicklung und geb auf. Ich werde jetzt Förster. Oder irgendwas anderes ohne Menschen. Gestern saß ich in einem Meeting bei einem Partner. Eigentlich nur als stiller Zuhörer, um mal zu schauen, was die mit KI und Softwareentwicklung treiben. Die Leute kommen aus der IT-Systemintegration. Softwareentwicklung in großen Teams war bisher eher nicht ihr Thema. Jetzt sollen mehrere Teams mit noch mehr Coding Agents gemeinsam Software entwickeln. Was soll da schon schiefgehen? Ich kenne die Leute seit über 15 Jahren. Ungefähr so lange mache ich auch schon Softwareentwicklung in großen Projekten mit vielen Leuten und Abhängigkeiten. Ich dachte eigentlich, das wissen die. Mich vorher mal zu fragen, wie man sowas aufzieht, war aber offensichtlich nicht nötig. Man hat jetzt schließlich Claude. Und wenn der Agent nicht macht, was man will, braucht man vermutlich einfach einen längeren Prompt. Oder noch einen Agent. Blöd nur, wenn fünf Teams mit ihren Agents in fünf verschiedene Richtungen entwickeln. Dann habt ihr hinterher zwar viel Code. Aber noch lange keine funktionierende Software. Wer legt fest, wie das System aufgeteilt wird? Wer definiert die Schnittstellen? Wer entscheidet, wenn zwei Teams unterschiedliche Vorstellungen haben? Und wer merkt, dass ein Agent gerade etwas "verbessert" hat, worauf drei andere Teams aufbauen? Das klärt sich nicht dadurch, dass alle besonders motiviert drauflos prompten. Auch eine Sammlung guter Agent-Skills ersetzt keinen gemeinsamen Entwicklungsprozess. Hier braucht ihr den "Senior Software Developer Skill". Den könnt ihr allerdings nicht als Markdown-Datei runterladen. Der kommt persönlich vorbei und fragt erst mal, was ihr eigentlich vorhabt. Der legt mit euch fest, wer welchen Teil übernimmt, wie Änderungen abgestimmt werden und wie ihr regelmäßig prüft, ob das Ganze zusammen funktioniert. Klingt weniger geil als ein autonomes Agent-Netzwerk. Ist aber ziemlich hilfreich, wenn am Ende mehr rauskommen soll als eine beeindruckende Anzahl geänderter Dateien. Die Probleme sind nämlich nicht neu. Unklare Zuständigkeiten, kaputte Schnittstellen und Teams, die aneinander vorbeientwickeln, konnten wir vorher auch schon. Dafür brauchten wir noch nicht mal KI. Jetzt können wir das Chaos halt deutlich schneller produzieren. Ich finde es voll gut, dass Softwareentwicklung für mehr Menschen zugänglich wird. Für viele kleine Anpassungen und eigene Tools war die Einstiegshürde bisher einfach zu hoch. Aber wer bisher keine großen Softwareprojekte entwickeln konnte, kann es nicht plötzlich, nur weil sein Agent jetzt schneller tippt. Holt euch jemanden dazu, der das täglich macht. Am Besten bevor fünf Teams ihren jeweiligen Teil für fertig erklären und keiner das Gesamtsystem zum Laufen bekommt. Falls ihr gerade an dem Punkt seid: Redet doch einfach mal mit mir. Noch bin ich nicht im Wald.

Die KI hat deine PDFs mit den Inhaltsstoffen zusammengefasst. Schön. Aber darfst du das Material jetzt verwenden oder nicht? Für einen Verpackungshersteller habe ich deshalb ein KI-Tool entwickelt, welches die PPWR-Konformität seiner Materialien bewertet und damit genau diese Frage geklärt. Mehrere PDFs rein. Substanzen und weitere Vorgaben der Regulierung prüfen. Am Schluss kommt die Konformitätserklärung raus. Oder ein Bericht, was nicht passt oder noch fehlt. Das Ganze läuft lokal. Auf einem kleinen Modell, das man auch selbst mit einer 16-GB-Grafikkarte hosten kann. Etwas tricksen musste ich trotzdem. Trotz JSON-Schema kamen Ausgaben zurück, die nicht zum vorgegebenen Format oder den erlaubten Werten gepasst haben. Ausgabe prüfen. Fehler zurück ans LLM. Noch ein Versuch. Deshalb nutze ich hier nun eine EBNF-Grammatik statt eines JSON-Schemas. Damit bekomme ich bei unserem kleinen Modell auch die speziellen Format- und Wertevorgaben direkt bei der Generierung besser in den Griff. So spare ich mir die ständigen Korrekturschleifen und einen Prompt, der irgendwann mehr Ausnahmebehandlung als eigentliche Aufgabe enthält. Fachlichen Blödsinn verhindert die Grammatik natürlich nicht. Das letzte Wort hat der Mensch. Aber der kann sich mit den kritischen Stellen beschäftigen, statt Informationen aus PDFs zusammenzusuchen und kaputte Ausgaben zu reparieren. Welche Dokumente müsst ihr regelmäßig gegen Anforderungen prüfen?

Du willst Entwickler durch KI ersetzen? Hoffentlich weißt du, was die den ganzen Tag machen. Wenn du glaubst, die sind Code-Monkeys und übersetzen nur Tickets in Code, sieht die Rechnung natürlich geil aus. Das kann die KI inzwischen ziemlich gut und auch ich nutze sie zum Coden, Enterprise Architect automatisieren, auf Hardware debuggen, … und bin damit deutlich schneller. Aber die KI merkt halt nicht, wenn eine Anforderung kompletter Blödsinn ist oder eine Schnittstelle falsch spezifiziert ist, wenn du ihr nicht vernünftigen Kontext geben kannst. Und sie schaut auch nicht am Prüfstand, warum es beim Kunden knallt, obwohl im Labor alles lief. Wenn man nur auf Commits im Repo fixiert ist, merkt man diese Arbeit gar nicht. Manchmal sitzt ein Entwickler einen halben Tag mit einem Kollegen zusammen und sie machen Pair-Programming und verhindern dabei einen Fehler, der euch sonst wochenlang beschäftigt hätte. In den Statistiken sieht das erstmal nach wenig Leistung aus, wenn da nachher dann nur ein Commit rauskommt und das Ticket vielleicht nicht mal geschlossen wurde. Wenn du genau diese Leute einsparst, bekommst du bestimmt mehr Code pro Tag. Aber kommst du damit auch wirklich schneller voran? Ich würde deshalb vor der kompletten Übergabe an die KI erst mal schauen, wo die Zeit im Projekt tatsächlich hingeht. Wenn dein Team ständig am Anforderungen abklären ist und es zwischen den Teams Integrationsprobleme gibt, musst du erstmal dort ansetzen. Sonst wächst euch euer Prozess nur noch schneller mit KI über den Kopf, als er nutzt. Du willst KI sinnvoll in eure Entwicklung einbauen und euren Prozess dafür fit machen? Schreib mir eine DM oder trag dich hier ein: https://lnkd.in/ecuZJpJR Dann schauen wir gemeinsam, wo sie euch wirklich Arbeit abnimmt.