La programació assistida per intel·ligència artificial ha deixat de ser una promesa de futur per convertir-se en la realitat diària de milers dequips de desenvolupament. En qüestió de segons, un assistent d'IA és capaç de produir funcions completes, scripts i fins i tot aplicacions senceres, i això està disparant la productivitat, però també els riscos.
El que moltes organitzacions encara no assumeixen és que la IA no assumeix cap responsabilitat: quan el codi falla, és l'equip tècnic qui dóna la cara. I el problema no és només que aquest codi pugui estar mal dissenyat o sigui difícil de mantenir; el veritable repte és que, en un percentatge enorme de casos, arriba a producció amb vulnerabilitats de seguretat greus.
Codi generat per IA: productivitat rècord i superfície d'atac desbocada
En molt poc temps hem passat a un escenari on un percentatge altíssim del codi en producció ja neix de models d'IA. Hi ha estudis que indiquen que un terç dels desenvolupadors reconeix que més d'un 60% del que escriuen prové d'assistents intel·ligents, i que les empreses ja estan veient increments de productivitat espectaculars gràcies a l'anomenat “vibe coding”, la programació a base de prompts.
El revers daquesta moneda és que al voltant de la meitat del codi generat automàticament presenta alguna vulnerabilitat, des d'injeccions SQL fins a errors criptogràfics o controls d'accés mal plantejats. En alguns llenguatges, com Java, s'ha arribat a detectar que més del 70% del codi proposat per IA tenia errors de seguretat.
Aquesta situació està provocant que moltes organitzacions enviïn a producció programari del que ja sospiten que no és perfecte. Hi ha informes que parlen de més d'un 80% d'equips que admeten haver desplegat codi sabent que no estava del tot madur, i gairebé la totalitat ha patit algun incident de ciberseguretat vinculat a vulnerabilitats en aquest codi.
Per si no n'hi hagués prou, s'ha disparat el fenomen del Shadow AI: empleats que usen eines de IA generativa sense control de l'organització, copiant i enganxant fragments de codi o fins i tot enganxant informació sensible als prompts. Això obre la porta a fugides de dades ia la proliferació silenciosa de components insegurs, impossibles de rastrejar després.
Bona part d'aquests riscos s'agreuja per la entrada massiva de “desenvolupadors ciutadans”, personal sense formació sòlida en enginyeria de programari que es recolza a la IA per crear automatitzacions, petites apps internes o integracions. El codi genera resultats funcionals, sí; però sol mancar de les mínimes garanties de seguretat i qualitat.
Els principals riscos de seguretat al codi generat per IA
La irrupció de la IA en el desenvolupament de programari no ha inventat noves vulnerabilitats, però ha multiplicat la velocitat i el volum amb què apareixen velles debilitats. Diverses anàlisis d'empreses de ciberseguretat coincideixen en una sèrie de riscos especialment crítics quan l'equip es recolza massa en eines generatives.
Un dels més visibles és el “vibe coding” sense bateria de proves ni revisions serioses. Es generen funcions o serveis complets a cop de prompt, es comprova que “funcionen” superficialment i s'integren sense passar per proves de seguretat, revisions de parells ni anàlisis automatitzades. Així es colen vulnerabilitats elementals que qualsevol auditoria mínimament rigorosa hauria detectat.
També preocupen els atacs a la cadena de subministrament de programari. Els models de IA tendeixen a recomanar dependències de tercers per resoldre problemes comuns. Si aquestes dependències no es monitoritzen ni s'analitzen amb eines de Programari Composition Analysis (SCA), s'obren portes per introduir llibreries malicioses o versions compromeses en milers de projectes amb un sol moviment.
La manca de monitorització contínua i auditoria de paquets externs permet que mòduls amb codi ofuscat o amb comportament sospitós s'executin dins dels sistemes sense aixecar alertes. Quan la IA suggereix i integra aquestes peces amb tanta facilitat, el risc de colar codi maliciós en forma de biblioteca “inofensiva” es dispara.
Un altre front delicat és la integració de models de llenguatge amb bases de dades i sistemes interns. Connectar un LLM a informació corporativa sense controls adequats obre la porta a atacs de prompt injection i prompt poisoning: instruccions malicioses amagades en dades o missatges que forcen el model a revelar secrets, saltar-se polítiques o executar accions indegudes.
A més, s'han detectat milers de credencials i secrets actius en datasets públics usats per entrenar models d'IA. Claus d'API, contrasenyes i tokens acaben incrustats en repositoris, fòrums o exemples de codi, i poden reaparèixer a les respostes d'un model o ser explotats per atacants que analitzen aquests conjunts de dades.
Cal no oblidar l'arrel del problema: la seguretat des del disseny continua sent la gran absent. Una majoria de desenvolupadors admet que passa més temps aplicant errors que incorporant requisits de seguretat des de la fase de disseny. En entorns on la velocitat de lliurament és prioritària, la pressió del negoci empeny a “treure la funcionalitat ja” i deixar la seguretat per més endavant… si és que arriba aquell moment.
La visió de CISOs, arquitectes i experts: acceptar la IA, però amb control
En diferents trobades professionals i taules rodones, responsables de ciberseguretat de banca, indústria, consultoria tecnològica o empreses de serveis coincideixen que la IA en el desenvolupament de codi ja no és opcional. S'està usant massivament i cap CISO assenyat es planteja prohibir-la sense més ni més.
El que sí que es plantegen és com mitigar els riscos sense bloquejar la innovació. Molts impulsen estratègies de desenvolupament segur basades en l'enfocament “shift left”: portar les proves de seguretat, l'anàlisi SAST i la revisió de dependències a les fases més primerenques del cicle de vida del programari, just quan el desenvolupador —o la IA— està escrivint les primeres línies.
Aquest canvi suposa que els equips de ciberseguretat ja no arriben al final, quan tot està desenvolupat i en producció, per dir que cal llençar-ho a baix i refer-ho. En lloc d'això, acompanyen el desenvolupament des del primer commit, integrant eines que analitzen el codi en temps real i ofereixen recomanacions immediates.
En organitzacions on el desenvolupament s'externalitza o el volum de codi propi no és enorme, els responsables de seguretat reclamen visibilitat sobre com es genera aquest codi. Volen garanties que els proveïdors usen pràctiques segures, que no depenen a cegues d'assistents d'IA i que passen el codi per escàners i revisions formals abans de lliurar-lo.
Altres CIS estan començant a veure els desenvolupadors com “validadors” del que genera la IA, més que com a autors de cada línia. El rol canvia: ja no es tracta només de produir codi, sinó d'entendre'l, qüestionar-lo, revisar-lo i millorar allò que proposa el model, especialment en àrees sensibles com autenticació, autorització, xifrat o tractament de dades personals.
En empreses amb gran quantitat de programari heretat, el focus és a controlar les vulnerabilitats que apareixen a llibreries de tercers i en capes legacy que ningú no s'atreveix a tocar. Aquí, les eines d'anàlisi automatitzada i els agents d'IA especialitzats en seguretat estan començant a ajudar a mapejar riscos i prioritzar què s'ha de posar pegats primer.
IA com a aliada defensiva: detecció, priorització i resposta
La mateixa tecnologia que facilita escriure codi insegur també està canviant radicalment la manera de defensar-lo. A centres d'operacions de seguretat (SOC), plataformes SIEM i eines d'anàlisi de codi, la IA generativa i els models d'aprenentatge profund s'estan convertint en peces clau.
Els motors de detecció basats en IA no es limiten a cercar firmes o patrons estàtics; són capaços d'analitzar el comportament del codi, els fluxos d'execució i les relacions semàntiques entre funcions. Entrenats amb enormes repositoris i dades reals d'amenaces, identifiquen vulnerabilitats i lògica maliciosa fins i tot quan el codi està escrit en estils poc convencionals o barrejant llenguatges.
A més, aquests models aporten context d'amenaça i priorització intel·ligent. No totes les vulnerabilitats mereixen el mateix esforç: una fallada explotable en un servei crític exposat a Internet pesa molt més que un bug en una eina interna. La IA pot creuar informació d'exposició, criticitat de l'actiu, historial d'explotació i configuració real per ordenar les alertes i centrar l'equip en allò que és veritablement perillós.
Un altre punt fort és la capacitat d'aprenentatge continu i adaptació. A mesura que evolucionen les tàctiques dels atacants i canvien els estils de codificació, els models es van ajustant i s'incorporen nous vectors d'atac i regles extretes d'incidents reals. Això converteix les defenses en un organisme viu que creix juntament amb el propi ecosistema de programari.
En el terreny de la resposta a incidents, la IA generativa permet automatitzar bona part de les accions inicials: categorització d'esdeveniments, generació de guions de resposta, aïllament de sistemes afectats, recomanacions de mitigació i creació d'informes clars per a equips tècnics i directius. Tot això redueix temps, evita errors i descarrega els analistes de tasques repetitives.
També s'estan usant models generatius per simular ciberatacs i entrenar els equips amb escenaris realistes. La IA produeix campanyes de pesca plausibles, seqüències d'atac complexes o patrons de comportament anòmals que forcen els analistes a reaccionar i millorar la seva capacitat de decisió sota pressió.
Malware i IA: hype, límits actuals i possible evolució
En paral·lel a l'auge de la IA defensiva, han aparegut prototips de codi maliciós que integren models de llenguatge o que aprofiten serveis d'IA per canviar de manera dinàmica. Experiments com BlackMamba, EyeSpy o el cuc Morris II han demostrat que és tècnicament possible fer servir un LLM per generar codi maliciós en temps d'execució, avaluar objectius o propagar atacs mitjançant instruccions injectades.
Tot i això, diversos experts en enginyeria inversa i xarxa teaming assenyalen que, ara com ara, aquests exemples són més curiositats tècniques que amenaces imbatibles. Les capacitats que mostren —polimorfisme, execució en memòria, ofuscació o selecció d'objectius— ja existien abans en programari maliciós avançat i es poden continuar detectant amb les defenses actuals.
Una de les raons és que el codi generat per models entrenats en dades públiques tendeix a ser menys sofisticat que l'escrit a mida per un atacant expert. Els LLM es basen en patrons apresos; no solen inventar del no res arquitectures de codi maliciós totalment innovadores, i moltes vegades produeixen fragments mediocres, redundants o fàcils de signar.
A més, perquè el codi maliciós basat en IA mereixi la pena, ha d'oferir una rendibilitat clara als qui el desenvolupen. Igual que va passar amb el ransomware o el criptojacking, no es veurà un ús massiu de certes tècniques fins que s'integrin de forma fluida al programari legítim i hi hagi una infraestructura madura que les suporti.
Dit això, els especialistes coincideixen que, si els models segueixen millorant al ritme actual, arribarà un punt en què sí que podran ajudar a crear amenaces més complexes i adaptatives. En aquest escenari caldrà reforçar encara més la supervisió humana, la protecció dels models davant de manipulació i la seguretat de tot el pipeline d'IA.
Assegurar el cicle complet d'IA: dades, models i canalització
Quan es parla de ciberseguretat en el codi generat per IA, no n'hi ha prou amb mirar el repositori: cal protegir tota la canalització d'IA d'extrem a extrem, des de la recollida de dades fins al desplegament dels models i el seu manteniment.
El primer pilar és la protecció de les dades d'entrenament i dels prompts, i l'elecció de plataformes segures com sistemes operatius lliures. Si els conjunts de dades contenen informació sensible sense anonimitzar, o si els usuaris enganxen secrets i dades personals a les consultes, es corre el risc de fugida d'informació, reaparició de credencials en les respostes o fins i tot filtracions massives si es compromet el proveïdor d'IA.
El segon pilar és la integritat dels models i algorismes. Atacs com el data poisoning poden contaminar les dades d'entrenament per esbiaixar les sortides; altres vectors busquen explotar vulnerabilitats a les API d'inferència per extreure'n el model o modificar-ne el comportament. Mantenir controls d'accés estrictes, xifrat, monitoratge i avaluació continuada és fonamental.
La tercera peça és la governança i supervisió de tot el pipeline. Això inclou registrar qui utilitza la IA, amb quins fins, quins tipus de codi genera, quines revisions passa i com s'integren els seus resultats als sistemes productius. Sense aquesta visibilitat, el Shadow AI es dispara i és impossible gestionar el risc.
Les bones pràctiques en aquest àmbit passen per polítiques de dades robustes, xifrat fort, autenticació multifactor, principis de mínim privilegi per accedir als models, guardrails als prompts, revisions manuals obligatòries i una monitorització constant d'entrades, sortides i efectes reals sobre l'entorn.
Marc SHIELD: posar límits clars a la programació assistida per IA
Per traduir tot això en controls pràctics, algunes consultores de seguretat han proposat marcs específics per a reduir el risc del “vibe coding”. Un dels més complets és el marc SHIELD, que resumeix en sis lletres els principis bàsics per fer servir la IA de forma responsable en desenvolupament.
La “S” de SHIELD fa referència a la Separació de funcions. Es tracta d'evitar que els agents d'IA tinguin permisos barrejats que arribin a entorns de producció. El que és sensat és limitar-ne el radi d'acció a desenvolupament i proves, sense credencials potents ni accés directe a bases de dades reals.
La “H” correspon a Humà al circuit. Això significa que el codi generat per IA ha de passar sempre per revisió i aprovació de personal qualificat, especialment quan l'utilitzen perfils que no són desenvolupadors professionals. Cap canvi rellevant no s'hauria de fusionar sense Pull Request supervisat.
La “I” apunta a la Validació d'entrades i sortides. Cal separar clarament instruccions fiables de dades no fiables, sanejar prompts, controlar què se li demana al model i sotmetre el resultat a eines com SAST abans d'integrar-lo a la base de codi.
La “E” se centra en Models auxiliars orientats a seguretat. En comptes de confiar en un únic assistent tot terreny, convé complementar amb eines específiques per a escaneig de secrets, verificació de controls, SCA, detecció de dependències fantasmes i comprovació de configuracions d'infraestructura com a codi.
La “L” es refereix al principi de “Least Agency” o agència mínima. Els agents d'IA han d'operar amb el mínim de permisos possible: sense accés a fitxers sensibles, amb límits estrictes a comandes destructives i sense capacitat d'autoexecutar canvis en entorns crítics.
Finalment, la “D” al·ludeix als Controls tècnics defensius. Abans de desplegar, és fonamental executar SCA, desactivar qualsevol mecanisme d'autodesplegament que eviti la intervenció humana, forçar pipelins amb etapes de seguretat i registrar exhaustivament cada acció que derivi d'un suggeriment de la IA.
Aquest tipus de marcs busquen una cosa molt senzilla: aprofitar l'acceleració que ofereix la IA sense lliurar-ne el control. O, dit de manera més directa, que l'assistent escrigui més línies per minut, però que la responsabilitat, els criteris i les decisions segueixin a les mans de l'equip humà.
Tot aquest nou ecosistema –amb IA generant codi a gran velocitat, defenses impulsades per models, marcs com SHIELD i una cultura que es debat entre la pressa i la prudència– obliga les organitzacions a madurar. Els qui aconsegueixin combinar bones pràctiques d'enginyeria, formació contínua en ciberseguretat, supervisió humana estricta i un ús intel·ligent de la intel·ligència artificial seran els que aconsegueixin que el codi sigui ràpid de produir, robust, segur i alineat amb els objectius del negoci, sense caure al parany de convertir-se en simples operadors de prompts ni de viure apagant incendis de seguretat constants.
