
Unix-Endpoint-Erkennungs- und -Reaktionslösung, die kernelbasierte Mechanismen nutzt, um Anomalien und Malware-Angriffe in Echtzeit zu erkennen.

MalDec-EDR ist eine Unix-Systemlösung, die Anomalien und Malware-Angriffe mithilfe von Mechanismen auf Kernel-Ebene erkennt. Weitere Informationen finden Sie in der Dokumentation.
Die Standardpraxis besteht darin, die neueste stabile Produktionsversion für Kunden im Haupt- und getaggten Branch verfügbar zu machen. Der Test-Branch dient als Spiegel des Entwicklungs-Branches 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 die Aufgabe der von Ihnen getesteten Komponenten, welche Pfade Sie verwendet haben und wie wir die Tests durchführen können. Erstellen Sie nach Möglichkeit ein Skript, das zeigt, wie die Tests für Ihre Aufgabe funktionieren. Mehr als ein Entwickler kann die Überprüfung durchführen.
Jede Änderung am Code, egal wie klein sie ist, 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 Schutzmaßnahme und stellt sicher, dass unbeabsichtigte Änderungen umgehend identifiziert und behoben werden.
Änderungen sollten von jemand anderem als dem Entwickler, der den Code geschrieben hat, getestet werden. Dies ist besonders wichtig bei großen oder risikoreichen Änderungen. Es ist hilfreich, einen Testplan in die Beschreibung des Pull Requests aufzunehmen, wenn das Testen der Änderungen nicht unkompliziert ist.