Manual de Testes da Trail of Bits

O Manual de Testes da Trail of Bits é um recurso para desenvolvedores e profissionais de segurança sobre como configurar, otimizar e automatizar muitas ferramentas de análise estática e dinâmica que usamos na Trail of Bits.

Pré-visualizar Manual de Testes: https://appsec.guide 🌐

Por que isso é necessário? ✨

• 📃 A documentação para configurar e otimizar ferramentas existentes geralmente não é amigável para desenvolvedores, pois muitas vezes é voltada para profissionais de segurança. Isso é especialmente verdadeiro quando se trata de utilitários de fuzzing. Isso pode levar à frustração e à baixa adoção de ferramentas de segurança que deveriam ser simples de configurar.
• ⚙️ Mesmo que a ferramenta seja fácil de configurar localmente, pode ser difícil configurá-la em pipelines de CI/CD. Frequentemente, as ferramentas de segurança são configuradas seguindo documentações online, mas sua configuração raramente é otimizada. Isso pode levar a uma ferramenta ruidosa que é mais difícil de manter do que vale a pena.
• 🧠 Nosso objetivo é tornar a configuração de ferramentas de segurança o mais fácil possível, de forma eficaz. Ao fazer isso, também esperamos desmistificar técnicas de análise estática e dinâmica, como fuzzing e análise de taint.

Capítulos

✅ Lançados

🎥 Webinars

🚧 Em construção

• kAFL
• Rust
• Verificação formal e Tamarin

Como contribuir

Se você deseja contribuir com o Manual de Testes, aqui estão algumas diretrizes para ajudar você a começar:

1. Adicionar uma Nova Ferramenta: Se você deseja cobrir uma nova ferramenta no Manual de Testes, proponha um tópico nas Issues do GitHub. Depois, você pode trabalhar em um novo pull request.
2. Melhorar Capítulos Existentes: Se você tem uma ideia para melhorar um capítulo específico, pode adicionar uma issue no GitHub.
3. Pegar Tarefas Pequenas: Se você não tem muito tempo mas ainda quer contribuir, pode pegar qualquer tarefa pequena da lista de issues do GitHub.
4. Reportar Problemas: Se você encontrar um pequeno problema técnico ou um erro de digitação, crie uma nova issue no GitHub e/ou corrija no novo pull request.

Configuração rápida para desenvolvimento conveniente

1. Instale o Hugo no seu sistema

   root@kitploit:~

   brew install hugo
   

2. Clone o repositório

   root@kitploit:~

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

3. Crie um novo branch ou selecione um branch no qual deseja trabalhar

   root@kitploit:~

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

4. Execute o servidor Hugo com a opção de rascunhos ativada (-D) a partir do diretório raiz do projeto. Seu navegador será atualizado automaticamente com as alterações sempre que você salvar um arquivo.

   root@kitploit:~

   hugo server -D
   

5. Adicione uma nova ferramenta como "doc" e execute o seguinte a partir do diretório raiz do projeto.

   root@kitploit:~

   hugo new docs/<name of tool>
   

   Nota: Este projeto usa o mesmo template Hugo do zkdocs. O template se refere a cada nova página como "doc", ao contrário de post. É por isso que você deve digitar hugo new docs/<name of tool> e não post/my-new-post.

Diretrizes

• O formato deve ser consistente em cada "doc". Ao adicionar um novo doc (ou seja, ao adicionar uma nova ferramenta), siga o modelo em content/docs/template.md. Envie um PR para este arquivo com alterações sugeridas conforme necessário.

• Crie um novo branch com suas alterações e crie um PR para mesclar no main quando terminar.

• O workflow do GitHub neste repositório verifica a correção dos arquivos Markdown através de três verificações:

  1. Verificação de Links Markdown: Esta etapa extrai links de arquivos Markdown e verifica se são válidos e acessíveis. Utiliza a lychee link checking action.
  2. Linter Markdown: Esta etapa garante que os arquivos Markdown sigam o estilo e as regras de formatação desejados. Utiliza um arquivo de configuração personalizado (.github/workflows/.markdownlint.jsonc) e a ação markdownlint-cli2-action. Use a extensão markdownlint com o Visual Studio Code para uma melhor experiência de usuário ao trabalhar no Manual de Testes.
  3. Verificação Ortográfica: Esta etapa verifica a ortografia em arquivos Markdown (construída sobre retext e remark). Utiliza a ação tbroadley/spellchecker-cli-action.

• Familiarize-se com o tema Hugo Book pois ele tem alguns recursos interessantes (botões, etc.)

• Entre em contato no #testing-handbook Empire Hacking Slack se você tiver alguma dúvida.

Edição

Diretrizes de Escrita

• O termo "Manual de Testes" deve ser capitalizado sempre que aparecer no site (seja em cabeçalho/subcabeçalho ou texto corrido), pois é o título de um documento. Mas se você quiser evitar a capitalização porque parece estranho, pode substituir "Manual de Testes" por "este manual" (já que está claro o título do manual).

Fluxo de Trabalho: A partir do Google Docs

Você pode exportar o documento do Google Docs como Markdown. Abra o documento no Google Docs. Clique em File > Download e depois selecione Markdown (.md).

Ambientes personalizados

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

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

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