No solo hacen falta nuevas herramientas; hace falta un enfoque fundamentalmente nuevo. DevSecOps proporciona lo que se necesita para combatir las amenazas emergentes. Al adoptar un enfoque colaborativo de la seguridad, se aprovecha el poder de toda la organización para impulsar la seguridad, en lugar de confiar en un único equipo dentro de esa organización.

El foco principal de DevOps es maximizar el flujo de creación de software: desde la concepción, hasta el desarrollo y la entrega. - Los desarrolladores quieren innovar y entregar más rápido - Los sysadmin quieren garantizar la estabilidad de los sistemas en producción y la calidad de los cambios La cultura DevOps es un conjunto de prácticas que reducen las barreras entre desarrolladores y operaciones. - Los desarrolladores están acostumbrados a procesos ágiles, como Scrum y XP, para reducir los tiempos de entrega. - Pero los procesos ágiles ya involucran también a los equipos de negocio - Sin embargo, falta incluir a los de operaciones en estos equipos La cultura DevOps es como una extensión de los procesos ágiles a todos los equipos, tanto desarrolladores como negocios y operaciones. - DevOps está muy influenciado por la tendencia al lean manufacturing

El despliegue es el "¡ya!" en "preparados, listos... ¡ya!" La integración podría ser el "¡a sus puestos!"

Muchos piensan que DevOps es un rol de TI, un híbrido entre desarrollador y administrador de sistemas. El problema de este pensamiento es que las empresas tienden a crear un nuevo silo llamado DevOps e intentan llenarlo con superadministradores que saben mágicamente de ambas cosas.

El movimiento DevOps surgió de la frustración de muchos profesionales que trabajaban con sistemas frágiles. Frágiles porque el software se construye en silos donde los diferentes equipos no se comunican entre sí de una forma eficaz. Debido a esta falta de comunicación, los desarrolladores no suelen disponer de entornos y herramientas para ser productivos, y el equipo de operaciones suele recibir el software como un "ahí llevas eso" (para que le des soporte). Los despliegues son complejos y propensos a errores. Los sistemas, cargados de deuda técnica, originan un trabajo no planificado. Los desarrolladores se ven obligados a tomar atajos, que suelen dar lugar a una arquitectura poco sólida y un retraso en los requisitos no funcionales, como la seguridad y la mantenibilidad.

DevOps es la unión de personas, procesos y productos para una entrega continua de valor a los usuarios finales. ¿Cuál es el proceso? Muy similar a los procesos ágiles, incluyendo los elementos clave descritos antes: CI/CD, monitorización, etc. ¿Qué hacen las personas? Colaborar, comunicarse y compartir responsabilidades. ¿Cómo se crea el producto? Usando herramientas que automaticen todos los elementos del proceso y faciliten la colaboración y la comunicación.

Cada uno de estos procesos tiene su propio pipeline

CI es la práctica de construir y probar las aplicaciones en cada nueva versión.

CD añade pruebas automáticas y despliegue automático al proceso de CI. Gracias a CD, el software entregado debe funcionar siempre. Todos los cambios que se incorporan en un _build_ pueden formar parte de un candidato a _release_. Antiguamente, los cambios pequeños solían tener que esperar a que se completaran otros muchos antes de ser empaquetados en una release. Siguiendo ese modelo, se suponía que el software era incorrecto hasta que era validado por profesionales de QA. Todas las pruebas se realizaban después del desarrollo, la responsabilidad de la calidad recaía exclusivamente en el equipo de QA.

El despliegue continuo es la práctica de desplegar automáticamente el software en producción después de cada cambio. La entrega es manual, el despliegue es automático.

IaC es el proceso de escribir el código de las etapas de aprovisionamiento y configuración de los componentes de la infraestructura, lo que ayuda a automatizar su implementación de manera repetible y consistente. La forma de permitir el self-service provisioning es crear un conjunto estándar de imágenes de máquinas se puedan solicitar bajo demanda. Estas imágenes representan máquinas estándar con todos los controles de seguridad, políticas y paquetes de software estándar instalados. Por ejemplo, un desarrollador que necesira un servidor web con Ruby puede seleccionar, de entre un conjunto estándar de imágenes de máquinas, un servidor de aplicaciones NGINX, un servidor de base de datos MySQL, etc. El desarrollador no tiene que configurar ninguno de estos entornos. En su lugar, solo tiene que solicitar una imagen y un entorno de destino. El entorno se aprovisiona automáticamente y el desarrollador puede empezar a trabajar.

IaC, al igual que el desarrollo software, requiere prácticas y procesos que permitan que el código de la infraestructura evolucione y se pueda mantener. - Todo debe estar automatizado en el código: hay que codificar y automatizar todos los pasos de aprovisionamiento y no dejar fuera pasos manuales que distorsionen la automatización de la infraestructura. - Al igual que el código de las aplicaciones, el código de la IaC debe estar sometido a un source control manager o SCM para poder versionarlo, rastrearlo, fusionarlo y restaurarlo. Así se tiene una mejor visibilidad del código entre Devs y Ops. - El código de la IaC debe guardarse junto al código de la aplicación, si es posible en el mismo repositorio. Así se asegura una mejor organización del trabajo entre desarrolladores y operaciones, que compartirán el mismo espacio de trabajo. - Los scripts deben tener en cuenta el estado de la infraestructura cuando se ejecutan y no generar un error si el recurso que se va a crear ya existe, o si un recurso que se va a eliminar ya se ha eliminado. Los lenguajes declarativos, como Terraform, asumen este aspecto de la idempotencia de forma nativa. Por lo tanto, la IaC, al igual que los procesos de CI/CD, es una práctica clave de la cultura DevOps que permite desplegar y configurar una infraestructura. La IaC solo puede ser eficaz con herramientas adecuadas.

El aprovisionamiento es la creación de los recursos que forman la infraestructura. Puede aprovisionarse un PaaS o un tipo de recurso serverless, como una app web, una Azure function o un Event Hub. Pero también puede aprovisionarse la parte de red que se gestiona, como VNet, subnets, tablas de encaminamiento o un cortafuegos de Azure. Para las máquinas virtuales, el aprovisionamiento solo crea o actualiza el recurso cloud de la VM, pero no su contenido. La contenerización consiste en desplegar aplicaciones en contenedores en lugar de desplegarlas en máquinas virtuales. Por ejemplo, Docker es una herramienta que permite crear, desplegar y ejecutar aplicaciones en contenedores. Las imágenes de los contenedores se crean a partir de un fichero Dockerfile. Este fichero contiene la declaración de la imagen base, que representa el sistema operativo a utilizar, middleware adicional a instalar en la imagen y la configuración de red de los puertos. Solo contiene los ficheros y binarios necesarios para la aplicación. A diferencia de las VMs, los contenedores son inmutables, es decir, la configuración de un contenedor no puede modificarse durante su ejecución.

ubuntu:latest puede incluir paquetes con vulnerabilidades No se fija versión de dependencias como python3

Las imágenes reducidas (slim/alpine) minimizan la superficie de ataque y el tamaño de la imagen. Aún así, depende de los componentes que se instalen en la imagen, ésta puede ser aún vulnerable.

IAST provides a useful tool during the testing phase. IAST solutions instrument applications by deploying agents and sensors in running applications to analyze how the application performs during runtime, which can be simulated by testing. Unlike SAST and DAST, IAST is integrated into your codebase and runs when your code runs. It should be noted that because IAST runs only when your code runs, it will not test all code but only those code paths that are executed during runtime.

Issue types (bug, vulnerability, and code smell) are deprecated. Issues are now tied to Clean Code attributes and software qualities impacted.

Un hotspot de seguridad es un fragmento de código sensible a la seguridad que se destaca, pero que no necesariamente afecta a la seguridad general de la aplicación. Depende del desarrollador revisar el código y determinar si es necesario o no una corrección para asegurar el código.

Una vulnerabilidad es un problema que impacta en la seguridad de la aplicación y que debe ser arreglado inmediatamente.

El clean code conduce a un software que es seguro, fiable y mantenible. Estos tres aspectos se denominan cualidades del software en Sonar, y contribuyen al valor a largo plazo de su software. Issue: un problema en el código que impide que sea Clean Code. Cada issue está vinculado a un atributo Clean Code que se asocia con una o más cualidades del software, cada una con un nivel de gravedad.

Tipos de vulnerabilidades de contaminación o taint (defectos de inyección de código): - inyección SQL - deserialización - inyección de comandos Su explotación puede tener consecuencias dramáticas: filtrar datos confidenciales, ejecutar código malicioso o tomar el control del servidor. Estas vulnerabilidades no se manifiestan en una sola línea de código, sino en la interacción entre múltiples secuencias de código que se encuentran en diferentes archivos y funciones. Cada secuencia de código en sí misma puede ser inofensiva, pero su combinación puede ser insegura. Es muy difícil comprender las implicaciones de seguridad de código procedente de múltiples fuentes (frameworks, librerías, etc.) Las dependencias (v.g. framework Spring o biblioteca log4j) inducen una interacción con el código de la aplicación que puede dar lugar vulnerabilidades (v.g. Log4shell). - Revisar manualmente el código propio de una aplicación es complicado. - Revisar además el código de las dependencias transitivas es imposible. SAST solo analiza el código propio de la aplicación, pero no el de las dependencias. Las herramientas de SCA informan de problemas en las dependencias basándose en una base de datos de vulnerabilidades conocidas. Esto es solo una pequeña parte. Tan sólo porque una característica de una dependencia pueda ser utilizada de forma insegura desde el código, no significa que la dependencia sea vulnerable en sí misma. Una base de datos SCA no va a listar una vulnerabilidad única que es causada por cómo se usa una dependencia en el código propio y, por lo tanto, será obviada.

El fragmento de código realiza una migración de BD para un usuario específico. Recupera un username proporcionado por el usuario [1] que se utiliza como parte del nombre de un punto de salvaguarda de la BD [7]. El punto de salvaguarda se crea con una función de la biblioteca con el nombre inocente setSavepoint() [8]. Ni un desarrollador ni una herramienta SAST tradicional pueden adivinar que esta función en particular es susceptible a la inyección SQL. Un atacante puede inyectar un nombre de usuario malicioso con sintaxis SQL en el punto de salvaguarda para modificar la consulta a la BD.

El fragmento de código muestra una vulnerabilidad de deserialización. El código recupera datos de la cabecera HTTP Session-Auth [1] y luego intenta invocar objetos Java en función de estos datos [6-8]. Si un atacante puede manipular la cabecera HTTP, los objetos Java pueden ser mal formados, lo que permite al atacante ejecutar código remoto. El paso crítico sucede en [3]. La función externa decodeBase64() procesa los datos. Si la herramienta SAST no es consciente de lo que hace esta función en [3], no puede establecer la conexión entre [1] y [8] y no detectará la vulnerabilidad.