Trail of Bits Testing Handbook

El Trail of Bits Testing Handbook es un recurso para desarrolladores y profesionales de la seguridad sobre cómo configurar, optimizar y automatizar muchas de las herramientas de análisis estático y dinámico que utilizamos en Trail of Bits.

Vista previa del Testing Handbook: https://appsec.guide 🌐

¿Por qué es necesario? ✨

• 📃 La documentación para configurar y optimizar las herramientas existentes a menudo no es amigable para los desarrolladores, ya que suele estar pensada para profesionales de la seguridad. Esto es especialmente cierto en el caso de las utilidades de fuzzing. Esto puede provocar frustración y una mala adopción de herramientas de seguridad que deberían ser sencillas de configurar.
• ⚙️ Incluso si la herramienta es fácil de configurar localmente, puede ser difícil configurarla en pipelines de CI/CD. A menudo, las herramientas de seguridad se configuran siguiendo la documentación en línea, pero su configuración rara vez está optimizada. Esto puede dar lugar a una herramienta ruidosa que resulta más difícil de mantener de lo que vale.
• 🧠 Nuestro objetivo es que sea lo más fácil posible configurar herramientas de seguridad de forma eficaz. Al hacerlo, también esperamos desmitificar técnicas de análisis estático y dinámico como el fuzzing y el análisis de taint.

Capítulos

✅ Publicados

🎥 Seminarios web

🚧 En construcción

• kAFL
• Rust
• Verificación formal y Tamarin

Cómo contribuir

Si deseas contribuir al Testing Handbook, aquí tienes algunas pautas para ayudarte a empezar:

1. Añadir una nueva herramienta: Si quieres cubrir una nueva herramienta en el Testing Handbook, propón un tema en GitHub Issues. Después, puedes trabajar en una nueva pull request.
2. Mejorar capítulos existentes: Si tienes una idea para mejorar un capítulo concreto, puedes crear un issue en GitHub.
3. Asumir tareas pequeñas: Si no tienes mucho tiempo pero aun así quieres contribuir, puedes tomar cualquier tarea pequeña de la lista de issues de GitHub.
4. Reportar problemas: Si encuentras un pequeño problema técnico o un error tipográfico, crea un nuevo issue en GitHub y/o corrígelo en la nueva pull request.

Configuración rápida para un desarrollo cómodo

1. Instala Hugo en tu sistema

   root@kitploit:~

   brew install hugo
   

2. Clona el repositorio

   root@kitploit:~

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

3. Crea una nueva rama o selecciona una rama en la que quieras trabajar

   root@kitploit:~

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

4. Ejecuta el servidor de Hugo con los borradores activados (-D) desde el directorio raíz del proyecto. Tu navegador se actualizará automáticamente con los cambios cada vez que guardes un archivo.

   root@kitploit:~

   hugo server -D
   

5. Añade una nueva herramienta como "doc" y ejecuta lo siguiente desde el directorio raíz del proyecto.

   root@kitploit:~

   hugo new docs/<name of tool>
   

   Nota: Este proyecto utiliza la misma plantilla de Hugo que zkdocs. La plantilla se refiere a cada página nueva como un "doc", a diferencia de una publicación. Por eso querrás escribir hugo new docs/<name of tool> y no post/my-new-post.

Pautas

• El formato debe ser coherente entre cada "doc". Al añadir un nuevo doc (es decir, al agregar una nueva herramienta), sigue la plantilla en content/docs/template.md. Envía un PR para este archivo con los cambios sugeridos según sea necesario.

• Crea una nueva rama con tus cambios y crea un PR para fusionar en main cuando hayas terminado.

• El flujo de trabajo de GitHub en este repositorio verifica la corrección de los archivos Markdown mediante tres comprobaciones:

  1. Comprobación de enlaces Markdown: Este paso extrae los enlaces de los archivos Markdown y verifica que sean válidos y accesibles. Utiliza la acción de comprobación de enlaces lychee.
  2. Linter de Markdown: Este paso garantiza que los archivos Markdown cumplan con el estilo y las reglas de formato deseadas. Utiliza un archivo de configuración personalizado (.github/workflows/.markdownlint.jsonc) y la markdownlint-cli2-action acción. Usa la extensión markdownlint con Visual Studio Code para una mejor experiencia de usuario al trabajar en el Testing Handbook.
  3. Corrector ortográfico: Este paso revisa la ortografía en los archivos Markdown (construido sobre retext y remark). Utiliza la acción tbroadley/spellchecker-cli-action.

• Familiarízate con el tema Hugo Book, ya que tiene un par de funciones interesantes (botones, etc.).

• Contacta con nosotros en #testing-handbook de Empire Hacking Slack si tienes alguna pregunta.

Edición

Pautas de redacción

• El término "Testing Handbook" debe escribirse en mayúsculas cada vez que aparezca en el sitio web (ya sea en un encabezado o subtítulo, o en el texto corrido), ya que es el título de un documento. Pero si prefieres evitar las mayúsculas porque se ven extrañas, puedes sustituir "Testing Handbook" por "este manual" (ya que queda bastante claro cuál es el título del manual).

Flujo de trabajo: desde Google Docs

Puedes exportar el documento desde Google Docs como Markdown. Abre el documento en Google Docs. Haz clic en File > Download y luego selecciona Markdown (.md).

Entornos personalizados

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

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

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