Entrevista de producto: ¿La revisión de dependencias debería bloquear los merges?

Consigna y contexto

Usted es el responsable de una plataforma de desarrollo para numerosos repositorios. El equipo de seguridad desea que en cada pull request se muestren las dependencias agregadas, actualizadas y eliminadas, además del impacto de vulnerabilidades, y que se bloqueen los merges cuando se detecte un paquete de alto riesgo. A ingeniería le preocupan los falsos positivos, los conflictos de licencias y los tiempos de espera más prolongados. Asuma que la plataforma puede leer manifiestos y lockfiles, y que cuenta con cuatro semanas para una prueba piloto. El objetivo es reducir el riesgo de dependencias que llega a producción sin ralentizar las entregas.

Qué evalúa el entrevistador

El entrevistador busca resultados medibles: dependencias de alto riesgo que ingresan a producción, tiempo de remediación, tasa de bloqueo de la barrera, tasa de falsos positivos y el p95 de espera de los desarrolladores. Una respuesta sólida separa la visibilidad (comentarios o reportes) de la aplicación de políticas (bloqueo de merges) y luego escalona la política según el riesgo del repositorio y la cobertura del ecosistema, en lugar de aplicar una única regla en todas partes.

Aclaraciones que conviene hacer primero

• ¿Qué severidades de vulnerabilidad u obligaciones de licencia deben bloquear? Las obligaciones legales pueden exigir un tratamiento más estricto que la explotabilidad por sí sola.
• ¿Qué ecosistemas y lockfiles están cubiertos? No se puede asumir que un repositorio no analizado esté protegido.
• ¿Quién es el responsable de la remediación y del SLA? Sin un responsable claro, una barrera solo acumula excepciones.
• ¿Cuál es la vía para liberaciones de emergencia? Necesita una exención temporal auditable con fecha de vencimiento.
• ¿El objetivo es el descubrimiento, la aplicación o ambos? Si los falsos positivos son altos, comience en modo de solo reporte.

Estructura para una respuesta de 30 segundos

“Establecería una línea base de los cambios en dependencias de alto riesgo, la mediana y el p95 del tiempo de remediación, los bloqueos de la barrera y las exenciones. Luego realizaría una prueba piloto en repositorios de alto riesgo con grafos de dependencias completos y validaciones estables: primero reportando, luego bloqueando hallazgos críticos y evaluando después los hallazgos altos. El éxito debe incluir menor riesgo y salvaguardas en la entrega. Si los falsos positivos o las esperas superan los límites, volvería al modo de solo reporte y corregiría las reglas.”

Respuesta detallada paso a paso

1. Segmentar el riesgo. Clasifique los repositorios por explotabilidad, exposición en producción, sensibilidad de los datos y obligaciones de licencia; no los clasifique únicamente mediante un puntaje de vulnerabilidad.
2. Validar los datos. Verifique si se analizan los manifiestos, los lockfiles y los envíos de dependencias. Marque los ecosistemas no compatibles como desconocidos en lugar de seguros.
3. Diseñar la política. Comente en repositorios de bajo riesgo; bloquee hallazgos críticos en repositorios de alto riesgo; use un conjunto explícito de licencias permitidas o denegadas según SPDX y mantenga la revisión humana.
4. Definir métricas. Las métricas principales son la tasa de dependencias de alto riesgo que ingresan a producción y el p95 de remediación. Las salvaguardas incluyen la tasa de bloqueo, la tasa de falsos positivos, el p95 de espera de compilación, la tasa de exenciones y las horas dedicadas por el equipo de seguridad.
5. Implementar gradualmente. Comience con el 10% de los repositorios de alto riesgo. Registre las coincidencias de reglas, los resultados de remediación, los motivos de las exenciones y su vencimiento. Compare los ecosistemas por separado para que los promedios no oculten brechas.
6. Lanzamiento y reversión. Expanda a través de conjuntos de reglas de la organización y versione cada cambio de política. Si la tasa de bloqueo o el tiempo de espera violan una salvaguarda, cambie al modo de solo reporte en lugar de acostumbrar a los equipos a eludir la validación.

Las alternativas incluyen bloquear únicamente las ramas de release, escaneos diarios, umbrales diferenciados para dependencias de runtime y de desarrollo, o mejorar primero la cobertura de lockfiles. Si el problema principal es la falta de inventario, completar el grafo de dependencias es más valioso que un bloqueo más estricto.

Respuesta modelo

“Trataría esto como un producto de control de riesgos. En la primera semana, mediría cuatro líneas base: dependencias de alto riesgo que ingresan a producción, p95 de descubrimiento a remediación, tasa de bloqueo de la verificación de dependencias y tasa de exenciones manuales. En la segunda semana, probaría el modo de solo reporte en repositorios de alto riesgo con grafos completos y responsables de seguridad asignados. En la tercera semana, bloquearía únicamente los hallazgos críticos, usaría reglas de licencias SPDX explícitas y exigiría un motivo y una fecha de vencimiento para cada exención. Requeriría una reducción del 40% en nuevas dependencias de alto riesgo, ningún aumento en el p95 de remediación, una tasa de bloqueo inferior al 5% y un incremento en el p95 de espera de compilación menor al 10%. Si más del 2% de las dependencias no pueden analizarse, detendría la expansión y corregiría el inventario; si las exenciones de emergencia superan el 10%, la política o el modelo de propiedad son incorrectos.”

Errores comunes

• Error: Bloquear todas las vulnerabilidades de inmediato → Por qué falla: No se segmentan la severidad, la explotabilidad ni la exposición en producción → Solución: Reportar primero y aplicar políticas según el riesgo del repositorio.
• Error: Optimizar la cantidad de detecciones del escaneo → Por qué falla: Las detecciones no demuestran una reducción del riesgo → Solución: Medir la tasa de ingreso a producción y la latencia de remediación.
• Error: Ignorar los lockfiles y la cobertura del ecosistema → Por qué falla: Las dependencias no analizadas generan una falsa sensación de seguridad → Solución: Hacer que la cobertura sea un requisito previo y marcar lo desconocido.
• Error: Permitir exenciones permanentes → Por qué falla: La barrera pierde autoridad progresivamente → Solución: Exigir un motivo, un responsable y una fecha de vencimiento.

Preguntas de seguimiento y respuestas

¿Deberíamos desactivar la barrera cuando los desarrolladores reclamen falsos positivos?

Segmente los falsos positivos por regla, ecosistema y severidad, y mantenga el modo de solo reporte mientras recopila evidencia. Vuelva a la aplicación de solo reporte únicamente cuando los falsos positivos no puedan ajustarse al SLA objetivo; la corrección de las reglas debe ser un criterio de salida.

¿Qué pasa si una vulnerabilidad crítica no tiene una versión corregida?

Indique explícitamente que no hay una corrección disponible (“no fix available”). Exija que un responsable de seguridad apruebe una exención temporal, controles compensatorios y una fecha de revisión; nunca convierta un fallo del escaneo en un resultado aprobado.

¿Cómo demuestra que la política no ralentiza las entregas?

Compare el p95 de espera previo y durante la prueba piloto, el volumen de merges (throughput) y la tasa de reversión por repositorio y tipo de cambio, al tiempo que reporta la tasa de exenciones. Un promedio a nivel de toda la empresa puede ocultar bloqueos graves en un equipo pequeño.

¿Cuándo se expande a toda la organización?

Expanda únicamente después de que la cobertura de repositorios de alto riesgo, los impactos de reglas explicables, el SLA de remediación y las salvaguardas de tiempo de espera cumplan con los objetivos durante dos ciclos de lanzamiento y las exenciones se cierren a tiempo.