1. DevSecOps
En los últimos años, la proporción de DevSecOps introducida por las grandes empresas ha aumentado año tras año, del 41,3% en 2020 a más del 63,5% en 2022, con una tasa de crecimiento compuesto de más del 20%.
El término DevSecOps fue propuesto por primera vez por Gartner en 2012 y gradualmente se ha convertido en un tema candente en el desarrollo de software en los últimos años. DevSecOps tiende un puente entre desarrolladores, evaluadores, equipos de seguridad y equipos de operaciones; mejora la comunicación y la colaboración entre equipos, con el objetivo de realizar entregas de manera más rápida y eficiente. DevSecOps agrega actividades de seguridad sobre la base de DevOps y, para garantizar un desarrollo y una implementación rápidos, mejora la seguridad e incorpora la seguridad en las aplicaciones para responder más rápidamente a las amenazas de seguridad.
La siguiente figura muestra las nueve etapas del ciclo de vida del software DevSecOps definido por el Departamento de Defensa de EE. UU. (DOD): planificar, desarrollar, construir, probar, lanzar, entregar, implementar, operar y monitorear. La seguridad está integrada en cada etapa. El ciclo de vida de DevSecOps es altamente adaptable y tiene muchos ciclos de retroalimentación para impulsar la mejora continua. DevSecOps plantea nuevos desafíos al desarrollo de software tradicional en términos de conceptos de gestión, métodos de gestión, estructura organizacional, procesos de desarrollo, desarrollo de software, plataformas de desarrollo, integración de herramientas y cultura corporativa.
En el proceso de aplicación de DevSecOps, las herramientas de análisis estático asumen una tarea muy importante de proteger la calidad y seguridad del código durante la fase de desarrollo. Este artículo se centra en el importante papel de las herramientas de análisis estático de software en el dominio de desarrollo de DevSecOps.
2. Operaciones de seguridad y desarrollo del Departamento de Defensa
El Departamento de Defensa de EE. UU. ha publicado una serie de documentos relacionados con DevSecOps desde 2021: "Guía estratégica de DoD Enterprise DevSecOps", "DoD Enterprise DevSecOps Basics", "Diseño de referencia de DevSecOps", "Manual de acción de DevSecOps" y otros documentos de respaldo relacionados.
La Guía DevSecOps Essentials: Actividades y Herramientas se complementó en mayo de este año. En este documento, las actividades de seguridad y las herramientas correspondientes que deben completarse en el ciclo de vida de DevSecOps se definen más claramente. Las actividades de seguridad involucradas se enumeran a continuación:
| actividades de seguridad | escenario | Herramientas dependientes |
|---|---|---|
| Evaluación de riesgos cibernéticos basada en tareas | todo | Herramienta de evaluación de riesgos cibernéticos basada en tareas |
| Modelado de amenazas | plan | Herramientas de modelado de amenazas |
| Escaneo de envío de código | desarrollar | Complemento de seguridad del almacén de códigos |
| Desarrollo de código seguro | desarrollar | IDE |
| Escaneo de código estático antes del envío | desarrollar | Complemento de seguridad IDE |
| Verificación de vulnerabilidad del componente dependiente | Construir | Herramienta de verificación de dependencia/verificación de BOM |
| Pruebas y escaneo de seguridad de aplicaciones estáticas (SAST) | Construir | Herramienta de escaneo y prueba de seguridad de aplicaciones estáticas (SAST) |
| Pruebas de seguridad de bases de datos | prueba | Herramientas de cumplimiento de seguridad |
| Pruebas y escaneo de seguridad de aplicaciones dinámicas (DAST) | prueba | Herramienta dinámica de prueba y escaneo de seguridad de aplicaciones (DAST) o herramienta interactiva de prueba de seguridad de aplicaciones (IAST) |
| Pruebas de seguridad de aplicaciones interactivas (IAST) | prueba | Herramienta dinámica de prueba y escaneo de seguridad de aplicaciones (DAST) o herramienta interactiva de prueba de seguridad de aplicaciones (IAST) |
| Pruebas de seguridad manuales (como pruebas de penetración) | prueba | Varias herramientas y scripts (pueden incluir herramientas de prueba de seguridad de red) |
| Pruebas de seguridad del servicio | prueba | Herramientas de cumplimiento de seguridad |
| Análisis de seguridad posterior a la implementación | desplegar | Herramientas de cumplimiento de seguridad |
| Monitoreo de Cumplimiento (Recursos y Servicios) | monitor | Herramientas de cumplimiento, paneles operativos |
| Monitoreo de cumplimiento | monitor | Herramientas de cumplimiento, paneles operativos |
| Monitoreo de bases de datos y auditoría de seguridad. | monitor | Herramientas de cumplimiento de seguridad |
| Protección de seguridad de aplicaciones en tiempo de ejecución (RASP) | monitor | Herramientas de cumplimiento de seguridad |
| Monitoreo de seguridad del sistema | monitor | Monitoreo Continuo de Seguridad de la Información (ISCM) |
| Análisis de composición del software SBOM. | Construcción tardía | Herramienta de monitoreo continuo de riesgos de fábrica de software y SBOM |
| Monitoreo continuo de los riesgos de la fábrica de software | Construcción tardía | Herramienta de monitoreo continuo de riesgos de fábrica de software y SBOM |
| Pruebas de seguridad de interfaz | Construir | Herramientas de prueba de seguridad API |
| Pruebas cooperativas y adversarias | Operación y mantenimiento | Herramientas de prueba cooperativas y adversarias |
| Pruebas continuas de operaciones de red. | Operación y mantenimiento | Herramienta de prueba continua de operaciones de red |
| ofuscación de ingeniería | Operación y mantenimiento | Herramienta de ofuscación de ingeniería |
En esta tabla de actividades, podemos ver que hay tres puntos de control de seguridad clave durante el proceso de desarrollo, que son las partes marcadas en rojo en la tabla), y la información sobre estos tres puntos de control en el archivo se combina en la siguiente tabla:
| Actividad | base | describir | ingresar | producción | Herramientas dependientes |
|---|---|---|---|---|---|
| Análisis estático del código antes del envío. | Requerir | El código se escanea y analiza a medida que los desarrolladores lo escriben. Notifique a los desarrolladores sobre posibles debilidades del código y haga recomendaciones para su solución. | Código fuente, debilidades conocidas. | Encuentra debilidades en el código | complemento IDE |
| Verificación de confirmación de código | Requerir | Antes de enviar cambios al repositorio, verifique los cambios en busca de información confidencial. Si se encuentra contenido sospechoso, notifica a los desarrolladores y bloquea los envíos. | Código enviado localmente | Problemas de seguridad y advertencias comprobados. | Complemento de seguridad del almacén de códigos |
| Pruebas de seguridad de aplicaciones estáticas | Requerir | Realizar comprobaciones de análisis estático en sistemas de software. | Código fuente, problemas de seguridad conocidos y vulnerabilidades | Informes de inspección estática y recomendaciones de reparación. | Herramientas de análisis estático |
En esta tabla podemos ver que durante la fase de desarrollo del código, la detección del análisis estático correspondiente debe completarse en los siguientes puntos de detección:
- En el IDE, utilice el complemento de seguridad del IDE para completar las pruebas de seguridad del código que debe enviarse;
- En el almacén de códigos, el escaneo del envío de códigos se realiza a través de complementos de seguridad, que también es lo que a menudo llamamos "control de acceso";
- Durante la compilación, complete la prueba y escaneo de seguridad de aplicaciones estáticas (SAST) a través de herramientas de análisis estático.
La "Guía básica de DevSecOps: actividades y herramientas" solo presenta los requisitos de actividad y los requisitos aproximados de herramientas para los puntos de detección de procesos, y no brinda integración de procesos específica ni cómo seleccionar herramientas en diferentes puntos de detección.
3. Operaciones de seguridad y desarrollo de OWASP
El Open Worldwide Application Security Project (OWASP) es una fundación sin fines de lucro dedicada a mejorar la seguridad del software. La Fundación trabaja para mejorar la seguridad del software a través de sus proyectos de software de código abierto liderados por la comunidad, cientos de capítulos en todo el mundo, decenas de miles de miembros y la organización de conferencias locales y globales.
La Guía OWASP DevSecOps nos orienta sobre cómo implementar canalizaciones seguras y utiliza las mejores prácticas, e introduce herramientas que se pueden utilizar para hacerlo.
Guía la práctica de DevSecOps y también utiliza un capítulo especial para presentar el proceso de confirmación previa. Como se muestra abajo:
Esta imagen muestra claramente el proceso de inspección previa al envío y dos tipos de verificaciones que deben completarse durante el envío previo:
- Asegúrese de que no haya problemas de contraseña o clave en el código;
- El código sigue las reglas de Linter.
Linter aquí, no puedo encontrar una traducción china adecuada para este inglés. Linter originalmente significa que después de lavar la ropa en la lavadora, las fibras de la ropa se juntan para formar pequeñas bolas de pelusa o fibras debido a la fricción de la rodadura. Solía querer deshacerme de estas "pequeñas bolitas" adicionales, pero luego la gente inventó un artefacto llamado Linter, que puede eliminar estas "pequeñas bolitas" con solo un giro.
En 1978, Stephen C. Johnson, que trabajaba en el Experimento Bell, estaba depurando su propio proyecto en lenguaje C y de repente pensó: ¿por qué no crear una herramienta que le avisara de cualquier problema en el código que escribiera? Esta herramienta también se conoce como Linter. Linter es una herramienta de análisis estático que se utiliza principalmente para encontrar errores gramaticales, errores potenciales, estilos de codificación, etc. en el código. Nuestras herramientas comunes denominadas lint son este tipo de herramientas de verificación estática. Casi todos los idiomas tienen su propia herramienta Linter de lenguaje, como las que conocemos: Java: checkstyle , Javascript: ESLint, Python: PyLint, C/C++: cpplint , Go: golint , etc.
-
En la "Guía OWASP DevSecOps", se proporciona la función de Linter:
- Detectar errores en el código y errores que podrían generar vulnerabilidades de seguridad;
- Detectar problemas de formato o estilo y hacer que el código sea más legible, lo que resulta en un código más seguro;
- Probar las mejores prácticas recomendadas;
- Puede mejorar la calidad general del código;
- Dado que todos siguen las mismas reglas de linting, mantener el código se vuelve más fácil.
-
En la "Guía OWASP DevSecOps", las herramientas de inspección estática se definen como Linter y herramientas de inspección estática avanzadas según diferentes problemas de inspección:
-
Las herramientas Linter son la forma más básica de análisis estático. El uso de la herramienta pelusa puede ayudar a identificar errores comunes, como:
- Índice de matriz fuera de límites;
- desreferencia de puntero nulo;
- Combinaciones (potencialmente) peligrosas de tipos de datos;
- Código inaccesible (código muerto);
- Estructura no portátil.
-
Herramientas avanzadas de análisis estático. Las herramientas avanzadas de análisis estático suelen proporcionar:
- Comprobaciones basadas en patrones;
- métricas de calidad y complejidad;
- Recomendaciones de mejores prácticas para desarrolladores;
- Admite múltiples estándares de codificación centrados en la seguridad y la protección;
- Para desarrollar aplicaciones críticas para la seguridad, como la autenticación lista para usar.
-
La "Guía OWASP DevSecOps" brinda las diferencias en los tipos de defectos detectados por diferentes herramientas y explica principalmente que es necesario configurar diferentes tipos de herramientas de verificación en diferentes puntos de detección.
4. Desplazamiento seguro a la izquierda
Capers Jones explica desde la perspectiva de la práctica de la ingeniería de software en "Medición del software de aplicación: un análisis completo de la productividad y la calidad" que la mayoría de los problemas se introducen durante la fase de codificación y, a medida que los defectos se descubren más adelante en el proceso de desarrollo, es necesario solucionarlos. Cuanto mayor sea el costo.
Por lo tanto, esperamos que al integrar las pruebas posteriores al desarrollo en el proceso de desarrollo, podamos reducir efectivamente el costo de reparar los defectos introducidos durante el proceso de desarrollo.
-
Las pruebas se mueven a la izquierda de la fase de desarrollo
-
Las pruebas se desplazan hacia la izquierda y los defectos se reducen durante la fase de desarrollo.
Después de que se propuso el concepto de DevSecOps, la gente naturalmente propuso el concepto de "desplazamiento de seguridad a la izquierda" . "Security Shift Left" (como se define en la Guía OWASP DevSecOps) es un enfoque o solución que incorpora la seguridad en el proceso de desarrollo y considera la seguridad desde los pasos iniciales del diseño de la aplicación o del sistema. En otras palabras, la seguridad es responsabilidad de todos los involucrados en el proceso de desarrollo y operación del software. Por supuesto, la seguridad es una profesión y necesitamos personas altamente capacitadas para desempeñar roles relacionados con la seguridad, pero en este enfoque cualquier diseñador, arquitecto de software, desarrollador, ingeniero de DevOps y... responsable.
De esta descripción podemos ver que el turno seguro a la izquierda incluye varias actividades específicas:
- La seguridad comienza desde el diseño y continúa durante todo el proceso;
- Todos los empleados participan en actividades de seguridad;
Según nuestro conocimiento previo de la "Guía básica de DevSecOps: actividades y herramientas" del Departamento de Defensa de EE. UU. y la "Guía de DevSecOps de OWASP" de OWADSP, existen tres puntos de control en la fase de codificación del proceso de desarrollo: IDE, control de acceso y compilación continua ( CI). De acuerdo con el concepto de "desplazamiento de seguridad hacia la izquierda", ¿podemos también "ir completamente hacia la izquierda" y colocar la herramienta de inspección estática en el IDE o control de acceso para realizar el desplazamiento hacia la izquierda de la herramienta de inspección estática, eliminando así la inspección? enlace en construcción continua (CI)? ¿Es posible ir completamente hacia la izquierda?
4.1. Las historias idiomáticas “se adaptan a las condiciones locales”
Ha pasado un tiempo desde que conté una historia en mi blog. China tiene una larga historia. Los sabios integraron varios principios y filosofías sobre cómo comportarse y lidiar con las cosas en las historias. Son fáciles de entender y se convierten en historias idiomáticas de las que la gente disfruta hablando. Tienen una larga historia y permiten a la gente común Recuerda estas historias: La esencia de la filosofía se transmite de generación en generación. Además de las canciones en sí, la gente está más interesada en explorar las diversas historias conmovedoras contenidas en las canciones que Daolang se ha vuelto popular recientemente.
Al final del período de primavera y otoño, el rey de Chu creyó en la calumnia y mató a la familia de Wu Zixu. Wu Zixu huyó al estado de Wu. Para vengarse con la ayuda del Reino de Wu, Wu Zixu le dio una sugerencia al Rey de Wu: si quería hacer que el país fuera próspero y la gente estable, primero debía construir una muralla alta para fortalecer la ciudad. el poder de defensa y evitar que otros países invadan. También necesitamos fortalecer nuestra fuerza militar y enriquecer nuestras reservas de armas y suministros, para que podamos actuar como elemento disuasorio para otros países. Al mismo tiempo, se debe desarrollar la agricultura. Sólo con el desarrollo de la agricultura el país podrá ser próspero y fuerte, la gente podrá vivir y trabajar en paz y satisfacción, los soldados tendrán suministros suficientes y los graneros deben enriquecerse para preparar para las necesidades de tiempos de guerra. Sólo así el país podrá ser estable y desarrollarse. El rey de Wu estuvo muy de acuerdo con la estrategia de Wu Zixu. Así que utilizó inteligentemente la topografía del estado de Wu para construir una ciudad rodeada de montañas y ríos. Hay muchas puertas en la ciudad y tres de ellas tienen torres. Hay dos ciudades pequeñas en la gran ciudad, la del este y la del oeste: la ciudad del oeste es donde se encuentra el palacio del rey Wu y la ciudad del este es donde están estacionadas las tropas y se almacenan los armamentos. De esta manera instaló una guarnición en la ciudad, acumuló alimentos y enriqueció su arsenal como preparación para dominar a los príncipes. Después de un período de preparación, el estado de Wu gradualmente se hizo cada vez más fuerte. Al final, el ejército de Wu lanzó un ataque a gran escala contra Chu, ganó cinco de cinco batallas y finalmente capturó la capital de Chu: Yingdu. Wu Zixu finalmente vengó el asesinato de su padre y su hermano. Esta es la historia del modismo "adaptarse a las condiciones locales".
De este modismo, también nos damos cuenta de que en la etapa de desarrollo, el uso de herramientas de análisis estático no puede ser "completamente hacia la izquierda", es necesario considerar las diferencias en los puntos de detección y seleccionar las herramientas de detección adecuadas para establecer una sistema de defensa eficaz.
4.2 Establecer un sistema de protección de código de tres capas
Podemos ver claramente las diferencias entre los tres puntos de detección a través de la siguiente tabla y seleccionar diferentes herramientas de inspección estática según las diferencias, para lograr el efecto de "adaptar las medidas a las condiciones locales".
| artículo de comparación | IDE | control de acceso | CI |
|---|---|---|---|
| Rango de escaneo | código de nivel de módulo | Archivos de código con modificaciones menores. | código de ingeniería completo |
| Diferencia en el tamaño del código | Generalmente menos de <100.000 LOC | La cantidad de modificación es generalmente <500LOC y la cantidad de archivos modificados es <10 | Determinada según el tamaño del proyecto, la cantidad de código puede alcanzar cientos de millones. |
| Entorno del compilador | Algunos lenguajes tienen entornos de compilación locales y el lenguaje C requiere una configuración compleja del compilador. | Sin entorno de compilación | Tener entorno de compilación |
| Configuración de herramientas | 简单，开箱即用，可以有少量的配置，与IDE融合 | 有一定的配置，需要与pre-commit 融合 | 可以有复杂的配置用于规则的选择和规则参数的设置 |
| 工具使用 | 部分开发人员会使用 | 强制。 注：IDE检查并不能保证开发人员一定执行了检查任务，这里通过强制手段，确保代码在入库前完成基本的安全检查 |
强制 |
| 分析精度 | 要求工具误报低，但允许有少量的误报 | 要求工具工具误报更低，减少因工具误报照成不必要的反复 | 容忍一定的误报率，建议<30% |
| 分析效率 | 秒级扫描，不影响本地开发，最好事实完成检查 | 分钟级的扫描，建议<5分钟 | 小时级的扫描，在第二天上班前获得扫描结果即可 |
| 静态检查工具要求 | 编译/非编译型，单文件分析，基于语法树分析； 在不影响效率或能到依赖信息的情况下，适度的进行跨文件的分析，提高检查范围和能力 |
非编译型，单文件分析，基于语法树分析 在整体工程较小的情况下，通过CI完成全量检查 |
编译/非编译， 跨文件分析，各种检查能力 |
DevSecOps 在实施过程中除了强调工具的配合实现各个检测点的自动化，更主要的是需要提供一套完整的工具整合平台，实现整体流程的自动化运行和监管。这也是为什么大部分的企业在实施DevSecOps的时候，都选择了通过云平台支撑DevSecOps的实施方式。
5. 华为云的三层检查体系
优秀的代码质量保障实践，往往将代码检查融入到开发作业流中，在用户代码编写、代码提交时进行自动化的审计检查，并对团队每日产出的代码进行持续编程规范和质量检查。
Los requisitos prácticos de esta actividad han sido recomendados por muchos modelos de desarrollo excelentes, como SDL y DevSecOps, en el proceso de desarrollo de seguridad.
El servicio de verificación de código en la nube de Huawei (CodeArts Check) proporciona una interfaz API enriquecida que cubre todo el proceso comercial de inspección, como la creación de tareas, la configuración de tareas, el escaneo de tareas, el análisis de informes de tareas, etc., y permite a los usuarios utilizar la interfaz para integrarse sin problemas. CI/CD o CodeArts de creación propia permiten que los datos del trabajo se conecten de manera flexible a los paneles de control del cliente, lo que hace que la calidad del código sea visible y manejable.
Al mismo tiempo, a través de una gestión de tareas flexible, admite la configuración del directorio de exclusión para evitar escaneos no válidos y admite la inspección de idiomas mixtos, la implementación simplificada y la adquisición de la calidad completa del código de la versión al mismo tiempo.
Para obtener más información, consulte: Protección contra defectos de tres capas de "escritura de código, fusión de código y lanzamiento de versión", teniendo en cuenta tanto la eficiencia como la calidad.
6. Referencia
- Guía de fundamentos de DevSecOps: actividades y herramientas
- Guía de estrategia de DoD Enterprise DevSecOps
- Fundamentos de DevSecOps empresariales del Departamento de Defensa
- Manual de estrategias de fundamentos de DevSecOps
- DoD Enterprise DevSecOps: camino hacia el diseño de referencia
- Guía de desarrollo de OWASP
- Capers Jones, Medición de software aplicada: análisis global de productividad y calidad.
- ¿Qué es la prueba de desplazamiento a la izquierda? -Parasoft
Obtenga más información sobre el servicio de inspección de código de canalización de desarrollo de software de Huawei Cloud : Code Check CodeArts Check_Precise Positioning_Code Defects_Security Check_Huawei Cloud