ATALAIA
  1. Inicio
  2. Servicios
  3. Revisión de código seguro
05Estación 05 · Build

Revisión de código seguro

Una persona lee los cambios que importan: auth, pagos, crypto, parsing y todo lo que un atacante pueda alcanzar. Los escáneres hacen el resto.

Cómo es un hallazgo aquí

No un PDF. Un comentario en la línea, con una corrección que puedes aplicar.

src/rewards/redeem.tsPR #318 · canje en partners
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

La comprobación y el débito son dos llamadas. Dos peticiones a la vez pasan la comprobación y gastan los mismos puntos dos veces. Cambio sugerido: un único débito condicional en el ledger.

DEV LEAD

Aplicado. Añadí un test que lanza dos canjes en 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}

Una revisión, de principio a fin

Elige un paso o déjalo correr. Cada línea es lo que alguien dice de verdad en la sala.

Paso 1Encuentra las rutas de riesgo

Auth, dinero, acceso a datos, parsing, cripto y entradas externas.

ATALAIA¿Qué código mueve puntos o comprueba quién eres?

DEV LEADredeem(), el cliente del ledger y el parser del callback del partner.

ATALAIAEsos siempre pasan por revisión humana. Los escáneres se encargan del resto.

Sale de la salaRutas de riesgo: auth, redeem, ledger, parser

Paso 2Lee los diffs

Línea a línea, con el threat model junto al código.

ATALAIAEn redeem(), se ejecuta la comprobación del saldo y luego la escritura. Nada entre medias.

DESARROLLADOREs rápido, eso sí. ¿De verdad pueden llegar dos peticiones a la vez?

ATALAIAFácil, con un script. Dos hilos, un saldo, dos vales.

Sale de la salaPR #318: 214 líneas leídas

Paso 3Comenta donde trabajan los devs

Los hallazgos llegan como comentarios en la PR, con una corrección sugerida.

ATALAIALa corrección va en la PR como sugerencia: un débito condicional.

DESARROLLADORAplicado. Mi test con dos redeems en paralelo ahora hace fallar uno.

Sale de la sala3 comentarios en la PR, 1 arreglo sugerido

Paso 4Enseña el patrón

Checklists y pairing para que la próxima revisión nos necesite menos.

DEV LEAD¿Podemos convertir esto en un checklist para los desarrolladores senior?

ATALAIAOcho comprobaciones para los flujos de dinero. En la próxima revisión la diriges tú y yo observo.

Sale de la salaChecklist: 8 comprobaciones para los flujos de dinero

  • ATALAIA
  • DEV LEAD
  • DESARROLLADOR
  • DESARROLLADOR 2
  • DESARROLLADOR 3

Antes y después

Antes

Los escáneres son buenos con los patrones conocidos y ciegos a la lógica. La autorización rota, las condiciones de carrera y los errores de confianza necesitan a alguien que lea el código y pregunte por qué.

  • Cada pull request recibe la misma revisión, toque lo que toque
  • La lógica de autorización está repartida entre muchos servicios
  • Los hallazgos de los escáneres se ignoran casi siempre
Después
  • Diffs revisados con los hallazgos como comentarios de revisión, no como informe
  • Correcciones sugeridas en el código
  • Una lista corta de rutas de riesgo que siempre pasan por revisión de seguridad
  • Checklists de revisión que tus desarrolladores senior pueden usar

Formato típico: Por release, por funcionalidad, o una porción fija de capacidad de revisión.

Habladlo

Una llamada de 30 minutos. Sin diapositivas, sin lista de precios y con un siguiente paso en cualquier caso.