No hemos aprendido nada del hackeo de SolarWinds

Artículo original ↗ Discusión en Hacker News ↗

Años después de la brecha de SolarWinds, los comentaristas argumentan que los problemas estructurales centrales de la seguridad del software siguen en gran medida sin abordar, especialmente en torno a la cadena de suministro de software. Destacan mecanismos débiles o abandonados para verificar dependencias, la profunda dependencia de plataformas centralizadas como GitHub y los incentivos económicos que favorecen la entrega rápida de funciones frente a una seguridad rigurosa. Las soluciones propuestas van desde una mejor compartimentación y sistemas basados en capacidades hasta la computación confidencial y regímenes regulatorios o de responsabilidad más estrictos, pero muchos dudan de que puedan adoptarse ampliamente sin un cambio cultural y económico significativo.

Firma de paquetes, repositorios y confianza en las dependencias

  • Varios comentarios critican la eliminación de las firmas PGP por parte de PyPI y la falta más amplia de firma/verificación robustas en los principales repositorios de paquetes.
  • Algunos confían en el empaquetado de la distribución (.deb) y en espejos locales en lugar de PyPI, señalando una mejor comprobación de firmas y la corrección de paquetes rotos.
  • Las herramientas empresariales (p. ej., similares a JFrog/Sonatype) que hacen hash y etiquetan componentes en distintos ecosistemas se ven como soluciones provisionales útiles, pero no están ampliamente disponibles en repositorios públicos.
  • La fuerte dependencia de GitHub como columna vertebral de facto para CI, las fuentes de paquetes y el alojamiento de código se considera un riesgo sistémico.

Análisis, herramientas universales y sus límites

  • Existe interés en servicios que analicen binarios o código fuente en busca de ataques a la cadena de suministro, pero muchos dudan de su eficacia y escalabilidad.
  • Existen herramientas que detectan comportamiento “sospechoso” de los paquetes (análisis estático/dinámico) y se están desarrollando activamente.
  • Se considera ampliamente inviable a gran escala un gestor de paquetes universal.

Economía, incentivos y responsabilidad

  • Los comentaristas subrayan que las organizaciones quieren una seguridad “suficientemente buena” al menor coste posible; el endurecimiento real se ve como económicamente poco atractivo.
  • Las multas y la presión regulatoria podrían ayudar, pero podrían afianzar a los grandes proveedores y perjudicar a las pequeñas empresas y al software libre.
  • Algunos argumentan que deberíamos diseñar sistemas para tolerar software comprometido mediante la compartimentación y la reducción del radio de explosión, en lugar de asumir que todo el software puede hacerse seguro.

Capacidades, sandboxing y diseño del sistema operativo

  • Un modelo de capacidades estandarizado se considera ideal, pero políticamente y técnicamente poco probable, y susceptible de abuso por parte de los proveedores (p. ej., redefinir las capacidades para proteger modelos de negocio).
  • Otros enfatizan la compartimentación y la redundancia, comparándolo con sistemas críticos para la seguridad donde un único fallo no arruina todo el sistema.
  • Hay discusión sobre los modelos de permisos móviles (iOS/Android), la instalación de apps desde terceros y la compensación entre plataformas “seguras” y cerradas y la libertad del usuario.

Seguridad de la cadena de suministro y atestación

  • Algunos proponen sistemas de compilación endurecidos e aislados y metadatos/atestación estandarizados (p. ej., in-toto, Witness) para rastrear y verificar los pasos de la cadena de suministro.
  • La computación confidencial con atestación remota se discute como una forma de probar que los artefactos se construyeron a partir de un código fuente específico con herramientas específicas, incluso en hosts comprometidos.
  • Esto desplaza los ataques hacia los compiladores y las propias herramientas de compilación, lo que aumenta el interés en compiladores seguros frente a fallos de memoria y en compilaciones reproducibles.

Realidad operativa y cumplimiento

  • Los profesionales señalan que, para amenazas avanzadas, la prevención es limitada; la práctica moderna se centra en EDR, registros, SIEM y la detección de comportamientos posteriores al compromiso.
  • Las redes corporativas se describen como desordenadas, con muchas restricciones heredadas y concesiones en la experiencia de usuario.
  • Los cuestionarios de seguridad y el cumplimiento tipo casilla se critican por obsoletos y desalineados con arquitecturas nativas de la nube, aunque hay intentos de simplificarlos.