De uma equipa de um a um programa a funcionar: um plano de 90 dias

15.04.20264 min de leituraEquipa Atalaia

Uma equipa de um não consegue fazer tudo, por isso a pergunta útil é o que fazer primeiro e como perceber se está a funcionar. Este plano assume um engenheiro de segurança, algumas dezenas de repositórios, um sistema de CI e pelo menos uma conta de cloud. Percorre a linha mais ou menos pela ordem em que o código a atravessa.

Cada bloco tem duas semanas. A regra para cada bloco é a mesma: terminar com um controlo que corre em todo o lado, mesmo que básico, em vez de um controlo perfeito num único repositório piloto.

Semanas 1-2: inventariar a linha

Não pode proteger o que não listou. Construa um inventário simples de repositórios, donos, linguagens, pipelines, destinos de deploy e quem tem direitos de admin. Uma folha de cálculo serve. A maior parte pode ser extraída da API do controlo de versões.

# list repositories with their default branch and archive status
gh repo list your-org --limit 500 \
  --json name,defaultBranchRef,isArchived,visibility \
  --jq '.[] | [.name, .defaultBranchRef.name, .isArchived, .visibility] | @tsv'

Atribua uma equipa dona a cada repositório. Os repositórios sem dono são o primeiro achado do programa.

Semanas 3-6: estações de build e release

Dois blocos na parte da linha onde o código é escrito e empacotado.

• Proteção de branches e revisão. Exija pull requests e pelo menos uma revisão nos branches por omissão. Ative o secret scanning e o push protection onde a sua plataforma o suporte.
• Segredos no CI. Adicione o Gitleaks como job não bloqueante em todo o lado e torne-o bloqueante quando o backlog estiver limpo.
• Dependências. Gere um SBOM com o Syft e analise-o com o Grype ou o Trivy. Comece apenas por reportar, para que as equipas vejam a forma do problema antes de algo falhar.
• Higiene do pipeline. Fixe as actions de terceiros a SHAs de commit e defina as permissões por omissão do token do workflow como só de leitura. Corra o actionlint e o zizmor para apanhar os erros óbvios.

# a minimal shared job, called from each repository
name: security-baseline
on: [pull_request]
permissions:
  contents: read
jobs:
  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<pinned-sha>
        with:
          fetch-depth: 0
      - run: gitleaks git --redact --exit-code 1 .

Semanas 7-10: estações de execução e design

Vá para as duas pontas da linha que um engenheiro sozinho costuma saltar.

• Operar. Confirme que os logs de produção de autenticação, ações de administração e do control plane da cloud chegam a um sítio pesquisável e ficam guardados tempo suficiente para investigar. Escreva quem é chamado em caso de suspeita de incidente.
• Design. Escolha os dois ou três serviços que lidam com dinheiro, credenciais ou dados pessoais e faça uma sessão curta de STRIDE com cada equipa. Uma hora por serviço chega para produzir uma lista de riscos e responsáveis.
• Acessos. Rever quem tem admin no controlo de versões, no CI e na cloud. Remover o que não é necessário e registar o resto.

Semanas 11-13: o programa à volta

O último bloco transforma atividade num programa com que as pessoas podem contar.

1. Escala de triageOs findings chegam a uma única fila, com uma pessoa designada por semana e regras de severidade escritas.
2. Prazos de correçãoAcordar com a liderança de engenharia em quanto tempo cada severidade deve ser corrigida, e como é uma exceção.
3. ChampionsUm engenheiro interessado por equipa, que é avisado cedo das alterações e tem uma linha direta para a segurança.
4. RoadmapUm plano de uma página para os dois trimestres seguintes, com base no que as primeiras 10 semanas mostraram.

O que medir

Os números de achados, por si só, são ruído: sobem quando acrescenta um scanner e descem quando desliga um. Meça um pequeno conjunto de coisas que consiga definir com precisão e que mexam quando o programa melhora.

Reporte-os mensalmente numa página, como tendências, junto com uma nota curta sobre o que mudou. Se precisar de uma quinta medida, que seja o número de serviços com um threat model atual.

O que fazer na segunda-feira

• Exporte a lista de repositórios e acrescente uma coluna de responsável.
• Escolha um controlo das semanas 3-6 e implemente-o em modo só de relatório em todos os repositórios esta semana.
• Marque três sessões de design de uma hora para os serviços que mais importam.
• Escreva as quatro definições de medidas acima na wiki da equipa, para que o primeiro relatório use as mesmas palavras que o último.

Onde isto fica na linha

Na torre (em desenvolvimento):