Los beneficios de DEVSECOPS son evidentes. Mejor calidad de software, mejor acabados, reducción del time to market, mejora de cumplimiento, etcétera. Pero ¿dónde queda la seguridad en todo esto? No es raro, los medios de comunicación generalistas así lo evidencian, que servicios tenidos como referencia de lo que puede aportar la informática al negocio, no es que pudieran ser endebles a posibles ataques: es que han sido escandalosamente vulnerables. Y todo porque en algún momento del diseño, del desarrollo o de su operación no se ha aplicado seguridad. No han fallado los controles de seguridad convencionales, los antivirus, firewall y demás mecanismos de todos conocidos. Ha fallado como se ha utilizado, lo que se ha hecho en ese servicio o aplicación. Así ocurre que bases de datos que se han perfilado su seguridad al milímetro y que se han colocado detrás de firewall con enrevesadas reglas de filtrado son accedidas con las credenciales de sysadmin por defecto, desde un script en claro que lanza un becario desde su PC obsoleto y descatalogado. O por un programador que le pareció buena idea incluir una librería que le resolvía un problema pero que no verifico su procedencia, posibles fallos y vulnerabilidades. Uno puede gastarse una pasta gansa en colocar la mejor puerta blindada en su casa, pero de poco le servirá para evitar la entrada de los cacos, si deja la llave debajo del felpudo. DevSECOps se ocupa de que nadie deje la llave en el felpudo.

Al aplicar una metodología como DevSECOps el área de seguridad en IT deja de trabajar de forma independiente, aislada. Debe involucrarse con el resto de los departamentos para facilitar sus iniciativas y no centrarse en vigilar que se produzcan incidentes de seguridad para resolverlos con prontitud. No se trata de aplicar métodos o estándares de seguridad que se pueden aplicar a la gestión de IT, como puede ser la ínclita ISO 27000. Con DevSECOps se trata de hacer que las operaciones en los procesos en los que intervienen los equipos de IT se hagan con perspectiva de seguridad. Desde el responsable del área hasta el becario, pasando por programador y el técnico de sistemas. Y por supuesto implicando al negocio. Los usuarios, al “usar” los servicios y aplicaciones, también son parte activa de la seguridad.

DevSECOps puede parecer otra novedad efímera de las modas que sacuden de vez en cuando al mundo IT, pero no lo es. Aún es una metodología o, si se prefiere, un movimiento incipiente al que le queda recorrido pero que no debe ser contemplado como algo independiente que vaya a sustituir a lo que ya se viene aplicando con muy buenos resultados: DevOps. Utilizar DevOps con seguridad debe ser considerado una evolución y una mejora de esta metodología independientemente del nombre que adopte.

Se podrá ser más o menos escéptico con la novedad, aplicarla o no aplicarla; no que no puede es pasar desapercibido. Y es lo que hay que tener en cuenta a la hora de valorar y estimar al proveedor de seguridad. En los tiempos que corren, ya no sirve el proveedor que base su valía en el área de seguridad en el conocimiento y experiencia de los mecanismos convencionales que todos saben que funcionan y que son efectivo. Esto no aporta valor a la IT desde la perspectiva de negocio.