Hoy en día, los consumidores quieren nuevas características, mejoras en los productos que usan y se encuentran en constante búsqueda de innovación. Las empresas lo saben y trabajan duro para que esto suceda. Pero cualquiera que tenga o apoye un equipo de desarrollo sabe que esta área está llena de desafíos diarios, incluyendo encontrar programadores, profesionales de UX, arquitectos y expertos en seguridad. Sin dejar de lado el reto de la seguridad de la información que sigue siendo uno de los protagonistas. Anteriormente, el equipo de seguridad era responsable de la implementación de proyectos de ciberseguridad y punto; estaba acostumbrado a implementar sus productos, como IPS, NGFW, Sandbox, EDR, WAF, etc. Estos proyectos servían para proteger datos y aplicaciones, pero eran más estáticos, no sufrían tantos cambios y muchas veces protegían productos desarrollados por terceros, como SAP, PeopleSoft, entre otros.

Pero la realidad hoy es distinta y llama a la integración. Entonces, ¿cómo lleva el desarrollador al personal de seguridad a la etapa de desarrollo? ¿Cómo puede el profesional de seguridad participar en la etapa inicial sin ser un impedimento para el producto? ¿Cómo reúne el profesional de estrategia de ventas a estos equipos para lanzar la funcionalidad o el producto a tiempo?

Así como la cultura DevOps ha roto muchos silos, también lo hace DevSecOps. Todos son responsables de la seguridad, y no solamente un equipo. Los riesgos deben ser conocidos, compartidos y abordados. Y ese “abordar” puede ser solucionar, compensar de alguna forma o simplemente aceptar que ese riesgo existe (y el peor riesgo es el que el hacker conoce, pero tú no).

Entonces, para que funcione, recomiendo el uso de algunas herramientas, que harán una gran diferencia en las etapas de desarrollo y operación.

• Escanee el código con herramientas SAST, DAST y SCA para tener visibilidad de posibles vulnerabilidades en lo que fue escrito.

• Use una solución de Workload Protection para verificar si la imagen de contenedor tiene vulnerabilidades conocidas. No se puede reinventar la rueda todos los días y usar imágenes/ librerías/contenedores públicos es inevitable (“fail fast, learn faster”), pero tampoco es práctico que el equipo de seguridad evalúe cada uno de ellos.

Además, una solución de Workload Protection valida la configuración del contenedor (por ejemplo, si tiene privilegios) y dirige a las herramientas de Sandbox que confirman que no hay amenazas de día cero integradas allí.

• ¿Hay alguna vulnerabilidad en el código, el riesgo es conocido, pero tiene fecha de entrega y retrasará la divulgación? Compruebe si las soluciones, como un NGFW y un WAF avanzado (con ML e integrado con sistemas de inteligencia de amenazas), pueden mitigar su riesgo, brindando la capa de protección que necesita para acceder al producto. Este tipo de solución mitiga la mayoría de los grandes riesgos, como Log4Shell, MiTB, Bots, Virtual Patching, fuga de datos, entre muchos otros. Además de validar la configuración de los servicios en la nube.

El punto aquí es: una vez que se conocen los riesgos, es posible minimizar su exposición y también el trabajo en su corrección, con planificación, sin retrasar las entregas y sin estar expuesto.