Boa! Faz muito sentido — se só uma pessoa ficar com a parte “técnica” e os outros em funções de apoio, realmente o time desanima rápido. O ideal é que os três sejam técnicos, mas cada um com um foco diferente dentro do ciclo de pesquisa, de forma que todos se sintam igualmente importantes. Além disso, o onboarding precisa ser objetivo, passo a passo e já colocar a pessoa nova em um fluxo claro.
Aqui está uma versão melhorada do onboarding + separação de responsabilidades:
🚀 Onboarding Sunsec Research
- O que é o time?
Comunidade voluntária, focada em pesquisa em AppSec e bug bounty.
Produzimos estudos técnicos, artigos e ferramentas de impacto público.
Trabalhamos sempre com ética: responsible disclosure e transparência.
- Como funcionamos
Pesquisas organizadas em ciclos trimestrais: escolhemos temas, trabalhamos e publicamos.
Usamos GitHub para código e relatórios de pesquisa.
Cada pesquisa vira uma issue ou projeto documentado, com responsável definido.
- Padrões de Contribuição
Código: sempre em repositórios GitHub, com README explicando contexto.
Artigos: em Markdown no repo /research → depois publicados no blog.
Divulgação: posts internos revisados por outro membro antes de publicar.
Naming padrão para commits, issues e pastas (ex.: jwt-parser-rce-2025).
-
Primeiro passo do novo membro
-
Entrar nos canais (Discord/Telegram).
-
Ler o guia de ética e os padrões de contribuição.
-
Escolher uma pesquisa em aberto OU propor um tema.
-
Abrir uma issue no GitHub descrevendo sua ideia.
-
Começar com pequenas tarefas (ex.: revisar um código, escrever parte de um artigo).
👥 Estrutura dos 3 Membros Principais
Todos são técnicos, mas cada um tem uma ênfase distinta:
Membro A — Caçador de Bugs / Offensive Research
Foco em exploração prática: fuzzing, PoCs, engenharia reversa.
Traz a “ponta ofensiva” e descobre vulnerabilidades.
Documenta testes iniciais e resultados brutos.
Membro B — Analista / Revisor
Valida achados do Membro A e de outros.
Refina PoCs, garante reprodutibilidade e clareza.
Cuida da qualidade técnica do que vai virar publicação.
Também pesquisa mitigação e impacto real.
Membro C — Documentação Técnica / Divulgação
Também pesquisa e faz PoCs, mas tem foco em escrever.
Transforma pesquisas em artigos técnicos, labs ou apresentações.
Mantém o blog e organiza submissões para eventos.
Faz a “ponte” entre técnico e comunidade.
📌 Atividades do Time (exemplo de fluxo)
-
Escolha de tema: cada um propõe → consenso do grupo.
-
Exploração (Membro A) → testes, PoCs iniciais.
-
Validação (Membro B) → confirmar falha, refinar exploit.
-
Produção (Membro C) → escrever artigo, preparar slides, enviar para conferência.
-
Revisão cruzada: sempre 2 membros revisam o trabalho do terceiro antes da publicação.
🧭 Dicas de Sustentação
Definir 1 entrega mínima por trimestre (ex.: artigo, talk, PoC).
Rotacionar papéis: cada trimestre, quem escreve mais pode ser quem explora menos.
Documentar até falhas “sem resultado” — isso também gera aprendizado e artigos (“por que esse vetor não funcionou”).
Manter lista pública de pesquisas concluídas e em andamento → dá visibilidade e histórico.
👉 Assim todos os 3 continuam técnicos, mas cada um tem um “chapéu” preferencial que valoriza seus esforços. E novos membros entram já sabendo onde procurar, como propor pesquisa e qual padrão seguir.
Quer que eu monte um template de “Guia do Novo Membro” em Markdown, pronto para vocês colocarem no GitHub (tipo /CONTRIBUTING.md), com esse fluxo escrito passo a passo?