Es importante comprobar si el código de la aplicación presenta errores, tanto si se trata de uno personalizado en un lenguaje propio como de otro ensamblado a partir de múltiples bibliotecas de código abierto. Las tecnologías como SAST, DAST, SCA e IAST tienen un propósito y existen por una buena razón, pero hay más opciones a la hora de proteger una aplicación nativa en la nube más allá de desplazar el testeo a la izquierda e implementar código seguro (en los Mitos 5 y 6 hablaremos sobre la importancia de «desplazar el testeo a la izquierda»).
Ejemplos en los que centrarse solo en el código de la aplicación NO FUE suficiente
Por ejemplo, el mejor código del mundo no protegerá contra un caso en el que, durante el tiempo de ejecución, las imágenes, que deberían ser inmutables y no cambiar nunca en la fase de producción, comienzan a ejecutar comandos que no estaban incluidos en la imagen base (Ver Mito 5). El código tampoco evitará las configuraciones erróneas del orquestador como, por ejemplo, no desactivar el acceso anónimo al servidor API de K8s, lo que podría permitir a un atacante tomar el control de todo un clúster y un conjunto de nodos. Y tampoco protegerá contra las desconfiguraciones de las cuentas en la nube que pueden dejar servicios enteros abiertos a los atacantes, como cuando la CPU se estaba utilizando para minar criptomonedas porque su consola administrativa de Kubernetes no estaba protegida con contraseña.
Desplazar el testeo a la izquierda, como veremos en el Mito 5, es un concepto clave y supone un cambio de mentalidad para los equipos de seguridad que protegen las aplicaciones nativas en la nube, pero estos equipos deben seguir estableciendo medidas de control en la compilación, la infraestructura y las cargas de trabajo.
