Início
Serviços
Revisão de Código Seguro

05Estação 05 · Construção

Revisão de Código Seguro

Um humano lê as alterações que importam: autenticação, pagamentos, criptografia, parsing e tudo o que um atacante consiga alcançar. Os scanners fazem o resto.

Marcar uma chamada →Percorrer a linha

Como é uma falha aqui

Não é um PDF. É um comentário na linha, com uma correção que pode aplicar.

src/rewards/redeem.tsPR #318 · resgate de parceiro

1export async function redeem(userId: string, offerId: string) {

2 const offer = await offers.get(offerId);

3- const balance = await ledger.balance(userId);

4- if (balance < offer.cost) throw new InsufficientPoints();

5- await ledger.debit(userId, offer.cost);

ATALAIARace condition

A verificação e o débito são duas chamadas. Dois pedidos no mesmo instante passam ambos a verificação e gastam os mesmos pontos duas vezes. Alteração sugerida: um único débito condicional no ledger.

DEV LEAD

Aplicado. Adicionei um teste que dispara dois resgates em paralelo.

6+ const ok = await ledger.debitIf(userId, offer.cost, { atLeast: offer.cost });

7+ if (!ok) throw new InsufficientPoints();

8 return partner.issueVoucher(offer, userId);

9}

Uma revisão, do início ao fim

Escolha um passo, ou deixe correr. Cada fala é o que alguém na sala diz de facto.

Passo 1Encontrar os caminhos de risco

Autenticação, dinheiro, acesso a dados, parsing, criptografia e input externo.

ATALAIAQue código movimenta pontos ou verifica quem é quem?

DEV LEADredeem(), o cliente do ledger e o parser de callbacks do parceiro.

ATALAIAEsses têm sempre revisão humana. Os scanners ficam com o resto.

Sai da salaCaminhos de risco: auth, redeem, ledger, parser

Passo 2Ler os diffs

Linha a linha, com o threat model ao lado do código.

ATALAIAEm redeem(), corre a verificação do saldo e depois a escrita. Nada pelo meio.

PROGRAMADORMas é rápido. Dois pedidos podem mesmo chegar juntos?

ATALAIAFacilmente, com um script. Duas threads, um saldo, dois vouchers.

Sai da salaPR #318: 214 linhas lidas

Passo 3Comentar onde os devs trabalham

As falhas chegam como comentários no PR com uma correção sugerida.

ATALAIAA correção está no PR como sugestão: um débito condicional.

PROGRAMADORAplicado. O meu teste com dois resgates em paralelo agora faz falhar um deles.

Sai da sala3 comentários no PR, 1 correção sugerida

Passo 4Ensinar o padrão

Checklists e trabalho em par para que a próxima revisão precise menos de nós.

DEV LEADPodemos transformar isto numa checklist para os devs seniores?

ATALAIAOito verificações para caminhos de dinheiro. A próxima revisão é liderada por si, e eu observo.

Sai da salaChecklist: 8 verificações para caminhos de dinheiro

ATALAIA
DEV LEAD
PROGRAMADOR
PROGRAMADOR 2
PROGRAMADOR 3

Antes e depois

Antes

Os scanners são bons com padrões conhecidos e cegos à lógica. Autorização falhada, race conditions e erros de confiança precisam de alguém que leia o código e pergunte porquê.

Cada pull request recebe a mesma revisão, toque no que tocar
A lógica de autorização está espalhada por muitos serviços
Os resultados dos scanners são quase sempre ignorados

Depois

Diffs revistos com resultados como comentários de revisão, não um relatório
Correções sugeridas no código
Uma lista curta de caminhos de risco que têm sempre revisão de segurança
Checklists de revisão que os seus programadores sénior podem usar

Formato típico: Por release, por funcionalidade, ou uma fatia fixa de capacidade de revisão.

A seguir na linha

Todas as estações reportam à mesma torre. Estas são as vizinhas.

Estação 08 · ConstruçãoAnálises de Segurança

SAST · SCA · Secrets · IaC · Container

Ver a estação →Estação 03 · DesignThreat Modeling

Negócio, devs e cyber, à mesma mesa

Ver a estação →Estação 04 · ConstruçãoHardening da Toolchain

IDEs, agentes de IA, MCP, endpoints

Ver a estação →

Vamos conversar

Uma chamada de 30 minutos. Sem slides, sem tabela de preços, e um próximo passo em qualquer caso.

Marcar uma chamada →Percorra cada estação