Manuale di Testing di Trail of Bits

Il Manuale di Testing di Trail of Bits è una risorsa per sviluppatori e professionisti della sicurezza su come configurare, ottimizzare e automatizzare molti degli strumenti di analisi statica e dinamica che usiamo in Trail of Bits.

Anteprima del Manuale di Testing: https://appsec.guide 🌐

Perché serve? ✨

• 📃 La documentazione per configurare e ottimizzare gli strumenti esistenti spesso non è pensata per gli sviluppatori, dato che è solitamente rivolta ai professionisti della sicurezza. Questo vale soprattutto per le utility di fuzzing. Ciò può portare a frustrazione e a una scarsa adozione di strumenti di sicurezza che dovrebbero essere semplici da configurare.
• ⚙️ Anche se lo strumento è facile da configurare in locale, può essere difficile configurarlo nelle pipeline CI/CD. Spesso gli strumenti di sicurezza vengono impostati seguendo la documentazione online, ma la loro configurazione è raramente ottimizzata. Questo può portare a uno strumento rumoroso, più difficile da mantenere di quanto ne valga la pena.
• 🧠 Puntiamo a rendere il più semplice possibile la configurazione efficace degli strumenti di sicurezza. In questo modo, speriamo anche di demistificare tecniche di analisi statica e dinamica come il fuzzing e la taint analysis.

Capitoli

✅ Pubblicati

🎥 Webinar

🚧 In costruzione

• kAFL
• Rust
• Verifica formale e Tamarin

Come contribuire

Se desideri contribuire al Testing Handbook, ecco alcune linee guida per iniziare:

1. Aggiungere un Nuovo Strumento: Se vuoi trattare un nuovo strumento nel Testing Handbook, proponi un argomento nelle GitHub Issues. In seguito, puoi lavorare a una nuova pull request.
2. Migliorare i Capitoli Esistenti: Se hai un'idea per migliorare un capitolo specifico, puoi aprire una issue su GitHub.
3. Svolgere Piccole Attività: Se non hai molto tempo ma vuoi comunque contribuire, puoi svolgere qualsiasi piccola attività dall'elenco delle issue su GitHub.
4. Segnalare Problemi: Se trovi un piccolo problema tecnico o un refuso, crea una nuova issue su GitHub e/o correggila nella nuova pull request.

Configurazione rapida per uno sviluppo comodo

1. Installa Hugo sul tuo sistema

   root@kitploit:~

   brew install hugo
   

2. Clona il repository

   root@kitploit:~

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

3. Crea un nuovo branch o seleziona un branch su cui vuoi lavorare

   root@kitploit:~

   cd testing-handbook
   # poi
   git checkout -b nome-del-tuo-nuovo-branch
   # oppure
   git checkout nome-del-branch-esistente
   

4. Esegui il server Hugo con le bozze attivate (-D) dalla directory principale del progetto. Il tuo browser verrà aggiornato automaticamente a ogni salvataggio di un file.

   root@kitploit:~

   hugo server -D
   

5. Aggiungi un nuovo strumento come "doc" ed esegui il comando seguente dalla directory principale del progetto.

   root@kitploit:~

   hugo new docs/<nome dello strumento>
   

   Nota: Questo progetto usa lo stesso template Hugo di zkdocs. Il template si riferisce a ogni nuova pagina come "doc", a differenza di un post. Ecco perché devi digitare hugo new docs/<nome dello strumento> e non post/my-new-post.

Linee guida

• Il formato deve essere coerente tra ogni "doc". Quando aggiungi una nuova doc (cioè quando aggiungi un nuovo strumento), segui il template in content/docs/template.md. Invia una PR per questo file con le modifiche suggerite, se necessario.

• Crea un nuovo branch con le tue modifiche e crea una PR per unire in main quando hai finito.

• Il workflow GitHub in questo repository verifica la correttezza dei file Markdown tramite tre controlli:

  1. Controllo dei link Markdown: Questo passaggio estrae i link dai file Markdown e verifica che siano validi e accessibili. Usa l'azione di controllo link lychee.
  2. Linter Markdown: Questo passaggio garantisce che i file Markdown rispettino lo stile e le regole di formattazione desiderate. Usa un file di configurazione personalizzato (.github/workflows/.markdownlint.jsonc) e l'azione markdownlint-cli2-action. Usa l'estensione markdownlint con Visual Studio Code per un'esperienza migliore mentre lavori sul Testing Handbook.
  3. Controllo ortografico: Questo passaggio controlla l'ortografia nei file Markdown (costruito su retext e remark). Usa l'azione tbroadley/spellchecker-cli-action.

• Acquisisci familiarità con il tema Hugo Book dato che ha alcune funzionalità interessanti (pulsanti, ecc.)

• Contattaci su #testing-handbook Slack di Empire Hacking se hai domande.

Modifica

Linee guida di scrittura

• Il termine "Testing Handbook" deve essere capitalizzato ogni volta che compare sul sito web (sia in intestazioni/sottointestazioni sia nel testo corrente), poiché è il titolo di un documento. Ma se preferisci evitare la maiuscola perché sembra strana, puoi sostituire "Testing Handbook" con "questo manuale" (dato che è abbastanza chiaro qual è il titolo del manuale).

Workflow: Da Google Docs

Puoi esportare il documento da Google Docs come Markdown. Apri il documento in Google Docs. Clicca File > Download, quindi seleziona Markdown (.md).

Ambienti personalizzati

{{< customFigure "Didascalia" >}}
{{< /customFigure >}}

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

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