Secure Coding: Sicherheit geprüft, während der Code entsteht
Das Modul Secure Coding bringt Sicherheit in die tägliche Arbeit der Entwickler, direkt in der IDE, bevor der Code ins Review oder in den Test geht.
1. Was dieses Modul ist
Drei Prüfungen während der Programmierung: verwundbare Pakete im Code, Vollständigkeit der Sicherheitsanforderungen in der Umsetzung und Einhaltung der geforderten Programmierrichtlinie.
2. Warum es nützlich ist
- Verwundbare Komponenten und fehlende Anforderungen lassen sich am günstigsten beheben, während der Code entsteht.
- Der CRA verlangt, dass Produkte ohne bekannte ausnutzbare Schwachstellen in Verkehr gebracht werden.
- IEC 62443-4-1 und ISO/SAE 21434 verlangen sichere Programmierpraktiken und Nachweise dafür.
3. So funktioniert es, kurz erklärt
- Läuft in der IDE der Entwickler.
- Markiert verwundbare Pakete, noch nicht umgesetzte Anforderungen und Abweichungen von der Programmierrichtlinie.
- Jeder Befund verweist auf das betroffene Paket, die Anforderung oder die Richtlinienregel, und die Ergebnisse fließen in das gemeinsame Produktmodell zurück.
4. Wer es nutzt
Softwareentwickler und Entwicklungsleiter.
5. In welchen Branchen
Hersteller mit eigener Software: Maschinenbau und Off-Highway, Industrieautomation, Automobil, Medizintechnik und Energietechnik.
Verbunden mit
Vorher: Bedrohungsmodellierung und Konzeptdesign. Danach: Tests. Alle Module teilen ein gemeinsames Produktmodell.
Im Detail: Secure Coding
Warum Sicherheitsprüfungen beim Programmieren wichtig sind, wo sie verlangt werden, welche Probleme sie verhindern und wie hoch der Aufwand ist.
Warum es wichtig ist
Die meisten Schwachstellen gelangen beim Programmieren in ein Produkt: über veraltete Open-Source-Pakete, über Sicherheitsanforderungen, die nie umgesetzt wurden, und über Abweichungen von der Programmierrichtlinie. In dieser Phase lassen sie sich am günstigsten beheben, weil noch niemand darauf aufgebaut hat.
Wo es verlangt wird
Der Cyber Resilience Act verlangt, dass Produkte ohne bekannte ausnutzbare Schwachstellen in Verkehr gebracht werden. IEC 62443-4-1 verlangt Praktiken für eine sichere Implementierung, ISO/SAE 21434 den Nachweis, dass die Cybersecurity-Anforderungen umgesetzt sind, und eingebettete Projekte folgen meist einer Programmierrichtlinie wie MISRA oder CERT C.
Welche Probleme es verhindert
Ein Produkt, das mit einer bekannten verwundbaren Bibliothek ausgeliefert wird. Sicherheitsanforderungen, die auf dem Papier stehen, aber nicht im Code. Und Befunde in späten Penetrationstests oder Audits, die kurz vor dem Release Nacharbeit erzwingen.
Typischer Aufwand ohne Werkzeug
Ohne Prüfungen im täglichen Arbeitsablauf fallen diese Probleme erst spät auf, in separaten Scans, Reviews oder Tests. Sie dann zu beheben heißt, in fertigen Code zurückzugehen, erneut zu testen und manchmal das Release zu verschieben.
Mit AITIGRITY
Die Prüfungen laufen in der IDE der Entwickler, während der Code entsteht. Verwundbare Pakete, fehlende Anforderungen und Abweichungen von der Richtlinie werden mit dem betroffenen Paket, der Anforderung oder der Regel markiert, und die Ergebnisse fließen in das gemeinsame Produktmodell zurück. So wächst der Nachweis für das Audit mit dem Code.
Wo steht Ihr Produkt?
Erzählen Sie uns von Ihrem Produkt und den Vorgaben, die Sie erfüllen müssen. Sie sprechen vom ersten Gespräch an mit einem Ingenieur.
Cybersecurity-Beratung und die Plattform AITIGRITY für vernetzte Produkte und industrielle Systeme.