El cumplimiento pertenece a la solicitud de extracción.
Llamamos a esta práctica revisión de cumplimiento para solicitudes de extracción: evaluar cada cambio frente a los marcos que tu empresa debe cumplir, en el diff, no meses después en una auditoría. Estos ensayos son los argumentos detrás de esa categoría. Breves, opinados y escritos para las personas que realmente cambian el sistema: ingenieros e ingenieros de seguridad.
- 00
Revisión de cumplimiento para pull requests.
La revisión de código se está dividiendo en enfoques: corrección, seguridad y ahora cumplimiento. Este ensayo define el tercer enfoque como una categoría y explica por qué existe ahora.
- 01
Detéctalo en el PR, no en la auditoría.
Una brecha de cumplimiento es más barata de corregir en el momento en que se escribe y más cara el día que un auditor la encuentra.
- 02
El cumplimiento es una verificación CI, no un simulacro de incendios trimestral.
Tratar el cumplimiento como un evento que se supera dos veces al año es la razón por la que parece un simulacro de incendios. Trátalo como una verificación que se ejecuta en cada cambio y se volverá aburrido, que es el objetivo.
- 03
Tu linter es ciego a los marcos de cumplimiento.
Los linters y escáneres detectan defectos y clases de vulnerabilidades. Un cambio puede ser código impecable y, sin embargo, incumplir una obligación de cumplimiento, porque la obligación no es una propiedad del código, sino una propiedad del marco.
- 04
Los controles viven en los diffs, no en documentos de Word.
Un control escrito en un documento de política es una intención. El control solo es real donde el sistema en ejecución lo hace cumplir, y el sistema en ejecución cambia un diff a la vez.
- 05
La auditoría es un indicador rezagado.
Una auditoría te dice lo que fue cierto hace meses. Si ese es el único señal que tienes, estás dirigiendo un sistema mirando por el espejo retrovisor.