La mayoría de los equipos que toman en serio las solicitudes de extracción ya asignan uno o dos revisores a cada cambio. Un verificador de errores como Cursor Bugbot o CodeRabbit lee el diff y pregunta si el código es correcto. Un agente de seguridad lo lee y pregunta si el código es seguro: una inyección, una verificación de acceso rota, un secreto filtrado. Ambos responden preguntas reales, y un cambio serio merece ambas.
Hay una tercera pregunta que la revisión de código rara vez asigna a un responsable: ¿este cambio sigue cumpliendo con los marcos de cumplimiento por los que tu empresa está auditada? No es '¿es un error?' ni '¿es una vulnerabilidad?', sino '¿afecta a un control en SOC 2, ISO 27001 o el GDPR, y sigue siendo válida la evidencia después de su implementación?'. Es una pregunta diferente a la corrección y a la seguridad, y es para la que está construido heygrc. Se sitúa junto a las otras dos en lugar de reemplazar ninguna.
Correcto, seguro y aún un hallazgo
Las tres preguntas son independientes. Un cambio puede ser un error y no una vulnerabilidad. Puede ser una vulnerabilidad y no un problema de cumplimiento. Y puede ser código limpio y funcional que, sin embargo, modifica un control por el que serás auditado. Este último caso es el que rara vez tiene un revisor en la sala.
Este es el tipo de cambio al que nos referimos. Trátalo como ilustrativo: una línea de código limpio que compila y se ejecuta, y que no es ni el error ni la vulnerabilidad en el diff.
export async function decideRefund(req: RefundRequest) { const score = await risk.score(req) if (score < 0.2) return { status: "rejected", reason: "auto" } return queueForReview(req)}La rama es código limpio y funcional: devuelve una decisión y no hay nada en ella que sea un error o una vulnerabilidad. Pero toma una decisión completamente automatizada sobre una persona, denegando su reembolso, sin opción a revisión humana. Cuando una decisión de este tipo produce un efecto legal o de similar importancia, el GDPR Art. 22 otorga a la persona el derecho a no estar sujeta a ella y el derecho a obtener intervención humana. Lo que este cambio realmente implementó es una pregunta de cumplimiento que responder, no un defecto que corregir.
Por qué la tercera pregunta no tiene responsable
Un verificador de errores y un agente de seguridad pueden ser deliberadamente ciegos a los marcos, y esa es su fortaleza. Sus reglas son universales: un uso después de la liberación es un uso después de la liberación en cada repositorio, una consulta no parametrizada es una inyección en todas partes. Las reglas universales son la razón por la que esas herramientas funcionan sin configuración.
El cumplimiento es lo opuesto. Si un cambio es un hallazgo depende de a qué marcos estás sujeto, qué controles has documentado y en qué se basó tu última auditoría. El mismo diff que no significa nada para una empresa es una brecha de evidencia de SOC 2 CC7.2 para otra. Eso no es algo que una regla ciega a los marcos pueda manejar por sí sola, porque el problema no es una propiedad del código. Es una propiedad de tus obligaciones, y debe leerse en función de ellas.
Aplica las lentes, no elijas entre ellas
La conclusión no es 'añade otra herramienta'. Es que una solicitud de extracción se lee de manera más completa a través de tres lentes, no de uno: ¿es correcto?, ¿es seguro?, ¿sigue cumpliendo con nuestros marcos? Mantén tu verificador de errores. Mantén tu agente de seguridad. Son buenos en sus preguntas, y heygrc no intenta responder las suyas. heygrc añade la tercera lente y la reporta de la única manera en que un hallazgo de cumplimiento vale algo: citando el control exacto que afecta.
El ejemplo anterior es ilustrativo, el tipo de cambio que plantea la tercera pregunta, no un incidente específico. Pero la forma es lo importante: los cambios que modifican tu postura de cumplimiento suelen no ser los que tienen errores o los inseguros. Son los limpios, que parecen correctos, pero que tocan silenciosamente un control, lo cual es algo diferente a buscar un error o una vulnerabilidad.