Ús de l'AST en codi de fluxos de treball i seguretat

Darrera actualització: 7 d'abril de 2026
  • L'ús d'Arbres de Sintaxi Abstracta permet modelar i visualitzar fluxos de treball de programari, facilitant-ne la validació, la portabilitat i l'anàlisi automatitzada.
  • Les solucions d'Application Security Testing (SAST, DAST, IAST, MAST, SCA, RASP i ASTO) cobreixen diferents fases del cicle de vida de l'aplicació per detectar i mitigar vulnerabilitats.
  • L'anàlisi estàtica de codi i les tècniques avançades de flux d'informació requereixen internalitzar el codi a AST de qualitat, superant ambigüitats sintàctiques i semàntiques.
  • Paral·lelament, l'automatització de processos amb RPA i l'Anàlisi de Seguretat en el Treball apliquen la mateixa filosofia de descompondre fluxos per millorar seguretat, eficiència i control.

ús de AST en codi de fluxos de treball

Quan parlem d'AST en codi de fluxos de treball , en realitat estem barrejant diversos mons que, encara que semblin llunyans, cada vegada estan més connectats: l'enginyeria de programari clàssica , la seguretat d'aplicacions, l'automatització de processos amb RPA, la generació de codi amb IA i, curiosament, fins a la prevenció de riscos laborals. Tot gira al voltant de com modelem, analitzem, automatitzem i protegim els fluxos de treball que governen sistemes complexos.

Els Arbres de Sintaxi Abstracta (AST) s'han convertit en una peça clau per entendre i transformar codi, automatitzar auditories, generar proves, reforçar la seguretat i fins i tot representar gràficament workflows de negoci. Alhora, sota les mateixes sigles AST trobem conceptes com Application Security Testing o Anàlisi de Seguretat en el Treball, que apunten a una altra idea de fons: prendre els fluxos de treball (de programari o de persones) i sotmetre'ls a una anàlisi sistemàtica per detectar errors, riscos i oportunitats de millora.

AST com Arbre de Sintaxi Abstracta en fluxos de treball i generació de codi

En desenvolupament de programari a mida, l'ús d'arbres de sintaxi abstracta permet passar de codi opac a estructures visuals i comprensibles que descriuen amb precisió la lògica d'un flux de treball. Un AST descompon el programa en nodes que representen operacions, estructures de control, cridades a funcions, dades i relacions entre ells, de manera que la lògica deixa de ser “línies de codi soltes” per esdevenir un graf navegable.

Aquesta representació és especialment útil quan es gestionen agents d'intel·ligència artificial o arquitectures distribuïdes on els fluxos són intricats i difícils de seguir mentalment. En transformar el codi d'un workflow en un AST, és possible generar diagrames que mostren intuïtivament branques de decisió, dependències entre components, ordre d'execució i punts crítics del procés, facilitant tant el desenvolupament com la revisió i la presa de decisions tècniques.

Empreses especialitzades en programari a mida, com Q2BSTUDIO , aprofiten aquests arbres sintàctics per convertir fluxos de treball complexos en diagrames accessibles, visualment clars i, sobretot, útils a nivell funcional. No es tracta només de dibuixar capsetes, sinó de tenir un model estructurat que serveixi per refinar algoritmes, identificar colls d'ampolla, localitzar errors lògics i preparar el terreny per a optimitzacions posteriors.

El gran avantatge de l'AST en aquest context és que és independent del llenguatge de programació final . A partir d'un mateix arbre es pot compilar o transformar el flux cap a diferents llenguatges o plataformes (per exemple, diferents runtimes al núvol com AWS o Azure), mantenint una lògica de negoci coherent. Això habilita arquitectures més flexibles, portables i mantenibles, on el core del procés està definit de manera abstracta i el codi executable és una derivació controlada.

Un altre punt clau és la reutilització de nodes dins de l'AST . És possible definir blocs lògics (per exemple, validacions d'entrada, patrons d'accés a dades o mecanismes d'auditoria) que es reutilitzen com a peces segures i ja validades. Si aquests nodes són a més coneguts per la IA generadora de codi, podeu referenciar-los en lloc d'inventar des de zero, incrementant enormement la seguretat i la consistència del programari generat.

AST i generació de funcions amb IA: seguretat, validesa i confiança

La irrupció de models d'IA generant codi ha obert un nou front : com confiar en funcions escrites per una IA sense revisar cada línia a mà? Una solució sòlida és no demanar directament “codi executable”, sinó una representació estructurada de la lògica mitjançant un AST, que després es valida i es transforma en codi per una eina de confiança.

En treballar amb AST en lloc de codi pla , la IA genera nodes, operacions, estructures de control i fluxos de dades que es poden analitzar de manera automàtica: es comproven tipus, rutes d'execució, coherència de paràmetres, maneig d'errors, condicions límits i altres propietats abans d'arribar al compilador oa l'intèrpret. Aquest filtre redueix de manera dràstica el risc dexecutar codi maliciós o simplement incorrecte.

Q2BSTUDIO i altres organitzacions que exploren aquestes tècniques donen especial importància al fet que la lògica generada per IA sigui rastrejable i verificable. L'AST es converteix en la veritat intermèdia sobre la qual s'apliquen regles de seguretat, estàndards de qualitat, polítiques internes i anàlisi d'impacte. Així, cada funció generada encaixa a una biblioteca de nodes segurs, aprofitant elements prèviament auditats.

Aquesta aproximació obre a més la porta a compilacions multiobjectiu : a partir del mateix AST es pot obtenir codi en diferents llenguatges (per exemple, Python per a microserveis, C# per a serveis interns, o scripts especialitzats per a orquestradors del núvol). Per a empreses que treballen en entorns híbrids o multicloud, això és especialment atractiu, perquè assegura que el flux de negoci és consistent sense importar l'stack final.

Per acabar, l'ús de nodes reutilitzables dins de l'AST permet construir “biblioteques de lògica” certificades. La IA, en lloc d'inventar patrons d'accés a base de dades, validacions de seguretat o traces de logging, els compon a partir d'aquests blocs, cosa que millora tant la seguretat com el rendiment i afavoreix l'analítica posterior en eines com Power BI o altres plataformes d'intel·ligència de negoci.

AST aplicat a testing intel·ligent a Python i màxima cobertura de codi

L'AST també és la base de solucions avançades de testing automatitzat , com ara certs kits d'eines open source per a Python que utilitzen l'estructura del codi per generar bateries de proves amb una cobertura molt superior a la que se sol aconseguir escrivint-les a mà.

En aquest tipus d'eines es combinen tres capacitats principals : generació automàtica de proves unitàries per a un fitxer Python concret, fuzzing guiat per sotmetre funcions crítiques a entrades extremes i mal formades, i una generació de proves orientada per la cobertura, on l'AST s'analitza a fons per localitzar totes les branques, els bucles, les condicions i les rutes d'excepció possibles.

La clau és que l'eina construeix l'AST del codi Python i, a partir d'aquest, identifica rutes d'execució que encara no tenen proves que les cobreixin. Amb aquesta informació, encarrega a un model d'IA (per exemple, Gemini) la creació de casos de prova dirigits específicament a activar cada camí. Després executa les proves i mesura la cobertura amb eines com ara coverage.py, tancant així un cicle automatitzat de millora contínua.

  Què és el disseny web: conceptes essencials

Aquest enfocament no es limita a generar un lot inicial de tests sinó que permet iterar i millorar: si després d'una primera ronda segueixen quedant rutes sense exercici, es tornen a estudiar a partir de l'AST i se sol·liciten nous casos a la IA. Amb això, el procés s'adapta tant a codi nou com a bases de codi heretades amb poca o cap cobertura prèvia.

El projecte està muntat com un servidor MCP (Model Context Protocol) , de manera que funciona com un servei local al qual es pot trucar des de l'editor o la línia d'ordres. L'ús de BAML facilita que el codi de proves que es genera compleixi un format precís, sigui fàcil d'analitzar i no trenqui les eines d'integració contínua que el consumeixen.

AST com Anàlisi de Seguretat en el Treball: fluxos segurs a l'entorn laboral

Sota les mateixes sigles AST, trobem un altre concepte molt estès en prevenció de riscos laborals: l'Anàlisi de Seguretat en el Treball. Encara que es mou en un pla diferent del codi, comparteix amb els Arbres de Sintaxi Abstracta la idea de descompondre un flux (en aquest cas, de tasques humanes) en etapes, identificar riscos i definir controls abans d'executar.

L'Anàlisi de Seguretat en el Treball és un procés preventiu que s'aplica sobretot en activitats d'alt risc, com ara feines en alçada, maneig de maquinària complexa o manipulació de substàncies perilloses. El flux de treball es trosseja en passos, i per a cadascun s'identifiquen perills concrets, se n'avalua el nivell de risc i s'especifiquen mesures de control (EPP, senyalització, instruccions d'emergència, etc.).

Entre els principals beneficis de l'AST laboral destaquen la reducció d'accidents, el compliment de la normativa, la millora de l'eficiència operativa i l'enfortiment de la cultura de seguretat. Com que té un desglossament clar de la tasca, es disminueix la improvisació, s'eviten interrupcions per incidents i es redueixen costos associats a lesions, sancions o parades de producció.

El procediment típic per realitzar un AST a l'entorn de treball inclou: definir amb precisió la tasca i el seu context (entorn, equips, materials), dividir-la en etapes, identificar perills i riscos en cada etapa (caigudes, exposició a químics, atrapaments, fallades en equips), establir mesures de control específiques, comunicar i formar els treballadors involucrats i realitzar una supervisió.

Perquè aquesta anàlisi sigui realment efectiva convé recolzar-se en matrius de risc, llistes de verificació i, cada cop més, eines digitals que faciliten la documentació, el seguiment i la traçabilitat de les mesures adoptades. Empreses de consultoria com GMS Consulting integren aquests AST dins de sistemes de gestió com ISO 45001, ajudant les organitzacions a superar auditories internes i externes ia mantenir un cicle de millora contínua en seguretat i salut laboral.

Application Security Testing (AST): SAST, DAST, IAST, MAST i més

En l'àmbit de la ciberseguretat, AST es refereix habitualment a Application Security Testing , és a dir, al conjunt de tècniques i eines orientades a detectar vulnerabilitats en aplicacions modernes, ajustant-se a metodologies àgils ia la complexitat creixent del programari.

Les solucions d'AST són un pilar de qualsevol programa d'AppSec sòlid perquè les revisions manuals de codi i els plans de prova tradicionals són lents i no escalen bé davant l'aparició constant de noves vulnerabilitats. A més, múltiples normatives i marcs reguladors (com PCI-DSS, entre d'altres) exigeixen explícitament utilitzar eines d'aquest tipus.

Dins d'Application Security Testing avui podem distingir diverses categories principals : l'anàlisi estàtica (SAST), l'anàlisi dinàmica (DAST), les tècniques interactives i híbrides (IAST), les proves específiques per a aplicacions mòbils (MAST) i altres serveis complementaris com SCA, RASP, descobriment d'aplicacions, proves com a servei o eines de correlació.

La tecnologia Static AST o SAST analitza el codi en repòs (codi font, bytecode o binari) durant les fases de programació i prova del cicle de vida del programari. Es considera una prova de “caixa blanca”, ja que l'analista té accés al codi i al disseny de l'aplicació. Aquestes eines busquen debilitats com ara errors numèrics, problemes de validació d'entrada, condicions de carrera, referències no segures, desbordaments, etc.

Per la seva banda, la tecnologia Dynamic AST o DAST s'enfoca a l'aplicació en execució , normalment en entorns de prova o producció controlada. Des de l'exterior, es llancen atacs simulats per descobrir problemes com injeccions, errors d'autenticació, gestió deficient de sessions, errors a les interfícies o al maneig de respostes. És una aproximació de “caixa negra”, on no es presumeix coneixement del codi intern.

Les tecnologies IAST combinen el millor de SAST i DAST . S'instrumenta l'aplicació (per exemple, amb un agent a la JVM oa .NET CLR) per observar des de dins com es comporta mentre es llancen proves dinàmiques. Això permet correlacionar fluxos de dades i d'execució, entendre si una vulnerabilitat teòrica és realment explotable i reduir falsos positius en validar les troballes sobre la marxa.

MAST, o Mobile Application Security Testing , aplica una barreja d'anàlisi estàtica, dinàmica i forense específica per a aplicacions iOS i Android, incloent els seus components de backend. Aquestes solucions presten especial atenció a escenaris com ara dispositius rootejats o desbloquejats, xarxes Wi-Fi falses, gestió incorrecta de certificats, filtratge de dades sensibles i altres particularitats de l'entorn mòbil.

Serveis afegits: SCA, RASP, descobriment, bases de dades i orquestració ASTO

Molts proveïdors d'AST han ampliat la seva oferta amb serveis complementaris clau per cobrir l'ecosistema complet de seguretat d'aplicacions i la gestió de riscos de ciberseguretat , des de la composició del programari fins a la base de dades i l'orquestració de totes les eines.

L'Anàlisi de Composició de Programari (SCA) se centra a identificar components de tercers i de codi obert inclosos en una aplicació, i confrontar-los amb bases de dades de vulnerabilitats conegudes com la NVD del NIST, CVE i repositoris comercials com VulnDB. Aquestes eines permeten detectar versions obsoletes o amb pedaços de seguretat pendents, però no solen identificar vulnerabilitats en codi propi.

RASP (Runtime Application Self-Protection) porta la instrumentació un pas més enllà, usant tècniques similars a IAST per monitoritzar l'aplicació en execució i bloquejar atacs en temps real, competint en certa manera amb els WAF tradicionals. Molts equips comencen activant la instrumentació només per a diagnòstic (manera IAST) i, quan confien en els resultats, passen a manera RASP amb bloqueig efectiu d'atacs.

  Guia Completa de Trucs de Notepad++ per a Principiants

També és rellevant la capacitat de descobriment d'aplicacions , que analitza l'ecosistema web d'una organització i localitza tots els llocs i serveis exposats, incloent-hi aquells que han quedat oblidats, però continuen sent una porta d'entrada potencial.

A l'àmbit de la capa de dades , les eines d'anàlisi de seguretat de bases de dades revisen versions, pegats, configuracions, contrasenyes, polítiques d'accés i altres punts febles, tant sobre dades en repòs com, en alguns productes, sobre dades en trànsit. Això és crucial perquè moltes vulnerabilitats explotables són degudes a un mal govern de la base de dades, més que a errors en el codi de l'aplicació.

El model ASTaaS (Application Security Testing as Service) externalitza part o tot el procés de proves de seguretat a un proveïdor especialitzat, que combina anàlisi estàtica i dinàmica, pentesting, avaluació d'APIs i anàlisi de riscos. És especialment atractiu en entorns cloud, on aixecar i escalar entorns de test és més senzill.

Per bregar amb l'allau de troballes procedents de múltiples eines sorgeixen les solucions de correlació de resultats i els analitzadors de cobertura. Les primeres unifiquen i prioritzen vulnerabilitats detectades per diferents solucions SAST, DAST, IAST, MAST, etc., mentre que les segones mesuren quin percentatge del codi o de les branques lògiques ha estat realment sotmès a proves, ajudant a fixar llindars de qualitat acceptables i detectar codi inabastable.

Finalment, Application Security Testing Orchestration (ASTO) proposa integrar totes aquestes eines de manera coordinada dins del cicle de vida de desenvolupament (SDLC) i dels pipelins de CI/CD, amb una gestió centralitzada de polítiques, execucions i reporting. Tot i que encara és un camp en evolució, respon a la necessitat automatitzar al màxim les proves de seguretat sense frenar el ritme de lliurament.

Anàlisi estàtica de codi font orientat a seguretat: estàndards, tècniques i reptes

L'anàlisi estàtica de codi font amb focus en seguretat és una exigència creixent en organitzacions que es volen alinear amb estàndards i bones pràctiques de desenvolupament segur. Models com CLASP, OpenSAMM, Touchpoints o Microsoft SDL integren explícitament aquesta etapa dins del cicle de vida de desenvolupament, reforçant la idea de “seguretat des del disseny”.

Metodologies com OWASP i marcs SDLC segurs proporcionen guies concretes per executar anàlisis estàtiques, definir criteris de revisió, explotar resultats i mapejar troballes contra referències com OWASP Top 10 (XSS, SQL Injection, File Inclusion, etc.). Les eines SAST existents tant comercials com open source es recolzen fortament en teoria de compiladors, AST i anàlisi de fluxos d'informació per extreure coneixement útil del codi.

Entre les tècniques elementals podem esmentar grep avançat (recerca de patrons i possibles secrets en text clar), verificació d'indentació i estructura, anàlisi de flux de dades per seguir la vida d'una variable des de la seva definició fins al seu ús, propagació de constants per avaluar l'impacte de valors immutables i anàlisi d'àlies o punters per entendre referències indirectes en llenguatges.

A nivell de classificació de troballes , convé distingir entre bugs (desviacions entre allò que el programador pretenia i allò que fa realment el programari), violacions de bones pràctiques o de les regles del llenguatge (codi “no ideal”) i vulnerabilitats, enteses com el subconjunt de problemes amb impacte en la seguretat. Una peça de codi pot ser, alhora, un bug i una violació, i tot i així no ser explotable a causa de capes de seguretat addicionals.

Un repte important és que moltes eines SAST populars (com PMD, SonarQube o FindBugs) estan més enfocades en qualitat de codi que en seguretat pura, i el seu màxim potencial s'aconsegueix si s'integren des de l'inici del projecte, cosa que no sempre passa. En entorns on s'audita codi ja existent —sovint escrit per tercers— aquestes eines es poden quedar curtes, i cal construir analitzadors propis ajustats a les necessitats de l'equip.

El procés de construcció d'un analitzador estàtic sol organitzar-se com un pipeline: partint de les fonts (codi generat, binaris o codi màquina no entren en aquesta categoria), es fa una internalització que produeix un model abstracte fidel al codi original (generalment un AST enriquit), es deriven models d'entitats i d'execució, s'hi apliquen tècniques d'anàlisi i finalment s'apliquen tècniques d'anàlisi. La qualitat de tota la cadena depèn críticament de la fase d'internalització.

Internalització i generació d'AST: frontends, gramàtiques i ambigüitats

L'etapa d'internalització vol traduir el codi font a una estructura manejable per l'analitzador, normalment un AST o un graf similar. Per això es poden utilitzar frontends de compiladors ja existents (com GCC per a C, Mono per a .NET o Eclipse JDT per a Java), que proporcionen estructures provades i eficients.

No obstant això, recolzar-se en aquests frontends té inconvenients . Molts estan pensats per integrar-se a un IDE, requereixen crear projectes i configuracions addicionals, i generen models orientats a la interacció amb l'usuari més que a l'anàlisi massiva. A més, solen operar sobre un codi ja preprocessat (per exemple, C amb macros resoltes), cosa que pot introduir discrepàncies amb el codi font original en reportar errors.

Quan aquestes opcions no són suficients , toca recórrer a tècniques clàssiques de teoria de compiladors: construir gramàtiques, definir analitzadors sintàctics amb eines com ANTLR, Bison o Flex, o fins i tot programar parser combinators o solucions basades en PEG. Això exigeix ​​un coneixement profund de la sintaxi i la semàntica del llenguatge que s'està processant.

Els problemes habituals en aquesta fase inclouen ambigüitats sintàctiques (expressions que la gramàtica pot interpretar de diverses formes vàlides), ambigüitats dependents del context o la semàntica (per exemple, distingir si un fragment representa una multiplicació o una declaració de punter) i resolució de referències (saber en cada ús a quina variable, tipus o membre) s'està fent referència.

En llenguatges complexos com C++ o en entorns mixtos –per exemple, ASPX amb C#, Android amb Java/Dalvik– aquestes ambigüitats es multipliquen. Fins i tot IDEs avançats mostren errors d'acoloriment o reconeixement de símbols en fragments difícils, cosa que il·lustra el nivell de dificultat per als que construeixen eines d'anàlisi pròpies.

La conclusió és que no hi ha solucions màgiques : cal dominar la gramàtica, la semàntica, el model de memòria del llenguatge, les regles de resolució de noms i tenir molt clar l'objectiu de l'anàlisi, perquè és fàcil perdre's en detalls d'implementació que no aporten valor a l'auditoria o al cas que es persegueix.

Tècniques d'anàlisi avançada: fluxos d'informació i models d'execució

Un cop disposats de models interns sòlids (AST, models de memòria i d'execució) , entra en joc la fase d'anàlisi pròpiament dita. Aquí destaca l'anàlisi de flux de dades, que estudia com es propaga la informació a través de l'aplicació des de les fonts no fiables (inputs de l'usuari, fitxers, sockets, etc.) fins als sinks potencialment perillosos ( consultes SQL , ordres del sistema, renderitzat HTML sense escapar, etc.).

  Ciberseguretat 101: protegeix les teves dades

L'anàlisi de flux permet estudiar totes les rutes d'execució possibles que connecten una entrada amb un punt vulnerable, tant en sentit directe (forward) com cap enrere (backward), essencial per a tècniques de taint analysis. Cal un coneixement precís del model de memòria del llenguatge i dels mecanismes implícits de propagació (pas per valor o referència, tancaments, objectes immutables, threads, etc.).

També cal modelar o incloure el comportament de llibreries de tercers , ja que una gran part de la lògica de negoci i dels punts d'entrada/sortida hi resideixen. Si no es tenen en compte, les anàlisis poden generar una gran quantitat de falsos positius o, pitjor encara, falsos negatius que passen desapercebuts.

Un exemple il·lustratiu és l'anàlisi d'una aplicació vulnerable a SQL Injection : el codi pot semblar senzill, però mitjançant taint analysis s'observa com un paràmetre controlat per l'usuari es propaga a través de diverses funcions fins a arribar a la construcció de la consulta, que s'executa sense una parametrització adequada. Sense un model detallat de flux i memòria, aquestes dependències són difícils de descobrir automàticament.

Un altre cas més complex implica variables estàtiques compartides, callbacks o esdeveniments , on el valor que arriba a un sink depèn d'execucions anteriors o de rutes poc evidents. Aquí el model d'execució -que representa estats, transicions i contextos- combinat amb l'AST és el que permet reconstruir el puzle i extreure'n conclusions fiables sobre la seguretat del codi.

Tot i que aquestes tècniques introdueixen desafiaments addicionals , com l'anàlisi entre llenguatges o l'avaluació precisa d'expressions en entorns molt dinàmics, aporten una gran qualitat al resultat: menys errors d'interpretació, processos més ràpids un cop construïda la infraestructura i un marc de treball estandarditzat que es pot adaptar a projectes i tecnologies diferents.

Automatització de fluxos amb RPA a AST (Aragonesa de Serveis Telemàtics)

Més enllà de l'anàlisi de codi, els fluxos de treball també s'optimitzen a l'Administració pública mitjançant tecnologies de robotització de processos (RPA). Un cas il·lustratiu és el d'Aragonesa de Serveis Telemàtics (AST), entitat pública que proporciona serveis TIC al Govern d'Aragó i actua com a operador de telecomunicacions de la comunitat autònoma.

AST gestiona un ampli catàleg de serveis digitals –gestió documental, signatura electrònica, passarel·les de pagament, BI, infraestructures de dades espacials, allotjament d'aplicacions, lloc de treball, connectivitat i serveis de valor afegit– i es va trobar amb un coll d'ampolla crític: el procés manual de conformació de factures, que consumia gran quantitat de temps i recursos en períodes molt concentrats.

Per abordar aquest repte es va comptar amb Hiberus , que va proposar una solució basada en RPA utilitzant UiPath. L´enfocament va seguir una seqüència ordenada: creació d´un Agile Center especialitzat (consultors RPA, arquitectes, desenvolupadors, testers), consultoria de processos per identificar dades, sistemes i fluxos automatitzables, elaboració d´un document PDD amb la definició funcional i, a partir d´aquí, construcció de l´entorn i desenvolupament de la solució.

L'automatització va incloure la integració amb el Portafirmes corporatiu , sistema clau per a la signatura de factures, afegint fins i tot un sistema d'avisos que l'eina original no tenia. Es van desplegar entorns de desenvolupament i producció, i es va executar un pla de proves específic apuntant a sistemes de preproducció, cosa que va permetre a AST validar el robot sense impactar-ne l'operació diària.

Després de la validació es va implantar la solució en producció , aprofitant les fortaleses d'UiPath: capacitat per automatitzar processos complexos i d'alt volum, sota requisit de programació, facilitat d'escalat horitzontal, rapidesa de desenvolupament, sistema de notificacions incorporat i possibilitat d'aturar execucions si es detecta alguna incidència.

El projecte es va completar amb formació detallada per al personal d'AST , manuals d'usuari confeccionats conjuntament i sessions pràctiques per assegurar que els responsables poguessin manejar l'eina amb autonomia, ajustar configuracions i entendre els resultats sense dependre contínuament del proveïdor.

Els resultats quantitatius van ser molt significatius : en un període de dos mesos es va estimar la conformació de més de 500 factures, un 60% més que l'any anterior, i el temps per factura va caure de 10 minuts a aproximadament 2, fet que suposa una reducció del 80% en el temps mitjà de gestió. A mitjà termini es projecta un estalvi de centenars d'hores de treball manual, a més de beneficis qualitatius com l'eliminació d'errors humans, més agilitat per rellançar factures, augment de la productivitat i millor alineació amb els objectius de facturació.

Des del punt de vista estratègic , aquest pilot de RPA encaixa amb el pla d'AST per introduir processos de robotització i actuació administrativa automatitzada a l'Administració aragonesa. A més, ha servit per revisar i aclarir regles de negoci en el procés de facturació, millorar la informació compartida entre els implicats i detectar nous processos candidats a ser automatitzats en fases posteriors.

En conjunt, tot aquest panorama mostra com el concepte d'AST , en les seves diferents accepcions, se situa al centre de la millora de fluxos de treball: modelant la lògica de programes mitjançant arbres de sintaxi abstracta per a desenvolupament i testing intel·ligent, examinant la seguretat d'aplicacions amb bateries d'eines especialitzades, desgranant tasques laborals per eliminar riscos, puguin concentrar-se en activitats de més valor.

seguretat desenvolupament
Article relacionat:
Seguretat en el desenvolupament de programari i DevSecOps