Use of AST in workflow and security coding

Informatec Digital » Resources » Using AST in workflow and security coding

When we talk about AST in workflow code , we're actually merging several worlds that, while seemingly disparate, are increasingly interconnected: traditional software engineering , application security, process automation with RPA, code generation with AI, and, interestingly, even occupational risk prevention. It all revolves around how we model, analyze, automate, and secure the workflows that govern complex systems.

Abstract Syntax Trees (ASTs) have become a key tool for understanding and transforming code, automating audits, generating tests, strengthening security, and even graphically representing business workflows. At the same time, the acronym AST encompasses concepts like Application Security Testing and Job Security Analysis, which point to another underlying idea: taking workflows (software or human) and subjecting them to systematic analysis to detect flaws, risks, and opportunities for improvement.

AST as an Abstract Syntax Tree in workflows and code generation

In custom software development, the use of Abstract Syntax Trees (ASTs) allows you to move from opaque code to visual and understandable structures that accurately describe the logic of a workflow. An AST breaks down the program into nodes that represent operations, control structures, function calls, data, and relationships between them, so that the logic ceases to be "loose lines of code" and becomes a navigable graph.

This representation is especially useful when managing artificial intelligence agents or distributed architectures, where workflows are intricate and difficult to follow mentally. By transforming workflow code into an AST (Automatic Software Analysis), it's possible to generate diagrams that intuitively show decision branches, component dependencies, execution order, and critical process points, facilitating development, review, and technical decision-making.

Companies specializing in custom software, such as Q2BSTUDIO , leverage these syntax trees to transform complex workflows into accessible, visually clear, and, above all, functionally useful diagrams. It's not just about "drawing boxes," but about having a structured model that can be used to refine algorithms, identify bottlenecks, locate logical errors, and pave the way for future optimizations.

The great advantage of AST in this context is that it is independent of the final programming language . From the same tree, the flow can be compiled or transformed into different languages ​​or platforms (for example, different cloud runtimes like AWS or Azure), while maintaining consistent business logic. This enables more flexible, portable, and maintainable architectures, where the core of the process is defined abstractly and the executable code is a controlled derivation.

Another key point is the reuse of nodes within the AST . It's possible to define logical blocks (for example, input validations, data access patterns, or auditing mechanisms) that are reused as secure and already validated components. If these nodes are also known to the code-generating AI, it can reference them instead of inventing them from scratch, greatly increasing the security and consistency of the generated software.

AST and AI-powered feature generation: security, validity, and trust

The emergence of AI models generating code has opened a new front : how can we trust functions written by an AI without manually reviewing every line? A solid solution is not to directly request "executable code," but rather a structured representation of the logic using an AST (Automatic Support Tool), which is then validated and transformed into code by a trusted tool.

By working with ASTs instead of plain code , AI generates nodes, operations, control structures, and data flows that can be automatically analyzed: types, execution paths, parameter consistency, error handling, boundary conditions, and other properties are checked before reaching the compiler or interpreter. This filter drastically reduces the risk of executing malicious or simply incorrect code.

Q2BSTUDIO and other organizations exploring these techniques place particular emphasis on ensuring that AI-generated logic is traceable and verifiable. The AST (Automated System Analysis) becomes the "intermediate truth" upon which security rules, quality standards, internal policies, and impact analyses are applied. Thus, each generated function fits into a library of secure nodes, leveraging previously audited elements.

This approach also opens the door to multi-purpose builds : from the same AST, code can be generated in different languages ​​(for example, Python for microservices, C# for internal services, or specialized scripts for cloud orchestrators). For companies working in hybrid or multi-cloud environments, this is especially attractive because it ensures that the business flow is consistent regardless of the final stack.

Finally, the use of reusable nodes within the AST allows for the construction of certified “logic libraries.” Instead of inventing database access patterns, security validations, or logging traces, AI constructs them from these building blocks, improving both security and performance and facilitating subsequent analytics in tools like Power BI or other business intelligence platforms.

AST applied to intelligent testing in Python and maximum code coverage

The AST is also the basis of advanced automated testing solutions , such as certain open source toolkits for Python that use the code structure to generate test suites with a much higher coverage than is usually achieved by writing them by hand.

This type of tool combines three main capabilities : automatic generation of unit tests for a specific Python file, guided fuzzing to subject critical functions to extreme and malformed inputs, and coverage-oriented test generation, where the AST is thoroughly analyzed to locate all possible branches, loops, conditions, and exception paths.

The key is that the tool builds the Python code's AST (Analog Test Asset) and, from it, identifies execution paths that are not yet covered by tests. With this information, it tasks an AI model (for example, Gemini) with creating test cases specifically designed to activate each path. It then executes the tests and measures the coverage with tools like coverage.py, thus closing an automated continuous improvement cycle.

This approach doesn't just generate an initial batch of tests ; it allows for iteration and improvement. If, after a first round, there are still routes that haven't been tested, they are re-examined using the AST (Advanced Test Assay) and new cases are requested from the AI. This makes the process adaptable to both new code and legacy codebases with little or no prior testing.

The project is set up as an MCP (Model Context Protocol) server , so it functions as a local service that can be called from the editor or the command line. Using BAML ensures that the generated test code adheres to a precise format, is easy to analyze, and does not break the continuous integration tools that consume it.

AST as Job Safety Analysis: safe flows in the work environment

Under the same acronym AST, we find another widely used concept in occupational risk prevention: Job Safety Analysis. Although it operates on a different level than code, it shares with Abstract Syntax Trees the idea of ​​breaking down a flow (in this case, of human tasks) into stages, identifying risks, and defining controls before execution.

Job Safety Analysis is a preventative process applied primarily to high-risk activities, such as working at heights, operating complex machinery, or handling hazardous substances. The workflow is broken down into steps, and for each step, specific hazards are identified, the level of risk is assessed, and control measures are specified (PPE, signage, emergency instructions, etc.).

Key benefits of workplace job safety assessments include reduced accidents, improved regulatory compliance, enhanced operational efficiency, and a strengthened safety culture. A clear job breakdown reduces improvisation, prevents interruptions due to incidents, and lowers costs associated with injuries, penalties, or production stoppages.

The typical procedure for conducting a JSA in the work environment includes: accurately defining the task and its context (environment, equipment, materials), dividing it into stages, identifying hazards and risks at each stage (falls, chemical exposure, entrapments, equipment failures), establishing specific control measures, communicating and training the workers involved, and conducting continuous monitoring and follow-up to adjust the analysis if conditions change.

For this analysis to be truly effective, it's advisable to use risk matrices, checklists, and, increasingly, digital tools that facilitate the documentation, monitoring, and traceability of the measures taken. Consulting firms like GMS Consulting integrate these Job Safety Analyses (JSAs) into management systems such as ISO 45001, helping organizations to pass internal and external audits and maintain a cycle of continuous improvement in occupational safety and health.

Application Security Testing (AST): SAST, DAST, IAST, MAST and more

In the field of cybersecurity, AST usually refers to Application Security Testing , that is, the set of techniques and tools aimed at detecting vulnerabilities in modern applications, adapting to agile methodologies and the increasing complexity of software.

AST solutions are a cornerstone of any robust AppSec program because manual code reviews and traditional test plans are slow and don't scale well to the constant emergence of new vulnerabilities. Furthermore, numerous regulations and regulatory frameworks (such as PCI-DSS, among others) explicitly mandate the use of such tools.

Within Application Security Testing today we can distinguish several main categories : static analysis (SAST), dynamic analysis (DAST), interactive and hybrid techniques (IAST), mobile application-specific testing (MAST) and other complementary services such as SCA, RASP, application discovery, testing as a service or correlation and coverage tools.

Static AST (SAST) technology analyzes code at rest (source code, bytecode, or binary) during the programming and testing phases of the software development lifecycle. It is considered a "white-box" test because the analyst has access to both the code and the application design. These tools look for weaknesses such as numerical errors, input validation problems, race conditions, unsafe references, overflows, and so on.

Dynamic AST (DAST) technology, on the other hand, focuses on the running application , typically in controlled test or production environments. Simulated attacks are launched from the outside to uncover problems such as injections, authentication failures, poor session management, interface errors, or response handling issues. It's a "black box" approach, where no knowledge of the internal code is assumed.

IAST technologies combine the best of SAST and DAST . The application is instrumented (for example, with an agent in the JVM or the .NET CLR) to observe its behavior from within while dynamic tests are run. This allows for the correlation of data and execution flows, understanding whether a theoretical vulnerability is actually exploitable, and reducing false positives by validating findings on the fly.

MAST, or Mobile Application Security Testing , applies a mix of static, dynamic, and forensic analysis specifically to iOS and Android applications, including their backend components. These solutions pay particular attention to scenarios such as rooted or unlocked devices, fake Wi-Fi networks, improper certificate management, leaks of sensitive data, and other characteristics of the mobile environment.

Additional services: SCA, RASP, discovery, databases, and ASTO orchestration

Many AST providers have expanded their offerings with key complementary services to cover the entire application security and cybersecurity risk management ecosystem , from software composition to database and orchestration of all tools.

Software Composition Analysis (SCA) focuses on identifying third-party and open-source components included in an application and comparing them against known vulnerability databases such as the NIST NVD, CVE, and commercial repositories like VulnDB. These tools can detect outdated versions or those with pending security patches, but they typically do not identify vulnerabilities in the application's own code.

RASP (Runtime Application Self-Protection) takes instrumentation a step further, using techniques similar to IAST to monitor the running application and block attacks in real time, competing in some ways with traditional WAFs. Many teams start by activating instrumentation for diagnostic purposes only (IAST mode) and, once they are confident in the results, they switch to RASP mode with effective attack blocking.

Also relevant is the application discovery capability , which analyzes an organization's web ecosystem and locates all exposed sites and services, including those that have been forgotten but remain a potential entry point.

At the data layer level , database security analysis tools review versions, patches, configurations, passwords, access policies, and other vulnerabilities, both for data at rest and, in some products, for data in transit. This is crucial because many exploitable vulnerabilities stem from poor database governance rather than flaws in the application code.

The ASTaaS (Application Security Testing as a Service) model outsources part or all of the security testing process to a specialized provider, combining static and dynamic analysis, penetration testing, API evaluation, and risk analysis. It is particularly attractive in cloud environments, where setting up and scaling test environments is simpler.

To deal with the flood of findings from multiple tools, results correlation solutions and coverage analyzers have emerged. The former unify and prioritize vulnerabilities detected by different solutions such as SAST, DAST, IAST, MAST, etc., while the latter measure what percentage of code or logical branches has actually been tested, helping to establish acceptable quality thresholds and detect untestable code.

Finally, Application Security Testing Orchestration (ASTO) proposes integrating all these tools in a coordinated manner within the software development lifecycle (SDLC) and CI/CD pipelines, with centralized management of policies, executions, and reporting. Although still an evolving field, it addresses the need to automate security testing as much as possible without slowing down the delivery pace.

Security-oriented static source code analysis: standards, techniques, and challenges

Static source code analysis with a focus on security is an increasing requirement for organizations seeking to align with secure development standards and best practices. Frameworks such as CLASP, OpenSAMM, Touchpoints, and Microsoft SDL explicitly integrate this stage into the development lifecycle, reinforcing the concept of "security by design."

Methodologies such as OWASP and secure SDLC frameworks provide concrete guidelines for performing static analysis, defining review criteria, exploiting results, and mapping findings against benchmarks such as the OWASP Top 10 (XSS, SQL Injection, File Inclusion, etc.). Existing SAST tools—both commercial and open source—rely heavily on compiler theory, AST, and information flow analysis to extract useful knowledge from code.

Among the elementary techniques we can mention advanced grep (searching for patterns and possible secrets in plain text), indentation and structure verification, data flow analysis to follow the life of a variable from its definition to its use, constant propagation to evaluate the impact of immutable values, and alias or pointer analysis to understand indirect references in low-level languages.

At the level of classification of findings , it is useful to distinguish between bugs (deviations between what the programmer intended and what the software actually does), violations of best practices or language rules (non-ideal code), and vulnerabilities, understood as the subset of problems with an impact on security. A piece of code can be both a bug and a violation, and still not be exploitable due to additional security layers.

A major challenge is that many popular SAST tools (such as PMD, SonarQube, or FindBugs) are more focused on code quality than pure security, and their full potential is realized when integrated from the project's inception, which doesn't always happen. In environments where existing code—often written by third parties—is being audited, these tools can fall short, making it necessary to build custom analyzers tailored to the team's needs.

The process of building a static analyzer is typically organized as a pipeline: starting with the source code (generated code, binaries, or machine code are not included in this category), an internalization process is performed to produce an abstract model faithful to the original code (generally an enriched AST), entity and execution models are derived, analysis techniques are applied, and finally, reports are generated. The quality of the entire process depends critically on the internalization phase.

Internalization and generation of AST: frontends, grammars and ambiguities

The internalization stage aims to translate the source code into a structure manageable by the parser, typically an AST or a similar graph. This can be achieved using frontends of existing compilers (such as GCC for C, Mono for .NET, or Eclipse JDT for Java), which provide proven and efficient structures.

However, relying on these frontends has drawbacks . Many are designed to integrate with an IDE, require creating additional projects and configurations, and generate models geared towards user interaction rather than large-scale analysis. Furthermore, they often operate on pre-processed code (for example, C with resolved macros), which can introduce discrepancies with the original source code when reporting errors.

When these options are insufficient , it becomes necessary to resort to classic compiler theory techniques: constructing grammars, defining parsers with tools like ANTLR, Bison, or Flex, or even programming parser combinators or PEG-based solutions. This requires a deep understanding of the syntax and semantics of the language being processed.

Common problems at this stage include syntactic ambiguities (expressions that the grammar can interpret in several valid ways), context-dependent or semantic ambiguities (e.g., distinguishing whether a fragment represents a multiplication or a pointer declaration), and reference resolution (knowing in each use which variable, type, or member is actually being referenced).

In complex languages ​​like C++ or in mixed environments —for example, ASPX with C#, Android with Java/Dalvik—these ambiguities multiply. Even advanced IDEs exhibit coloring or symbol recognition errors in difficult fragments, illustrating the level of difficulty for those building their own analysis tools.

The conclusion is that there are no magic solutions : you need to master the grammar, the semantics, the language's memory model, the rules of name resolution, and have a very clear objective for the analysis, because it is easy to get lost in implementation details that do not add value to the audit or the use case being pursued.

Advanced analysis techniques: information flows and execution models

Once robust internal models (AST, memory and execution models) are in place , the actual analysis phase begins. Data flow analysis is key here, studying how information propagates through the application from untrusted sources (user inputs, files, sockets, etc.) to potentially dangerous sinks ( SQL queries , system commands, unescaped HTML rendering, etc.).

Flow analysis allows you to study all possible execution paths connecting an input to a vulnerable point, both forward and backward, which is essential for taint analysis techniques. It requires a precise understanding of the language's memory model and implicit propagation mechanisms (pass by value or reference, closures, immutable objects, threads, etc.).

It's also necessary to model or include the behavior of third-party libraries , since a large part of the business logic and entry/exit points reside in them. If these are not taken into account, the analyses can generate a large number of false positives or, worse, false negatives that go unnoticed.

An illustrative example is the analysis of an application vulnerable to SQL Injection : the code may appear simple, but through taint analysis, it can be observed how a user-controlled parameter propagates through several functions until it reaches the query construction, which is executed without proper parameterization. Without a detailed flow and memory model, these dependencies are difficult to discover automatically.

Another, more complex case involves shared static variables, callbacks, or events , where the value reaching a sink depends on previous executions or less obvious paths. Here, the execution model—representing states, transitions, and contexts—combined with the AST is what allows us to piece together the puzzle and draw reliable conclusions about code security.

Although these techniques introduce additional challenges , such as cross-language analysis or accurate evaluation of expressions in highly dynamic environments, they bring great quality to the result: fewer interpretation errors, faster processes once the infrastructure is built, and a standardized framework that can be adapted to different projects and technologies.

Automation of workflows with RPA at AST (Aragonese Telematics Services)

Beyond code analysis, workflows are also being optimized in the Public Administration through Robotic Process Automation (RPA) technologies. An illustrative case is that of Aragonesa de Servicios Telemáticos (AST), a public entity that provides ICT services to the Government of Aragon and acts as the telecommunications operator for the autonomous community.

AST manages a wide catalog of digital services —document management, electronic signature, payment gateways, BI, spatial data infrastructures, application hosting, workstation, connectivity and value-added services— and encountered a critical bottleneck: the manual process of invoice creation, which consumed a large amount of time and resources in very concentrated periods.

To address this challenge, Hiberus was brought on board , proposing an RPA-based solution using UiPath. The approach followed a structured sequence: creation of a specialized Agile Center (RPA consultants, architects, developers, testers), process consulting to identify automatable data, systems, and workflows, development of a PDD document with the functional definition, and from there, building the environment and developing the solution.

The automation included integration with the corporate digital signature platform , a key system for invoice signing, even adding an alert system that the original tool lacked. Development and production environments were deployed, and a specific test plan was executed targeting pre-production systems, allowing AST to validate the robot without impacting its daily operations.

After validation, the solution was implemented in production , taking advantage of UiPath's strengths: ability to automate complex and high-volume processes, low programming requirement, ease of horizontal scaling, speed of development, built-in notification system, and the ability to stop executions if any issues are detected.

The project was completed with detailed training for AST staff , jointly prepared user manuals, and practical sessions to ensure that managers could operate the tool independently, adjust settings, and understand the results without constantly relying on the vendor.

The quantitative results were highly significant : in a two-month period, over 500 invoices were generated, 60% more than the previous year, and the time per invoice fell from 10 minutes to approximately 2, representing an 80% reduction in average processing time. In the medium term, savings of hundreds of hours of manual labor are projected, in addition to qualitative benefits such as the elimination of human error, greater agility in resubmitting invoices, increased productivity, and better alignment with billing objectives.

From a strategic perspective , this RPA pilot aligns with AST's plan to introduce robotic process automation and automated administrative procedures within the Aragonese Administration. Furthermore, it has served to review and clarify business rules in the invoicing process, improve information sharing among stakeholders, and identify new processes that could be automated in subsequent phases.

Taken together, this whole picture shows how the concept of AST , in its various meanings, is at the heart of improving workflows: modeling program logic using abstract syntax trees for intelligent development and testing, examining application security with specialized toolkits, breaking down work tasks to eliminate risks, or orchestrating robots that take care of repetitive tasks so that people can focus on higher-value activities.