Guide de test de Trail of Bits

Le Guide de test de Trail of Bits est une ressource destinée aux développeurs et aux professionnels de la sécurité pour configurer, optimiser et automatiser de nombreux outils d'analyse statique et dynamique que nous utilisons chez Trail of Bits.

Aperçu du Guide de test : https://appsec.guide 🌐

Pourquoi est-ce nécessaire ? ✨

• 📃 La documentation pour configurer et optimiser les outils existants est souvent peu adaptée aux développeurs, car elle est souvent destinée aux professionnels de la sécurité. C'est particulièrement le cas pour les utilitaires de fuzzing. Cela peut entraîner de la frustration et une mauvaise adoption d'outils de sécurité qui devraient être simples à configurer.
• ⚙️ Même si l'outil est facile à configurer localement, il peut être difficile de le configurer dans les pipelines CI/CD. Souvent, les outils de sécurité sont installés en suivant une documentation en ligne, mais leur configuration est rarement optimisée. Cela peut conduire à un outil bruyant et plus difficile à maintenir qu'il ne vaut la peine.
• 🧠 Nous visons à rendre la mise en place efficace d'outils de sécurité aussi simple que possible. Ce faisant, nous espérons également démystifier les techniques d'analyse statique et dynamique telles que le fuzzing et l'analyse de flot de données (taint analysis).

Chapitres

✅ Publiés

🎥 Webinaires

🚧 En cours de construction

• kAFL
• Rust
• Formal verification and Tamarin

Comment contribuer

Si vous souhaitez contribuer au Guide de test, voici quelques directives pour vous aider à démarrer :

1. Ajouter un nouvel outil : Si vous souhaitez couvrir un nouvel outil dans le Guide de test, proposez un sujet dans GitHub Issues. Ensuite, vous pouvez travailler sur une nouvelle pull request.
2. Améliorer les chapitres existants : Si vous avez une idée pour améliorer un chapitre spécifique, vous pouvez ajouter une issue GitHub.
3. Prendre en charge de petites tâches : Si vous n'avez pas beaucoup de temps mais souhaitez tout de même contribuer, vous pouvez choisir une petite tâche dans la liste des issues GitHub.
4. Signaler des problèmes : Si vous trouvez un petit problème technique ou une faute de frappe, créez une nouvelle issue GitHub et/ou corrigez-la dans une nouvelle pull request.

Configuration rapide pour un développement pratique

1. Installez Hugo sur votre système

   root@kitploit:~

   brew install hugo
   

2. Clonez le dépôt

   root@kitploit:~

   git clone --recurse-submodules https://github.com/trailofbits/testing-handbook.git
   

3. Créez une nouvelle branche ou sélectionnez une branche sur laquelle vous souhaitez travailler

   root@kitploit:~

   cd testing-handbook
   # then
   git checkout -b name-of-your-new-branch
   # or
   git checkout name-of-existing-branch
   

4. Exécutez le serveur Hugo avec les brouillons activés (-D) depuis le répertoire racine du projet. Votre navigateur sera automatiquement actualisé avec les modifications chaque fois que vous enregistrez un fichier.

   root@kitploit:~

   hugo server -D
   

5. Ajoutez un nouvel outil en tant que « doc », et exécutez la commande suivante depuis le répertoire racine du projet.

   root@kitploit:~

   hugo new docs/<name of tool>
   

   Remarque : Ce projet utilise le même template Hugo que zkdocs. Le template désigne chaque nouvelle page comme une « doc », par opposition à un article. C'est pourquoi vous voudrez taper hugo new docs/<nom de l'outil> et non post/my-new-post.

Directives

• Le format doit être cohérent entre chaque « doc ». Lors de l'ajout d'une nouvelle doc (c'est-à-dire lors de l'ajout d'un nouvel outil), suivez le modèle dans content/docs/template.md. Envoyez une PR pour ce fichier avec les modifications suggérées si nécessaire.

• Créez une nouvelle branche avec vos modifications, et créez une PR pour fusionner dans main lorsque vous avez terminé.

• Le workflow GitHub de ce dépôt vérifie l'exactitude des fichiers Markdown via trois vérifications :

  1. Vérification des liens Markdown : Cette étape extrait les liens des fichiers Markdown et vérifie s'ils sont valides et accessibles. Elle utilise l'action de vérification de liens lychee.
  2. Linter Markdown : Cette étape garantit que les fichiers Markdown respectent les règles de style et de formatage souhaitées. Elle utilise un fichier de configuration personnalisé (.github/workflows/.markdownlint.jsonc) et l'action markdownlint-cli2-action. Utilisez l'extension markdownlint avec Visual Studio Code pour une meilleure expérience utilisateur lors du travail sur le Guide de test.
  3. Vérification orthographique : Cette étape vérifie l'orthographe dans les fichiers Markdown (basée sur retext et remark). Utilise l'action tbroadley/spellchecker-cli-action.

• Familiarisez-vous avec le thème Hugo Book car il possède quelques fonctionnalités intéressantes (boutons, etc.)

• Contactez-nous sur #testing-handbook sur Slack Empire Hacking si vous avez des questions.

Édition

Règles de rédaction

• Le terme « Guide de test » doit être capitalisé chaque fois qu'il apparaît sur le site web (que ce soit dans un en-tête/sous-en-tête ou dans le texte courant), car il s'agit du titre d'un document. Mais si vous souhaitez éviter la capitalisation parce qu'elle semble étrange, vous pouvez remplacer « Guide de test » par « ce guide » (car le titre du guide est suffisamment clair).

Workflow : Depuis Google Docs

Vous pouvez exporter le document depuis Google Docs au format Markdown. Ouvrez le document dans Google Docs. Cliquez sur Fichier > Télécharger, puis sélectionnez Markdown (.md).

Environnements personnalisés

{{< customFigure "Caption" >}}
{{< /customFigure >}}

{{< resourceFigure "cov1.png" >}}
{{< /resourceFigure >}}

{{< hint info >}}
{{< /hint >}}