KICS – ¿Cómo lo hicimos?

Comparte este artículo

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp

Ser Nativo a la Nube implica un cambio completo en la filosofía de cómo las aplicaciones modernas se diseñan, desarrollan, e implementan. Finalmente, los monolitos se divideen en microservicios pequeños y contenidos

Ser Nativo a la Nube (Cloud Native) implica un cambio completo en la filosofía sobre cómo se diseñan, desarrollan e implementan las aplicaciones modernas.

Finalmente, los monolitos se dividen en microservicios pequeños y auto-contenidos, independientes y sin conciencia de su contexto. La orquestación los une en aplicaciones que se vuelven más escalables, confiables y completamente resistentes.

La orquestación, en este contexto, se ocupa no solo de la forma en que los microservicios se comunican o están compuestos, sino también de las necesidades de infraestructura o configuraciones específicas.

Si bien no hace mucho tiempo el aprovisionamiento de infraestructura y configuración era principalmente un proceso manual, hoy en día, y con el advenimiento de la mentalidad DevOps, la automatización es omnipresente y está definida en el código. Bienvenido a la era de la Infraestructura-como-Código (IaC).

La “IaC” establece una metodología con herramientas y tecnología para la configuración y aprovisionamiento de infraestructura mediante código.

Aporta ventajas como: automatización, idempotencia (por ejemplo, replicación de infraestructura para pruebas y producción), consistencia, auto-documentación, reducción de costos, por mencionar solo algunas.

Sin embargo, de manera similar al desarrollo tradicional de software, es propenso a problemas como configuraciones incorrectas o vulnerabilidades de seguridad que pueden poner en peligro no solo una aplicación específica, sino a una escala mucho mayor, todo el negocio y su infraestructura subyacente.

¿Alguien mencionó el código y las vulnerabilidades?

Presentamos KICS (Keeping Infrastructure as Code Secure): un motor independiente de código abierto impulsado por Checkmarx, líder del mercado en análisis de código estático, para detectar vulnerabilidades, problemas de cumplimiento o configuraciones incorrectas de “IaC” en el contexto de aplicaciones nativas de la nube.

A partir de su fecha de lanzamiento, KICS viene con más de 1000 reglas de seguridad (consultas en lenguaje Cx), que admiten Terraform, Kubernetes, Docker, AWS CloudFormation y Ansible en múltiples proveedores de nube (por ejemplo, AWS, Google Cloud o Microsoft Azure).

¿Cómo hicimos KICS?

Al principio, KICS tenía solo 50 queries, residía en un repositorio privado y existía como un motor independiente. En este momento, el motor podía leer solo algunos tipos de archivos IaC, convertirlos en una representación interna y producir resultados en formato JSON.

Para convertirlo en un producto, establecimos un objetivo ambicioso de llegar a 1K consultas REGO / OPA en menos de tres meses y convertirlo en completamente open source en menos de dos.

Podría haber sido fácil si todo el equipo hubiera estado a bordo, pero la realidad no era así.

Las reglas de KICS – La fuerza de trabajo para estudiantes

En dos semanas logramos reclutar un grupo de estudiantes talentosos para unirse al equipo y enfocarnos en crear más reglas desarrolladas usando REGO.

REGO / OPA es un lenguaje declarativo de alto nivel para consultar documentos estructurados. Por este motivo, se eligió como método para obtener las reglas de exploración de IaC.

Los estudiantes recogieron el desarrollo con facilidad usando REGO y en menos de una semana de capacitación, estaban elaborando reglas y muestras de IaC (un verdadero positivo y otro verdadero negativo por consulta), siguiendo la lista recomendada de vulnerabilidades y descripciones proporcionadas por el equipo de investigación de seguridad de aplicaciones de Checkmarx.

Nuestro objetivo de crear 1000 reglas fue un gran desafío. Adaptamos nuestros procesos y diseños y creamos bibliotecas reutilizables para evitar la replicación en nuestro código REGO.

Irónicamente, con estos en su lugar, el cuello de botella se convirtió en la aprobación de Pull Requests en lugar del desarrollo en sí. En la fecha límite, no sólo se alcanzó el hito de 1K consultas, sino que se superó (~ 1.2K).

KICS Core: la búsqueda de código abierto

El enfoque inicial del equipo central estuvo en que KICS fuera completamente de código abierto.

Con la supervisión cercana y los valiosos consejos de nuestro consultor de OSS, Lior Kaplan, quien acompañó el proyecto, rompimos las dependencias con el repositorio privado, reescribimos el historial de confirmaciones para hacerlo aceptable y lo movimos al repositorio público de GitHub https://github.com/Checkmarx/kics, bajo licencia Apache 2.0.

Durante este proceso, creamos canalizaciones de CI con acciones de GitHub, manteniendo toda la infraestructura de KICS dentro del entorno de Github. En poco tiempo, estábamos ejecutando una batería de verificaciones, a partir de Pull Request, en el pipeline. Ésta aborda varios aspectos de la calidad:

  • Cobertura de prueba (con Codecov)
  • Calidad del código (con SonarCloud y Codacy)
  • Seguridad (con CxSAST de Checkmarx y el propio KICS, a través de la acción KICS GitHub)

Todas estas verificaciones son sorprendentemente rápidas y demoran aproximadamente un minuto, el tiempo necesario para tener KICS listo para su lanzamiento después de cada Pull Request exitoso.

Siempre que se apruebe el grado de calidad en cada paso de CI, KICS puede publicarse en cualquier momento. Siguiendo las mejores prácticas de código abierto, producimos:

  • Un lanzamiento nocturno, nombrado con el hash de la confirmación correspondiente.
  • Un lanzamiento oficial cada dos semanas, utilizando el estándar SemVer.

Cada versión de KICS incluye fuentes básicas, binarios para Windows, Linux y MacOS, así como una imagen de la ventana acoplable disponible en DockerHub.

Documentación de KICS: compartir la riqueza

KICS funciona. Tiene un núcleo fuerte capaz de analizar muchos tipos de archivos IaC y tiene miles de reglas de seguridad. Se lanza constantemente cada dos semanas; es de código abierto y el equipo está orgulloso de ello. ¡Solo necesitamos correr la voz por el mundo!

De hecho, creamos un sitio web y lo almacenamos en AWS. Pero esa es solo la hermosa Landing Page. El sitio de documentación se genera sobre la marcha, a través de MkDocs, a partir de archivos de rebajas y está disponible a través de las páginas de GitHub.

Intentamos hacer que la documentación de KICS sea lo más clara posible, que contenga todo sobre el proyecto, incluidas hojas de ruta, tutoriales sobre cómo usarlo o cómo contribuir.

Además, creamos una comunidad KICS usando Gitter. Algunos becarios comenzaron a comentar, a hacer preguntas y a proporcionar retroalimentación de inmediato.

Gestión de KICS – Domando a la bestia

El equipo trabaja de forma ágil, siguiendo un enfoque Kanban. Administrar el trabajo de esta manera se vuelve fácil ya que, naturalmente, podemos aprovechar las capacidades de administración integradas de GitHub.

Dividimos el trabajo en proyectos y definimos hitos para organizar mejor los problemas y solicitudes a manejar. Las etiquetas se aplican a cada problema abierto, lo que permite comprender fácilmente su naturaleza: errores, características, seguridad, consultas, mejoras, lo que sea.

Para guiar y administrar mejor las contribuciones de los usuarios de KICS, definimos plantillas para errores, funciones, nuevas consultas y solicitudes de extracción. Con las plantillas, requerimos información importante y, en última instancia, estandarizamos la calidad con la que se describe el trabajo.

En general, KICS involucra a un equipo multidisciplinario de arquitectos, desarrolladores, DevOps y gerentes. Ya tiene algunas contribuciones de seguidores y se esperan muchas más pronto.

Y tú, querido lector, eres más que bienvenido a contribuir también. No importa si es simplemente siguiendo el proyecto, proporcionando comentarios, abriendo problemas o solicitudes de funciones, enviando cambios de código o simplemente usando KICS para mantener tu IaC segura.

Nuno Oliveira

Líder del grupo de desarrollo de software

Nuno es líder del grupo de desarrollo de software en Checkmarx donde gestiona y contribuye a los equipos técnicos en las soluciones CxSAST y KICS, bajo la unidad de producto SAST. Su experiencia en análisis sintáctico y teoría y tecnología de compiladores ayudó a mejorar el análisis estático de Checkmarx en los últimos años. Nuno tiene un doctorado en Ciencias de la Computación y es profesor invitado habitual en el IPCA y la Universidade do Minho con responsabilidades de enseñanza y supervisión.

Ebook: 5 razones por las que la Seguridad del Software es más crítica que nunca