gmh5225/crowarmorLinux-Kernel-Sicherheitstreiber, der LSM nutzt, um das System zu härten, die Integrität der Syscall-Tabelle zu überwachen und wiederherzustellen sowie CPU-Steuerregister vor Manipulation zu schützen.
CrowArmor ist ein Treiber für Linux, der auf Systemsicherheit abzielt. Wir nutzen LSM-Schnittstellen, um die Kernel-Sicherheit zu verbessern, und bieten Unterstützung für MalDec-EDR. Codedokumentation und Anleitung zur Installation finden Sie in der Dokumentation.
Die Standardpraxis besteht darin, die neueste stabile Produktionsversion für Kunden im Haupt- und im getaggten Branch verfügbar zu haben. Der Test-Branch dient als Spiegel des Entwicklungs-Branchs und wird einer Reihe von Tests und Qualitätssicherungsprozessen (QA) unterzogen. Der Entwicklungs-Branch (dev) ist hingegen der laufenden Projektentwicklung, Verbesserungen und Anpassungen gewidmet.
+-----------+
| feature1 |
+-----------+
|
+-----------+
| feature3 |
+-----------+
|
+-----------+
| feature2 |
+-----------+
|
+-----------+ +-----------+ +-----------+
| dev | ---> | test | ---> | main |
+-----------+ +-----------+ +-----------+
|
+--------------------------+
| | |
+-----+ +-----+ +-----+
|1.0.0| |2.0.0| | ... |
+-----+ +-----+ +-----+
Sie müssen alle Komponenten von MalDec-EDR testen. Beschreiben Sie nach Möglichkeit detailliert die Aufgabe der von Ihnen getesteten Komponenten, welche Pfade Sie gewählt haben und wie wir die Tests durchführen können. Erstellen Sie nach Möglichkeit ein Skript, das die Tests für Ihre Aufgabe veranschaulicht. Mehr als ein Entwickler kann die Überprüfung durchführen.
Jede Änderung am Code, egal wie klein, sollte idealerweise von gründlichen Unit-Tests begleitet werden. Diese Praxis ist entscheidend, um potenzielle Fehler zu erkennen, die von anderen Entwicklern eingeführt wurden. Das Vorhandensein von Unit-Tests dient als Schutz und stellt sicher, dass unbeabsichtigte Änderungen umgehend erkannt und behoben werden.
Änderungen sollten von einer anderen Person getestet werden als von dem Entwickler, der den Code geschrieben hat. Dies ist besonders wichtig bei großen oder risikoreichen Änderungen. Es ist sinnvoll, dem Pull-Request einen Testplan beizufügen, wenn das Testen der Änderungen nicht unkompliziert ist.