Skip to main content

5 prácticas recomendadas de seguridad para adoptar asistentes de programación con IA generativa como GitHub Copilot

blog feature ai lilac

5 de marzo de 2024

0 minutos de lectura

No hace tanto, la IA solía considerarse una idea futurista, algo sacado de una película de ciencia ficción. Incluso películas como Her y Ex Machina nos advertían que la IA podía ser una caja de Pandora que, una vez abierta, podía tener consecuencias inesperadas. ¡Cuánto han cambiado las cosas desde entonces, en gran parte gracias a la accesibilidad y adopción de ChatGPT! Este año, una encuesta de Gartner a altos ejecutivos realizada en mayo reveló que el 89 % de las organizaciones estaban investigando o implementando IA generativa, mientras que otro informe de Gartner del mismo periodo pronostica que más del 80 % del código en el desarrollo de productos será generado por IA para 2025.

Los desarrolladores se han beneficiado enormemente de la IA generativa y usan asistentes de programación con IA como GitHub Copilot, Amazon CodeWhisperer y ChatGPT de OpenAI para potenciar su productividad. Sin embargo, por poderosas y transformadoras que sean estas herramientas de IA, todavía pueden cometer errores y alucinar, por lo que deben usarse únicamente para complementar, no reemplazar a los desarrolladores. Por eso, es necesario implementar una validación humana cuidadosa del código generado por IA, herramientas y barreras de seguridad, además de otras medidas que garanticen el uso seguro de las herramientas de programación con IA generativa, para que puedas innovar sin temor. A continuación, veremos cómo puedes adoptar de forma segura herramientas de autocompletado de código con IA, como Copilot, al aplicar estas 5 prácticas recomendadas.

Práctica 1: Siempre debe haber una persona en el proceso

No contar con revisiones y validaciones humanas (o que sean insuficientes) es un error clásico al adoptar herramientas de programación con IA generativa. Como mencionamos antes, estas herramientas solo están pensadas para ayudar a los desarrolladores y no son infalibles. Por eso, los desarrolladores deben mantener los mismos hábitos seguros que tenían antes de implementar herramientas de programación con IA y seguir revisando cuidadosamente su código, ya sea generado por IA o no.

Piensa en la IA como un desarrollador sin experiencia que, casualmente, puede leer miles de hilos de Stack Overflow a la vez. Nunca integrarías código de un desarrollador nuevo sin revisarlo, así que no dejes que la velocidad de la IA te haga creer que es más inteligente de lo que realmente es.

Los equipos deben recibir capacitación sobre los riesgos del código generado por IA, además de conocer sus beneficios, y las revisiones periódicas de código deben formar parte de las prácticas internas de desarrollo de software. Valida, prueba y corrige en el IDE. Estos hábitos deben quedar establecidos en las políticas y los procedimientos de la empresa, y se debe ofrecer capacitación periódica para garantizar que los equipos comprendan la importancia de estas prácticas y realicen adecuadamente las revisiones de código necesarias.

Práctica 2: Analiza el código de IA desde el IDE con una herramienta de seguridad independiente e imparcial

Estos dos puntos van de la mano. En primer lugar, para aprovechar por completo el impulso que la IA ofrece a los desarrolladores, no puedes frenarlos con una revisión de seguridad tradicional. Los desarrolladores ya superan ampliamente en número a los profesionales de seguridad, lo que ha obligado a los equipos a adoptar prácticas de seguridad de desplazamiento a la izquierda. Ahora que la IA aumenta la productividad de los desarrolladores, también ha crecido el volumen de código vulnerable que se crea, así que desplazar la seguridad a la izquierda ya no es opcional: es un requisito. La forma más sencilla de lograrlo es integrar el análisis de seguridad directamente en el IDE, para analizar el código en cuanto se escribe y detectar vulnerabilidades de forma proactiva, en lugar de buscarlas de forma reactiva después de que se propaguen por el flujo de desarrollo.

En segundo lugar, el análisis debe realizarlo una herramienta de seguridad distinta de la que escribe el código. La razón es la misma por la que tienes equipos de desarrollo y equipos de seguridad separados. Si dejas que el equipo que escribe el código también se encargue de protegerlo, muchas vulnerabilidades pasarán inadvertidas. La seguridad es compleja y constituye una disciplina distinta del desarrollo.

La IA que impulsa la herramienta que escribe código se ha entrenado con código funcional para generar código funcional. En cambio, una herramienta de seguridad diseñada específicamente para una sola tarea —proteger el código— solo se habrá entrenado con datos centrados en la seguridad, para detectar y corregir problemas de seguridad de forma confiable. Además, las herramientas de seguridad deben comprender todo el contexto de tu aplicación, no solo el fragmento de código que se analiza, para que las correcciones de seguridad no generen errores en otras partes. Por eso, Snyk Code usa IA simbólica basada en reglas para analizar las posibles correcciones que propone nuestro LLM y solo ofrece a los usuarios opciones de corrección que no generen problemas adicionales.

Con la IA, necesitarás dos herramientas distintas (una para escribir y otra para proteger), del mismo modo que tienes dos equipos distintos (desarrollo y seguridad). Ambas herramientas deben comprender todo el contexto de tu aplicación para que no termines con fragmentos de código que solo tengan sentido por sí solos.

Práctica 3: Valida el código de terceros

En promedio, el 70 % del código de una aplicación es de código abierto. Eso significa que el 70 % de tu aplicación fue escrito y protegido por alguien ajeno a tu empresa, que no puede ser considerado responsable si una vulnerabilidad se convierte en un punto de acceso para actores maliciosos que buscan datos de clientes.

Cuando los desarrolladores usan dependencias de terceros, siempre deben analizarlas con una herramienta de análisis de composición de software (SCA) para determinar si son seguras. Las herramientas de SCA detectan paquetes vulnerables, informan cuál es la vulnerabilidad (tipo, gravedad, etc.) y sugieren formas de corregirla.

El código escrito por IA también incorpora dependencias de terceros. ¿Recuerdas? La IA es simplemente otro desarrollador, solo que escribe código a una velocidad increíble. También hay que analizar todas las dependencias de ese código. Sobre todo si tenemos en cuenta que una herramienta de IA basada en LLM siempre tendrá cierto retraso respecto a los hallazgos y lanzamientos más recientes de paquetes de terceros. La IA necesita SCA. Por eso, recomendamos que siempre verifiques manualmente las bibliotecas de código abierto que recomienda la IA y uses herramientas como Snyk Open Source para probarlas.

Práctica 4: Automatiza las pruebas en todos los equipos y proyectos

Si algo no está automatizado, es muy probable que no se haga. La automatización es una práctica recomendada tan fundamental que está presente casi en todas partes: desde administradores de Unix que escriben tareas cron, hasta equipos de control de calidad que implementan pruebas automatizadas y equipos de DevOps que desarrollan infraestructuras enormes, mantenidas con scripts de Python. La automatización no solo facilita la vida: también hace imposible olvidar una tarea.

Asegúrate de implementar herramientas de seguridad que protejan automáticamente tus aplicaciones desde CI/CD, así como en los flujos de trabajo que los equipos ya usan.

Práctica 5: Protege tu propiedad intelectual

Al implementar políticas sobre el uso de herramientas de IA, es muy importante que no permitas que estas aprendan de tu código propietario. En 2023, vimos que Samsung prohibió el uso de ChatGPT después de que sus datos propietarios se filtraran durante el entrenamiento basado en el uso. Lo último que quieres es que tu ventaja competitiva aparezca como código sugerido para desarrolladores de otra empresa de tu sector.

Esta medida es un poco más difícil de aplicar mediante la tecnología, así que es fundamental documentar bien las políticas de uso de IA y capacitar adecuadamente a los equipos (con ejemplos claros de los usos permitidos, las prácticas obligatorias y las posibles consecuencias). Además, asume que los datos que ingreses en un LLM se usarán para entrenarlo. Proporciona al LLM solo la información mínima que necesita para hacer su trabajo, sin incluir nada confidencial, y considera implementar controles de entrada y salida para depurar los datos que ingresan los usuarios y los resultados de tus LLM.

Usa asistentes de programación con IA de forma segura

No cabe duda: los asistentes de programación con IA son el futuro. Tus equipos trabajarán más rápido que nunca y generarán más código que nunca. Depende de ti asegurarte de que las aplicaciones que entregan sean seguras. Necesitarás las políticas adecuadas, la capacitación correcta y, lo más importante, las herramientas de seguridad apropiadas para que los equipos sigan avanzando a buen ritmo. Aquí es donde Snyk puede ayudar.

Con inteligencia líder en el sector e IA híbrida con participación de expertos, la plataforma de seguridad para desarrolladores de Snyk analiza el código a medida que se escribe, ya sea por una persona o por IA, y ofrece recomendaciones de corrección con un solo clic directamente en el IDE, para que los desarrolladores no tengan que ralentizarse y los equipos de seguridad no se vean sobrecargados.

Empieza a confiar en el código generado por IA con Snyk. Agenda hoy una demostración con un experto para descubrir cómo Snyk puede ser el copiloto de seguridad que Copilot necesita.

Empieza a proteger el código generado por IA

Crea tu cuenta gratuita de Snyk para empezar a proteger el código generado por IA en minutos. O agenda una demostración con un experto para descubrir cómo Snyk puede adaptarse a tus necesidades de seguridad para desarrolladores.

Leer más

Blog

Los modelos de frontera encontraron las vulnerabilidades. Solo el atacante encontró las cadenas.

El análisis estático encontró las fallas, pero solo las pruebas de ataque en vivo demostraron cómo podían encadenarse para provocar brechas. Una comparación de Evo COS, Claude Security y Claude Code Security.

feature insights context
Blog

Los ataques autónomos ya están aquí. La defensa debe estar a su altura.

Los atacantes autónomos están reduciendo el tiempo disponible para defenderse. Descubre cómo el descubrimiento, la corrección, la validación y la prevención continuos pueden ayudar a los equipos de seguridad a seguirles el ritmo.

Blog

Por qué los agentes de programación con IA siguen generando fallas de control de acceso

Los agentes de programación con IA pueden generar lógica de autorización que compila y supera la revisión, pero expone los datos de un inquilino a otro. Descubre por qué es difícil detectar el control de acceso roto y cómo prevenirlo.