El enfoque shift left de Snyk para el desarrollo de API
Terence Tirella
1 de febrero de 2022
0 minutos de lecturaLa plataforma de seguridad para desarrolladores de Snyk ofrece a desarrolladores y profesionales de seguridad las herramientas que necesitan para crear y operar aplicaciones modernas de forma segura. Snyk permite a los usuarios aplicar el enfoque shift left a la seguridad y adoptar un modelo de DevSecOps. Los equipos modernos de desarrollo de aplicaciones entienden que aplicar el enfoque shift left significa poner la información al alcance de los desarrolladores lo antes posible en el proceso de desarrollo, para crear aplicaciones y procesos de desarrollo eficientes y seguros.
En Snyk, aplicamos este mismo enfoque shift left al desarrollar las API y aplicaciones que impulsan nuestra plataforma. El desarrollo de API, como otras tareas especializadas, requiere desarrollar procesos específicos y usar las herramientas adecuadas. Como plataforma API-first, es fundamental recibir comentarios sobre nuestros contratos de API lo antes posible. Las API de Snyk dan a los usuarios, tanto dentro como fuera de Snyk, acceso a nuestros productos de seguridad líderes en la industria. Los desarrolladores confían en Snyk y nuestras API para impulsar su SDLC y permitirles crear aplicaciones seguras. Ofrecer API de alta calidad es fundamental para el éxito de nuestra plataforma, y contar con un proceso de desarrollo de API de alta calidad es clave para ofrecer esas API a los usuarios.
En esta publicación del blog, exploraremos algunos de los procesos y herramientas que usa Snyk para crear nuestra plataforma API-first.
¿Por qué aplicar el enfoque shift left?
Desde hace mucho tiempo, las organizaciones de software reconocen el valor de aplicar el enfoque shift left a las pruebas, las operaciones y la seguridad. En lugar de esperar a que las revisiones se realicen más adelante en el SDLC, los desarrolladores pueden recibir comentarios rápidamente con técnicas como la integración continua y herramientas como los complementos de IDE de Snyk. El resultado es una entrega más rápida, una postura de seguridad mejorada, costos reducidos y, en general, un proceso de entrega de aplicaciones más confiable. El mismo enfoque shift left también se aplica al desarrollar API. Es mejor recibir comentarios pronto, idealmente con herramientas automatizadas.
Guías de estilo y el enfoque de Snyk
El desarrollo de API RESTful es un tipo particular de desarrollo de aplicaciones que requiere los procesos y las herramientas adecuados. Las API V3 de Snyk están diseñadas para ofrecer a los usuarios formas confiables, uniformes, fáciles de entender e innovadoras de interactuar con la plataforma subyacente. En Snyk, definimos nuestras API con OpenAPI (también conocido como Swagger), el estándar de facto para definir API RESTful. Sin embargo, tener una especificación de API en un formato legible para máquinas y personas no significa que las API cumplirán nuestros objetivos de usabilidad. Los usuarios necesitan que las API sean uniformes en toda la plataforma para poder interactuar fácilmente con sus diferentes partes.
Para ofrecer una API uniforme, necesitamos estándares de estilo. Muchas organizaciones usan una guía de estilo para indicar a quienes crean contenido cómo lograr un tono y estilo uniformes en sus textos. En Snyk, desarrollamos nuestra propia guía de estilo para el desarrollo de API. Es nuestro API Stylebook para los equipos que crean API. A medida que nuestra organización crece y más desarrolladores crean API, nuestro estilo de API nos ayuda a lograr uniformidad y ofrecer a los usuarios una experiencia uniforme para desarrolladores. Pero contar con una guía de estilo es solo parte de la solución. También necesitamos mecanismos que ayuden a nuestros desarrolladores a garantizar que la cumplan.
Una forma de garantizar el cumplimiento es hacer una revisión manual. Como nuestras API se especifican en OpenAPI y se mantienen bajo control de versiones, podemos seguir el mismo proceso de revisión que usamos para otros artefactos de código. Los desarrolladores pueden crear pull requests (PR) para sus cambios en las API y pedir comentarios a un colega. Este proceso manual puede ser eficaz para garantizar el cumplimiento, pero, como todos los procesos manuales, está sujeto a errores humanos y no siempre es oportuno. Snyk es una empresa global con un modelo de trabajo remoto desde el principio. Esperar a que un colega revise tu PR de API puede demorar el proceso y afectar la productividad, sobre todo en los aspectos de la revisión que se pueden automatizar. Aquí es donde resulta útil nuestro enfoque de aplicar shift left con revisiones automatizadas de API.
Los desarrolladores de Snyk que crean API cuentan con los tres elementos necesarios para realizar un proceso local de revisión automatizada:
El estándar de API de Snyk, expresado como una serie de reglas
La API que escribieron en OpenAPI
Herramientas de linting que validan si la especificación de OpenAPI escrita por el desarrollador cumple las reglas de la especificación
Los desarrolladores que cuentan con herramientas locales de linting para sus API pueden recibir comentarios en tiempo real sobre ellas. Esto permite que los desarrolladores de Snyk corrijan problemas en sus API antes de llegar a la etapa de revisión manual. El linter también se puede integrar con nuestros trabajos de CI para comprobar el cumplimiento. Como todos los equipos de desarrollo usan las mismas reglas, la plataforma Snyk puede ofrecer a nuestros usuarios una experiencia de API más uniforme.
Colaboración con Optic
Una vez que decidimos representar nuestro modelo de datos con REST, empezamos a definir nuestro estándar de API con JSON API. Cuando tuvimos un borrador del estándar, nos propusimos convertirlo en algo ejecutable: un estándar como código que evitara bloquear a los equipos de desarrollo con una «revisión experta de API». Nuestro objetivo era ofrecer comentarios rápidos como parte de nuestra filosofía shift left.
Las herramientas iniciales que encontramos para crear estas reglas eran excelentes para la verificación sintáctica mediante coincidencia de patrones, como el linting para validar OpenAPI 3. Sin embargo, pronto descubrimos las limitaciones de este enfoque al aplicarlo para implementar nuestros estándares de API. Estas reglas son tediosas de leer y escribir (JSONPath y expresiones regulares), y solo pueden expresar restricciones sobre el contenido de la versión actual de la especificación de API que se evalúa. Decidimos que necesitábamos una solución más robusta y descubrimos que Optic era una excelente opción.
Optic es un socio que busca aplicar el enfoque shift left a sus productos de revisión y gobernanza de API, y admite flujos de trabajo de diseño de API primero. El resultado de nuestro trabajo con Optic en este ámbito es Optic CI, un producto de linting de API capaz de expresar nuestros estándares de API. Las reglas de Optic CI son fáciles de leer y escribir en un DSL de TypeScript de alto nivel. Y lo más importante: Optic CI reconoce la misma realidad del desarrollo de API que Snyk: las API siempre cambian y evolucionan. Las reglas se aplican a los cambios en una API, no a un momento específico. Son lo suficientemente flexibles para impulsar la mejora continua y el perfeccionamiento de nuestras API, y para regir esos cambios sin acumular una montaña de «excepciones de linting» a medida que se refinan los estándares.
Y esto no es todo
En Snyk, nos comprometemos a crear una plataforma centrada en los desarrolladores y API-first. Al aplicar el enfoque shift left en nuestro SDLC de desarrollo de API, acercamos los comentarios a nuestros desarrolladores. No te pierdas nuestra próxima publicación sobre el proceso de desarrollo de API de Snyk, donde exploraremos cómo usamos herramientas para administrar las versiones de nuestras API.
¿Quieres formar parte del equipo que crea la plataforma de Snyk? Explora nuestras vacantes abiertas en Ingeniería y ayúdanos con nuestra misión de seguridad para desarrolladores.
