Puntos clave: Incorporar la seguridad como código en los Pipelines CI/CD integra las prácticas de seguridad desde el principio del desarrollo, evitando que las vulnerabilidades se conviertan en cuellos de botella. Cinco mejores prácticas aseguran que las comprobaciones de seguridad y cumplimiento son integradas a lo largo de todo el ciclo de vida del desarrollo.
- Define y codifica las políticas de seguridad desde el principio.
- Prueba la seguridad en el check-in del código para identificar vulnerabilidades a tiempo.
- Automatiza las comprobaciones de cumplimiento de forma continua a lo largo de la pipeline.
Este es el cuarto blog de nuestra miniserie que ilustra cómo BMC utilizó el desarrollo ágil, servicios en la nube, un enfoque de Infraestructura como Código y nueva tecnología de despliegue para ofrecer un producto nativo en la nube. No olvides leer también: Empezar con aplicaciones nativas en la nube, 9 pasos para construir Pipelines para entrega y despliegue continuos, e infraestructura, y cómo "Todo como código" lo cambia todo. Incorporar seguridad como código en una pipeline CI/CD significa tratar políticas de seguridad, pruebas y comprobaciones de cumplimiento como artefactos versionados y automatizados que se ejecutan en cada etapa de entrega—detectando vulnerabilidades durante el desarrollo y no en el momento de la liberación. Las cinco mejores prácticas que se muestran a continuación muestran cómo los equipos de ingeniería pueden integrar directamente los principios de Seguridad-Como-Código y Cumplimiento como Código en una cadena de entrega continua para mantener tanto la seguridad como la velocidad.
¿Por qué importa la seguridad como código en una pipeline CI/CD?
Cuando la seguridad no está integrada desde el Comienza, se convierte en un cuello de botella en el peor momento posible. A medida que una versión se acerca a la preparación para el despliegue, los equipos se son enfrentados a una etapa avanzada de escaneo de vulnerabilidades, pruebas de penetración y modelado de amenazas, ejecutadas mediante herramientas manuales, listas de comprobación y documentos de revisión. Cuando surgen vulnerabilidades críticas o de alto nivel en esta etapa, las versiones se estancan durante semanas o meses mientras se resuelven sus problemas. El principio de Seguridad como Código elimina este cuello de botella al codificar las prácticas de seguridad y automatizar su ejecución como parte de una cadena de procesamiento DevOps . La seguridad y el cumplimiento normativo son aplican de forma continua—en el caso utiliza , en las etapas de diseña, desarrollo y pruebas de la entrega de aplicaciones—en lugar de deferirse a una revisión previa al lanzamiento. Las políticas, pruebas y resultados de seguridad son tratados como artefactos de código de primera clase: versionados en el mismo repositorio y progresados a través de la misma cadena CI/CD que el código de aplicación.
¿Cuáles son las cinco mejores prácticas para aplicar la seguridad y el cumplimiento conforme al código?
Las siguientes prácticas son extraídas de la experiencia de BMC construyendo una aplicación nativa en la nube en Amazon Web Services (AWS). Cada una aborda una capa distinta del enfoque Security-As-Code, desde la definición inicial de políticas hasta la remediación en producción.
1. Define y codifica las políticas de seguridad
Las políticas de seguridad deben definirse al Comienza de un proyecto y almacenarse en un repositorio de código fuente junto con el código de la aplicación. Para una aplicación nativa en la nube en AWS, esto incluye requisitos como:
- Grupos de seguridad y cortafuegos asegurados
- Nube Privada Virtual (VPC), Elastic Load Balancing y servicios relacionados reforzados y seguros
- Todos los EC2 y otros recursos deben residir dentro de la VPC y estar protegidos individualmente por cortafuegos
- Todos los recursos y registros de AWS cifrados usando Servicios de Gestión de Claves
Las políticas de seguridad también deben estar automatizadas: una sola acción debe poder evaluarlas para cualquier aplicación en cualquier etapa o entorno. Todo lo relacionado con la seguridad está codificado, versionado y automatizado; los artefactos de seguridad son registrados en un repositorio igual que el código de la aplicación. Las empresas deberían construir patrones de seguridad estandarizados para Permite la reutilización entre organizaciones y aplicaciones. Una aplicación de 3 niveles y un entorno de nube de desarrollo/prueba, por ejemplo, requieren cada uno su propia plantilla estándar de seguridad. Con AWS, las cinco plantillas de NIST AWS CloudFormation pueden reforzar redes, VPCs y roles de gestión de identidad y accesos, formando una base de "nube reforzada". Para infraestructura de nube privada o On-premises, BMC BladeLogic Server Automation se encarga del endurecimiento de servidores.
2. Define historias de usuario de seguridad y evalúa el riesgo de la arquitectura de aplicaciones
Las historias de usuario relacionadas con la seguridad deben definirse en el proceso ágil como cualquier otra historia de funcionalidad. Ejemplos incluyen:
- "Validación de entrada para scripting multi-sitio e inyección SQL"
- "SSL/TLS habilitado para toda comunicación"
- "Pruebas automatizadas de seguridad de aplicaciones"
Esta práctica garantiza que la seguridad nunca están tratada como opcional o diferida. Los controles de seguridad son identifican en función de los modelos de riesgo y amenaza de la aplicación tanto para la arquitectura de la aplicación como para la infraestructura, y luego se implementan en el código de la aplicación o mediante políticas.
3. Probar y remediar la seguridad en el check-in del código de aplicación
Las pruebas de seguridad deben activarse automáticamente tan pronto como se están registrado el código, tanto para cambios en la aplicación como en la infraestructura. Muchas herramientas de escaneo de vulnerabilidades de seguridad son disponibles de BMC, proveedores externos y proyectos de código abierto para automatizar la detección y remediación. Cuando se detectan vulnerabilidades críticas o de alto son, las herramientas de automatización pueden generar defectos o tickets asignados al propietario del componente para su resolución. Para aplicaciones nativas en la nube, las pruebas en el check-in de código implican evaluar artefactos de infraestructura como código—como las plantillas de AWS CloudFormation—frente a políticas de seguridad definidas.
4. Probar las políticas de seguridad para asegurarse de que no violan los requisitos
Las propias políticas de seguridad deben ser probadas para asegurarse de que no permiten configuraciones conocidas como defectuosas. Ejemplos de comprobaciones de violaciones de políticas incluyen:
- "Ningún bucket S3 debe ser legible o escribible públicamente"
- "No utilicéis grupos de seguridad abiertos con 0.0.0.0/todo el tráfico permitido"
Estas pruebas deben automatizarse como parte de la cadena de entrega de aplicaciones. En la cadena de BMC para su aplicación nativa en la nube, son orquestados escaneos de seguridad desde Spinnaker para validar cada envío a producción. Para comprobaciones de cumplimiento regulatorio —como los requisitos del Center for Internet Security (CIS) y la Defense Information Systems Agency (DISA) en servidores, bases de datos y redes— la suite de productos BMC BladeLogic puede Detecta y remediar violaciones de cumplimiento.
5. Probar y remediar la seguridad y el cumplimiento en producción
Las pruebas automatizadas de seguridad y cumplimiento continúan a medida que una aplicación avanza en entornos de desarrollo, control de calidad y pruebas. El riesgo de encontrar problemas críticos en esta etapa está menor porque la mayoría de la automatización de seguridad se ejecuta mucho antes en la cadena. Para entornos de producción, BMC BladeLogic Server Automation y BMC Threat Director soportan la aplicación de parches de seguridad tras escanear los servidores de producción en busca de infraestructura mutable. Este paso sigue siendo fundamental: más del 80% de los ataques apuntan a vulnerabilidades conocidas y el 79% de las vulnerabilidades tienen parches disponibles el día de la divulgación. Para aplicaciones desplegadas en nubes públicas como AWS, las evaluaciones de seguridad y cumplimiento pueden automatizarse mediante Spinnaker. En las pilas nativas de la nube modernas, los componentes nunca son parcheados en su lugar: son reemplazados por completo. Aun así, los nuevos contenedores o servidores deben pasar pruebas de seguridad y cumplimiento antes de ser desplegados en producción.
Desplazamiento a la izquierda: Comienza la seguridad al principio
El principio shift-left significa trasladar la seguridad desde el final del proceso de lanzamiento hasta el principio—y mantenerla presente durante toda la pipeline DevOps. En lugar de tratar la seguridad como una puerta final o realizar escaneos periódicos de los entornos de producción, los equipos integran prácticas de Security-As-Code en cada etapa de la entrega, desde la definición de políticas al inicio del proyecto hasta las comprobaciones automatizadas de cumplimiento en producción. Al codificar políticas, automatizar pruebas e integrar el cumplimiento en la pipeline CI/CD desde el primer día, los equipos de producto pueden mantener tanto la seguridad como la velocidad de la innovación.
Preguntas frecuentes sobre la seguridad como código en CI/CD
¿Cuál es la diferencia entre la seguridad como código y DevSecOps? La seguridad como código es una práctica específica dentro de DevSecOps que implica tratar las políticas de seguridad, pruebas y comprobaciones de cumplimiento como artefactos de código versionados y automatizados almacenados en un repositorio fuente. DevSecOps es la práctica cultural y organizativa más amplia que integra las responsabilidades de seguridad a lo largo de todo el ciclo de vida del desarrollo de software: la seguridad como código es la implementación técnica que hace que DevSecOps sea accionable. ¿Qué significa "desplazamiento a la izquierda" en el contexto de las pruebas de seguridad? Desplazarse a la izquierda significa avanzar las pruebas y validaciones de seguridad antes en el proceso de desarrollo—idealmente hasta el punto de revisión del código—en lugar de esperar hasta la fase de etapas o liberación. En una cadena de Security-As-Code, las comprobaciones de seguridad automatizadas se ejecutan en cada commit, detectando vulnerabilidades en la fase de desarrollo, donde son más baratas y rápidas de solucionar. ¿Qué herramientas soportan pruebas de seguridad automatizadas en una pipeline CI/CD? Las herramientas más comunes incluyen escáneres de vulnerabilidades, validadores de políticas de infraestructura como código y plataformas de automatización de cumplimiento . BMC BladeLogic Server Automation, BMC Threat Director y organizadores de pipelines como Spinnaker son ejemplos de herramientas que soportan pruebas automatizadas de seguridad y cumplimiento en entornos de desarrollo, QA y producción. ¿Por qué son importantes los patrones de seguridad estandarizados para aplicaciones en la nube? Los patrones de seguridad estandarizados permiten a los equipos reutilizar configuraciones de seguridad probadas —como plantillas reforzadas de VPC o políticas de almacenamiento cifradas— en múltiples aplicaciones y entornos. Esto elimina la necesidad de que cada equipo Define la seguridad desde cero y garantiza una cobertura de seguridad consistente y lista para usar en toda la organización. Las plantillas de NIST AWS CloudFormation son un ejemplo de un patrón de nube reforzado reutilizable. ¿Cómo Reduce Security-As-Code los retrasos en la publicación causados por revisiones de seguridad? Al automatizar las comprobaciones de seguridad y cumplimiento en el check-in del código y a lo largo de toda la pipeline CI/CD, Security-As-Code detecta vulnerabilidades durante el desarrollo en lugar de en el momento de la liberación. Esto elimina las evaluaciones manuales de seguridad de última hora —pruebas de penetración, análisis de vulnerabilidades, modelado de amenazas— que tradicionalmente detienen los despliegues durante semanas o meses cuando son detectan problemas críticos cerca de la producción. Las opiniones y puntos de vista expresados en esta publicación son los del autor y no reflejan necesariamente la posición oficial de BMC.
Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.