Cómo DevSecOps empodera a los desarrolladores ciudadanos

Para 2025, total creación de datos globales llegará a 181 zettabytes. Para las empresas, esos datos son un activo que les permite aprovechar una variedad de plataformas tecnológicas para crear experiencias de cliente altamente personalizadas que generen lealtad y atraigan nuevos negocios. Sin embargo, estas experiencias dependen de las infraestructuras en la nube que utilizan modos de seguridad compartidos. Ahí es donde radica el riesgo, y está aumentando a medida que la tecnología crece para incorporar un nuevo ejército de desarrolladores ciudadanos que utilizan plataformas de código bajo y sin código.

Comprender y superar la mentalidad de herencia 

Gartner estima que para 2025, el 70 % de las aplicaciones empresariales se crearán a partir de plataformas de bajo código y sin código, como Salesforce y ServiceNow. Responder con una mentalidad basada en la herencia es una forma segura de hacer que más de dos tercios de las aplicaciones empresariales fallen.   

La "mentalidad de herencia" es una descripción adecuada de los problemas que aquejan a la infraestructura. Me recuerda a unos niños ricos y mimados que dependen totalmente del trabajo realizado y de las personas que los precedieron. Esa no es una buena forma de construir un legado, y es una forma igualmente mala de construir un sistema.

Cuando tiene una mentalidad heredada, asume que la infraestructura está configurada. La plataforma es segura y la seguridad está integrada. La confianza se asume simplemente porque la tecnología estaba ahí antes que el administrador.

Esa mentalidad hereditaria afecta a las plataformas de código bajo y sin código. Los usuarios confían en la seguridad de una plataforma para llevarlos a través de una infraestructura empresarial completa. En cambio, la seguridad de esa plataforma debería aplicarse solo a esa plataforma.

Supongamos que los desarrolladores de Salesforce crean un programa de asignación automatizado para nuevos clientes potenciales. Lo usan dentro de Salesforce para asignaciones internas y está bien. Pueden confiar en la seguridad de la plataforma. Deciden ampliarlo para mejorar la automatización. Conectan ese programa a un CRM externo como ServiceNow, SAP u Oracle. La mentalidad de herencia se hace cargo: Salesforce es seguro. ServiceNow, SAP o el tercero es seguro.

Entonces, Salesforce + tercero = seguro.

Pero, hay una gran cantidad de incógnitas en ese signo más. ¿Cómo conecta de forma segura y compatible el programa interno creado en Salesforce con el programa externo creado en la plataforma de terceros? Hay mucho margen de error en ese único carácter.  

Y esa es sólo una conexión. Muchos programas creados en Salesforce tocan cientos de otros. Son cientos de incógnitas tratadas como el signo más descrito anteriormente por personas que tienen poca o ninguna experiencia en desarrollo.  

La única solución es llevar ese desarrollo a la tierra con un retorno a los principios de DevSecOps.

Establecimiento del marco DevSecOps 

DevSecOps Los marcos se han escrito, reescrito y vuelto a escribir desde que se creó el concepto. No hay necesidad de reinventar la rueda al establecerlos, especialmente cuando SAFECode y la Alianza de Seguridad en la Nube ha construido seis pilares:

1. Responsabilidad colectiva: La seguridad es responsabilidad de cada persona en la empresa, pero las personas no pueden cumplir con estándares que no conocen. Se deben asignar líderes para impulsar la política de seguridad cibernética y garantizar que se difunda en toda la empresa.  
2. Colaboración e integración: El conocimiento debe ser compartido y transferido. La mitad de la razón por la que las empresas caen en la mentalidad heredada es que todos los que conocían el antiguo sistema se han ido. El intercambio continuo de conocimientos ayuda a eliminar este problema.
3. Implementación pragmática: La implementación pragmática se relaciona con la experiencia del desarrollador. Los procesos que son difíciles, mundanos y difíciles de manejar no se siguen por mucho tiempo. La seguridad debe integrarse en las prácticas de desarrollo, es decir, cada línea de código requiere una línea de prueba. Una empresa de alto rendimiento iría más allá al usar una herramienta para automatizar cada línea de código de prueba.
4. Cumplimiento y desarrollo: Los requisitos de cumplimiento deben guiar el proceso de desarrollo de una manera que no permita a los desarrolladores desviarse de ellos. Un desarrollador de una institución financiera, por ejemplo, trabajaría en una plataforma diseñada para cumplir con la Ley Gramm-Leach-Bliley. El desarrollador no tiene que conocer los entresijos individuales del acto para cumplir porque están integrados en la plataforma.  
5. Automatización: Las tareas que son predecibles, repetibles y de gran volumen deben automatizarse siempre que sea posible para eliminar la carga de los desarrolladores y reducir el riesgo de error humano.
6. Monitor: Las infraestructuras de nube modernas cambian y crecen. Es vital realizar un seguimiento de él, idealmente, a través de alguna forma de orquestación que permita una vista rápida de todas las diversas interconexiones.

En un código bajo o sin código entorno, estos pilares no son tan sencillos como cabría esperar. Las personas que usan estas herramientas suelen ser expertos en negocios con poca familiaridad con los fundamentos de DevSecOps.

Reuniendo personas, procesos y tecnología

El uso de plataformas low-code y no-code en realidad puede ayudar a cerrar esta brecha de habilidades. Los empleados quieren aprender nuevas habilidades. Las empresas pueden respaldar eso al establecer un marco DevSecOps que se centre en las personas, los procesos y la tecnología. 

• procesos: En un entorno de confianza cero, los desarrolladores de código bajo y sin código no tienen que preocuparse por hacer conexiones que pongan en peligro la integridad del sistema porque son incapaces de hacerlo. No tienen autoridad básica fuera de su sistema aislado.  
• Gente: Una cultura de rendición de cuentas es diferente de una cultura de culpa. La rendición de cuentas significa que las personas se sienten cómodas al presentar un problema o un error porque el enfoque está en el problema, no en la persona.
• Tecnología La tecnología es la barrera más grande para la implementación adecuada de los principios de DevSecOps porque está fuera del alcance de los desarrolladores. Deben usar lo que la organización les da. Si esa tecnología no funciona, los desarrolladores encontrarán soluciones alternativas que no son ni seguras ni seguras. Esencialmente, la tecnología se convierte en un gran generador de TI en la sombra.

Vivimos en un momento apasionante para el desarrollo. Cada vez más personas tienen la oportunidad de crear software, probar estrategias y mejorar el valor comercial. Pero con eso viene el riesgo. Las empresas que buscan formas de descargar ese riesgo en la tecnología mantendrán su desarrollo con los pies en la tierra y dejarán espacio para explorar.