
Solution de détection et de réponse sur les terminaux Unix utilisant des mécanismes au niveau du noyau pour détecter les anomalies et les attaques de malwares en temps réel.

MalDec-EDR est une solution pour systèmes Unix conçue pour détecter les anomalies et les attaques de malwares à l'aide de mécanismes au niveau du noyau. Pour plus d'informations, veuillez consulter la Documentation.
La pratique standard consiste à mettre à disposition des clients la dernière version de production stable dans la branche main et taguée. La branche test sert de miroir à la branche de développement, en la soumettant à une batterie de tests et de processus d'assurance qualité (QA). Pendant ce temps, la branche de développement (dev) est dédiée au développement continu du projet, aux améliorations et aux ajustements.
+-----------+
| feature1 |
+-----------+
|
+-----------+
| feature3 |
+-----------+
|
+-----------+
| feature2 |
+-----------+
|
+-----------+ +-----------+ +-----------+
| dev | ---> | test | ---> | main |
+-----------+ +-----------+ +-----------+
|
+--------------------------+
| | |
+-----+ +-----+ +-----+
|1.0.0| |2.0.0| | ... |
+-----+ +-----+ +-----+
Vous devez tester tous les composants de MalDec-EDR, si possible détaillez la tâche des composants que vous avez testés, les chemins que vous avez empruntés et comment nous pouvons effectuer les tests, si possible créez un script expliquant comment fonctionnent les tests pour votre tâche, plus d'un développeur peut réaliser la revue.
Chaque modification du code, aussi minime soit-elle, devrait idéalement être accompagnée de tests unitaires approfondis. Cette pratique est cruciale pour détecter les erreurs potentielles introduites par d'autres développeurs. La présence de tests unitaires sert de garde-fou, garantissant que toute modification involontaire est rapidement identifiée et traitée.
Les modifications doivent être testées par une personne autre que le développeur qui a écrit le code. Cela est particulièrement important pour les modifications importantes ou à haut risque. Il est utile d'ajouter un plan de test à la description de la pull request si le test des modifications n'est pas simple.