Alan-Lucena/claude-skills

Remediar hallazgos de seguridad

Tu trabajo no es "arreglar todo de una". Es remediar en el orden correcto, verificar cada fix y no romper lo que ya funciona. El usuario suele ser vibecoder: no des por sentado que entiende el blast radius, explícalo.

Regla de oro

NUNCA borres, undeployes o desactives algo en producción sin antes responder: "¿qué lo usa hoy?" (front, jobs, otros endpoints, el dashboard). Mirar antes de borrar. Si algo legítimo lo usa, parar y avisar al usuario, no proceder.

Cómo preguntar en cada gate

En cada punto donde el flujo se detiene a pedir confirmación (orden propuesto, plan de auth, antes de aplicar algo irreversible), usa la herramienta AskUserQuestion en vez de preguntar en prosa libre. El usuario es vibecoder y prefiere elegir una opción a redactar la respuesta.

Patrón por gate:

• Header corto (ej. "Tier 1 crítico", "Plan auth", "Aplicar diffs").
• Opciones típicas: "Aprobar y arrancar" (recomendada, primera), "Ajustar antes", "Revisar/explicar más primero".
• Una pregunta por decisión real. No agrupes en una sola pregunta cosas que el usuario querría aprobar por separado (ej. arrancar Tier 1 y aprobar el plan Tier 2 son DOS preguntas distintas).
• Si la decisión depende de algo que el usuario aún no vio (ej. el diff todavía no se mostró), primero muestra ese contenido y luego pregunta.

Flujo

1. Triage

Ordena los hallazgos por severidad e irreversibilidad, no solo por severidad. Un "alto" que rompe un flujo en prod es más delicado que un "crítico" aislado. Clasifica cada uno en:

• Aislado + reversible → se puede arreglar directo.
• Toca auth / cambia contrato público → requiere plan antes de código.
• Borra o undeploya infra en prod → requiere confirmar "qué lo usa hoy" + respaldo + plan de rollback ANTES de tocar nada.

Presenta el orden propuesto y para. No avances al fix sin que el usuario confirme.

2. Crítico / irreversible primero, solo

• Antes de borrar/undeployar: lista qué lo invoca hoy. Si está realmente huérfano, deja respaldo (export de tablas afectadas) y plan de rollback.
• Aplica UN solo cambio. No mezcles con otros hallazgos.
• Verifica (paso 4) antes de seguir.

3. Fixes de auth / contrato público

• Primero el plan en texto: qué validación agregas, qué clientes legítimos llaman hoy, cómo evitas romperlos. Espera aprobación.
• Recién entonces escribe código.

4. Verificación (obligatoria por cada fix)

Re-ejecuta el mismo ataque/PoC que encontró la vuln y muestra el "antes vulnerable / ahora rechazado". Sin reproducción, el fix NO cuenta como cerrado. La palabra "ya está arreglado" no alcanza.

5. Regresión

Confirma que los flujos legítimos siguen vivos (ej. si agregaste auth a un endpoint, que el cliente oficial siga funcionando). Nombra qué probaste.

6. Guardrail

Por cada vuln confirmada, agrega un test que reproduzca el exploit y falle si reaparece. Si no es testeable, deja una nota de por qué.

7. Quick wins en lote

Los hallazgos de bajo riesgo (headers, validaciones de input, fixes de query) sí se agrupan en un commit, pero lista cada uno con su diff antes de aplicar.

8. Cierre

Resumen final: qué quedó arreglado y verificado, qué quedó pendiente y por qué (ej. multisig pre-mainnet), y qué cambios necesitan deploy manual del usuario.

Auto-chequeos (no los saltees, no esperes que el usuario los pida)

El usuario es vibecoder y puede aprobar un fix sin notar que es decorativo. Antes de declarar cerrado un hallazgo, corre estos chequeos por tu cuenta y, si alguno aplica, dilo aunque nadie lo haya pedido.

• Auth = identidad, no presencia. Un gate que solo verifica que LLEGA un token no cierra un IDOR. Confirma que el token/sesión está atado a la identidad (wallet, user_id) y que comparas esa identidad contra el recurso pedido. Si el check de "pertenencia" (403) no se apoya en un binding real, el fix es falso.
• main = prod. Si deployaste los fixes desde una rama no mergeada, producción corre código que no está en main: el próximo deploy desde main REVIERTE los fixes. Avisa que hay que mergear, y enmárcalo como riesgo de seguridad, no como prolijidad.
• El auditor puede equivocarse. Antes de aplicar un fix, verifica el supuesto del hallazgo en el código real (ej. "el cliente manda token" puede ser falso). Un fix sobre un supuesto equivocado rompe producción.
• Riesgo aceptado se documenta, no se silencia. Si algo no se arregla (token estático, rotación revertida porque rompía un flujo), déjalo escrito como riesgo aceptado, no como "cerrado".
• Validación en un endpoint, no en todos. Si un campo se valida en PATCH pero no en POST (o viceversa), el agujero sigue. Chequea todas las rutas de entrada del mismo dato.
• Borrar deja huella. Tras undeployar/borrar, audita la tabla o recurso por datos que dejó el exploit; no asumas que revertir el endpoint limpia el daño ya hecho.

Estilo de output

• Muestra el diff antes de aplicar cualquier cambio irreversible o de deploy.
• No declares "resuelto" sin la reproducción del paso 4.
• Si un hallazgo resultó falso positivo al investigarlo, dilo y no lo "arregles".