El analizador de riesgos de código de IBM Cloud Continuous Delivery escanea el código fuente de Python, Node.js y Java en los repositorios de Git en busca de riesgos legales y de seguridad.
por Paul Krill
Con el objetivo de llevar la analítica de seguridad y cumplimiento a devops , IBM ha agregado su capacidad Code Risk Analyzer a su servicio IBM Cloud Continuous Delivery .
IBM describe Code Risk Analyzer como una medida de seguridad que puede configurarse para ejecutarse al inicio de la canalización de código de un desarrollador, analizando y revisando los repositorios de Git para descubrir problemas con el código fuente abierto. El objetivo es ayudar a los equipos de aplicaciones a reconocer las amenazas de ciberseguridad, priorizar los problemas de seguridad de las aplicaciones y resolver los problemas de seguridad. IBM Cloud Continuous Delivery ayuda a aprovisionar cadenas de herramientas, automatizar pruebas y compilaciones, y controlar la calidad del software con análisis.
IBM dijo que a medida que las prácticas de desarrollo nativas de la nube, como los microservicios y los contenedores, cambian los procesos de seguridad y cumplimiento, ya no es posible que los equipos de operaciones centralizados administren la seguridad y el cumplimiento de las aplicaciones. Los desarrolladores necesitan capacidades nativas de la nube, como Code Risk Analyzer, para integrarse en los flujos de trabajo existentes. Code Risk Analyzer ayuda a los desarrolladores a garantizar la seguridad y el cumplimiento en los flujos de trabajo de rutina.
Al desarrollar Code Risk Analyzer, IBM examinó los artefactos de origen utilizados por las organizaciones de TI para crear y desplegar aplicaciones y para aprovisionar y configurar la infraestructura de Kubernetes y los servicios en la nube. Las soluciones en la nube existentes proporcionan controles de seguridad limitados en todo el espectro del código fuente, incluido el escaneo de vulnerabilidades de los manifiestos de aplicaciones. Por lo tanto, es necesario diseñar una solución que abarque la evaluación de la seguridad y el cumplimiento en todos los artefactos.
Code Risk Analyzer escanea repositorios de código fuente basados en Git para Python, Node.js y código Java y realiza verificaciones de vulnerabilidad, verificaciones de administración de licencias y verificaciones de cumplimiento de CIS (Centro para la seguridad de Internet) en las configuraciones de implementación y generar una “lista de materiales” para todas las dependencias y sus fuentes. Los archivos de Terraform que se utilizan para aprovisionar servicios en la nube, como Cloud Object Store, se analizan para encontrar errores de configuración de seguridad.
IBM buscó anclar los controles de seguridad en estándares como NIST o CIS y aplanar la curva de aprendizaje mientras presentaba a los usuarios nuevas prácticas de seguridad. Los desarrolladores están protegidos de tener que comprender las definiciones y políticas de seguridad, con comentarios prácticos proporcionados.
Fuente: https://www.infoworld.com/article/3588100/ibm-adds-code-risk-analyzer-to-cloud-based-cicd.html
Cómo llevar la seguridad al desarrollo ágil y CI / CD
Alinee a DevSecOps y cambie la seguridad a la izquierda para mejorar las prácticas de codificación, eliminar vulnerabilidades en el desarrollo y entregar aplicaciones altamente seguras a producción.
por Isaac Sacolick
Devops surgió debido a los muros culturales, funcionales y técnicos entre los equipos de desarrollo que desean lanzar con frecuencia y los equipos de operaciones que necesitan preservar la confiabilidad y la estabilidad. La cultura de Devops aborda la mentalidad, la colaboración y las prácticas para lograr tanto los objetivos como las prácticas de Devops, incluida la integración y entrega continuas (CI / CD) , la infraestructura como código (IaC) y AIOps , que aprovecha el aprendizaje automático en el monitoreo de aplicaciones , habilita el implementación.
A medida que más personas y organizaciones adoptaron devops , quedó claro que el término “devops” no llegaba a describir la amplitud completa del movimiento, sus prácticas y requisitos. Una vez mencioné la necesidad de DevQaOps y recomendé prácticas de prueba de cambio a la izquierda donde sea posible.
Pero igualmente importante, si no más importante, es la necesidad de que todos sean responsables de la seguridad . Cambiar la seguridad al desarrollo y las operaciones, o DevSecOps, lo ayuda a lograrlo.
La seguridad del software comienza con los desarrolladores
Antes de devops, los equipos de desarrollo a menudo implementaban prácticas de seguridad en las etapas finales del proceso de lanzamiento de una aplicación, generalmente como un paso requerido por una junta asesora de cambios (CAB) . Debido a que los equipos de seguridad llegaron tarde en el proceso, tenían un tiempo limitado para conocer los requisitos comerciales, comprender los cambios técnicos, evaluar los riesgos y ejecutar pruebas de seguridad. Cuando los equipos de seguridad aumentaron los problemas, hubo un tiempo limitado para solucionar los problemas sin afectar los plazos, y los problemas que requerían cambios sustanciales en el código dejaron a los equipos de desarrollo con decisiones difíciles.https://imasdk.googleapis.com/js/core/bridge3.424.1_es.html#goog_2146015270Volumen 0%00:2908:37
Probar la seguridad al final del proceso de lanzamiento puede ser un riesgo crítico para los equipos de DevOps que están aumentando la frecuencia de lanzamientos o invirtiendo en microservicios. En el informe Accelerate: State of DevOps 2019 , publicado por DORA y Google Cloud, el 43% de los encuestados se identifican como de alto rendimiento o élite que lanzan aplicaciones diaria o semanalmente. Eso es un aumento significativo en las implementaciones de producción, una tasa que requiere un enfoque integrado para implementar las mejores prácticas de seguridad con frecuencia y en las primeras etapas del proceso de desarrollo.
La colaboración entre los equipos de desarrollo ágiles y la seguridad de la información es necesaria en las siguientes áreas:
- Revisar los requisitos de seguridad, la arquitectura y las prácticas de codificación.
- Instrumentación de pruebas de seguridad automatizadas en canalizaciones de CI / CD
- Supervisión de aplicaciones en busca de amenazas y resolución de problemas de seguridad
Ofreceré algunas pautas para abordar cada una de estas áreas en las secciones siguientes.
Colaborar en los requisitos de seguridad, la arquitectura y las prácticas de codificación.
Los equipos de desarrollo y la seguridad informática deben asociarse en materia de seguridad en las primeras etapas del proceso de desarrollo ágil, incluso antes de que comience la codificación. En el informe State of DevOps de 2019 , publicado por Puppet, CircleCI y Splunk, los autores identifican varias prácticas recomendadas sobre cómo deben colaborar los equipos de desarrollo e infosec:
- Los equipos de seguridad y desarrollo deben colaborar en modelos de amenazas.
- Los requisitos de seguridad funcionales y no funcionales deben priorizarse en la cartera de productos.
- Los requisitos de seguridad deben tratarse como restricciones de diseño.
Los equipos de desarrollo ágiles pueden implementar estas prácticas señalando los requisitos e implementaciones de mayor riesgo de seguridad para las revisiones de seguridad. El desarrollo debe asociarse con infosec sobre los requisitos, la arquitectura, el diseño y la implementación de las partes de la aplicación que capturan la información del usuario, administra las autorizaciones o procesa los datos confidenciales.
Para cambios de codificación menos riesgosos, los equipos ágiles deben escribir criterios de aceptación de historias de usuario que aborden los requisitos y restricciones de seguridad de infosec.
Los desarrolladores ágiles también deben revisar los principios de seguridad por diseño de OWASP , que incluyen varias mejores prácticas:
- Establecer políticas predeterminadas basadas en la seguridad en áreas como el vencimiento de contraseñas
- Implementar el principio de privilegio mínimo al definir roles y otorgar acceso a los procesos comerciales
- Comprender los principios de seguridad como la separación de funciones, los servicios de “no confianza”, la minimización de las áreas de superficie de ataque y la prevención de la seguridad por oscuridad
- Solucionar problemas de seguridad rápidamente mediante la comprensión de las causas fundamentales y la implementación de soluciones integrales
Por último, los equipos de desarrollo e infosec deben establecer conjuntamente una referencia para las mejores prácticas de codificación. Algunos buenos puntos de partida incluyen las prácticas de codificación de Carnegie Mellon University , las mejores prácticas de Safe Computing de la Universidad de Michigan y las mejores prácticas de codificación de seguridad para los lenguajes de programación y las plataformas utilizadas.
Si está implementando aplicaciones en nubes públicas, también debe revisar las mejores prácticas, como la seguridad de AWS por diseño , el sitio sobre el diseño de aplicaciones seguras en Azure y la descripción general de seguridad de Google Cloud .
Prueba de seguridad en canalizaciones de CI / CD
La siguiente etapa para considerar la seguridad son las canalizaciones de CI / CD, donde el código automatizado y las validaciones de seguridad pueden romper las compilaciones y alertar a los desarrolladores. Algunas de las prácticas y herramientas de seguridad más comunes a considerar al establecer estándares de canalización de CI / CD:
- Las plataformas de pruebas de seguridad de aplicaciones estáticas (SAST) como SonarQube , Veracode , Sentinel Source y Checkmarx escanean el código en busca de diferentes vulnerabilidades y patrones. Por ejemplo, SonarQube busca entradas incorrectas (análisis de contaminación), secuencias de comandos entre sitios, exposición de datos confidenciales y vulnerabilidades conocidas. Veracode afirma que han escaneado más de 11 billones de líneas de código y tienen una tasa de falsos positivos de menos del cinco por ciento. Checkmark funciona con más de 20 lenguajes de programación y cumple con PCI-DSS, HIPAA, FISMA y otros estándares regulatorios. Las tres herramientas funcionan en muchos IDE y plataformas CI / CD. También hay opciones de herramientas SAST de código abierto como CodeWarrior y NodeJsScan. OWASP enumera más de 20 herramientas SAST y afirma que sus debilidades incluyen encontrar problemas de configuración y vulnerabilidades en la autenticación y el control de acceso.
- Las herramientas de análisis de dependencias revisan los componentes de software subyacentes, incluidas las bibliotecas de código abierto, y notifican vulnerabilidades. GitLab Secure tiene SAST y otras herramientas de seguridad, incluida la verificación de dependencias, y funciona con Java, JavaScript, PHP, Python, Ruby, Scala y Go. OWASP Dependency Check tiene integraciones para Jenkins, CircleCI y SonarQube. Snyk Open Source Security Manager permite a los desarrolladores encontrar y corregir vulnerabilidades de código abierto. Microsoft lanzó recientemente Application Inspector , una herramienta de análisis de código que informa sobre 400 patrones, incluidas características que afectan la seguridad.
- Las pruebas de penetración han existido por un tiempo, pero tradicionalmente, muchas organizaciones tienen equipos de seguridad que ejecutan estas pruebas independientemente del código, compilan e implementan procesos en el ciclo de vida de desarrollo de software (SDLC). Una de las herramientas más populares, OWASP Zed Attack Proxy o OWASP ZAP , puede conectarse a herramientas CI / CD como Jenkins y desencadenar implementaciones. En la serie All Day DevOps sobre ZAP in Ten , Simon Bennetts, líder del proyecto ZAP, señala: “Cuanto antes se use, mejor. ZAP realmente brilla con la automatización “.
- Devops, la nube y las herramientas de desarrollo generalmente ofrecen sus propios complementos de seguridad. Por ejemplo, tanto Jenkins como Azure DevOps tienen más de 40 complementos de seguridad, mientras que CircleCI enumera más de 20 . Microsoft Azure ha publicado sus metodologías de seguridad continua , mientras que AWS proporciona pautas de DevSecOps para los usuarios de CodePipeline . Dado que las tecnologías de seguridad, las integraciones y las herramientas de devops están evolucionando rápidamente, los equipos de seguridad y desarrollo deben revisar periódicamente estas herramientas en busca de nuevos complementos de seguridad.
- Otra consideración importante es asegurar la propia canalización de CI / CD . Por ejemplo, proteger las claves y los parámetros es fundamental para la seguridad, y CircleCI , Jenkins y Azure proporcionan herramientas y recomendaciones para bloquearlos.
Cerrando el ciclo de seguridad con monitoreo y AIOps
Existe un conjunto completamente diferente de disciplinas DevSecOps vinculadas a proteger la infraestructura como código, fortalecer los contenedores y configurar los servicios en la nube. Además, hay temas especializados de DevSecOps sobre seguridad de datos, gestión de identidades y protección de dispositivos de IoT. Si sus proyectos de ingeniería y desarrollo cubren infraestructura, dispositivos móviles, redes, IoT o análisis, también encontrará prácticas y herramientas de seguridad especializadas en estas áreas.
Más allá de la infraestructura y la seguridad de los datos, cualquier persona que trabaje en el desarrollo de aplicaciones debe comprender mejor cómo funcionan las aplicaciones en los entornos de producción. La revisión de incidentes, la participación en el análisis de la causa raíz y la reparación de defectos son responsabilidades fundamentales del desarrollo de aplicaciones. Para los desarrolladores, esto a menudo significa mejorar el registro y revisar los análisis de las herramientas de monitoreo de aplicaciones.
Una tecnología operativa emergente es AIOps , que aprovecha el aprendizaje automático y la automatización para simplificar devops y el monitoreo de aplicaciones. Los equipos de operaciones suelen trabajar con varias herramientas de supervisión diferentes, pero hacer malabarismos con varias herramientas puede ralentizar los esfuerzos para resolver incidentes, especialmente en entornos complejos de múltiples nubes, y especialmente cuando los equipos de desarrollo implementan cambios con frecuencia.
Las herramientas AIOps agregan datos operativos de múltiples herramientas de monitoreo, archivos de registro de aplicaciones o componentes de infraestructura. Luego, aplican el aprendizaje automático para ayudar a identificar incidentes, activar respuestas automatizadas y reducir el tiempo para resolverlos. Estas herramientas también ayudan a descubrir valores atípicos y problemas que evolucionan lentamente al examinar los datos operativos longitudinales. Se pueden encontrar muchos problemas de seguridad utilizando este tipo de análisis.
La revisión de las herramientas de monitoreo y AIOps para los problemas de seguridad es la forma en que los equipos de seguridad e infosec incorporan los incidentes de seguridad operativa al proceso de desarrollo ágil para su corrección. Esta es una postura de seguridad reactiva, pero una práctica de suma importancia para los equipos ágiles y las organizaciones de desarrollo que se esfuerzan por administrar y mejorar la seguridad de sus aplicaciones.
Abordar la seguridad del software requiere una combinación de pasos proactivos instituidos al comienzo del proceso de desarrollo ágil, mejores prácticas e instrumentos en la línea de desarrollo y medidas reactivas basadas en sistemas de producción de monitoreo. Las amenazas de seguridad cambian rápidamente, por lo que los equipos ágiles y las organizaciones de DevOps necesitan revisar las prácticas de seguridad y validar nuevas metodologías continuamente.
Fuente: https://www.infoworld.com/article/3520969/how-to-bring-security-into-agile-development-and-cicd.html
