Project archive

Full write-ups and architecture diagrams for projects beyond the three featured ones.

AI for IT operations IBM RESEARCH

ScriptSmith: LLM Bash Script Generation, Assessment and Refinement

Generate, assess and refine Bash scripts for SREs, without an execution environment.
2024 · IBM Research
LLMBASHSREAIOPSSELF-REFINEMENTIBM INSTANA

ScriptSmith is a unified, reference-free and execution-free LLM framework for generating, assessing and refining Bash scripts for IT operations, built on CodeSift. The last stage of an incident-remediation pipeline (root-cause diagnosis, action recommendation, action automation) turns recommended actions into scripts an SRE can run, and Bash is the tool of choice. LLMs can draft those scripts, but validating Bash by execution is often impossible: a test environment may not exist, and values such as free memory depend on the live system, so unit-test-based generate-and-fix approaches do not transfer. ScriptSmith instead assesses and refines scripts with LLMs alone, cutting the manual writing and debugging effort of SRE teams.

For each recommended action step the framework first searches a knowledge catalog of SRE-verified scripts (descriptions embedded as vectors, approximate nearest-neighbour search); a high-confidence hit is shown directly. Otherwise a code LLM generates a script, CodeSift assesses it without execution, and if it fails the LLM is asked to explain why and the explanation is fed back as a prompt to regenerate the script; the SRE approves, edits or rejects the result and approved scripts join the catalog. On the CodeSift Bash dataset (100 tasks, scored by execution) and InterCode Bash (153 tasks, scored by domain experts), the framework improves script generation by 7–10% overall. A peer-review setup, where a smaller model (Llama3 8B) judges a larger model's (Llama3 70B) scripts, beats self-reflection (assessment accuracy 74% vs 69% and 61% vs 54%), the largest refinement gain is 17% when a 70B model refines what an 8B model generated and assessed, and open-source models with ScriptSmith match raw closed-source (Gemini 1.5) generation. In a user study with four domain experts on the 153 InterCode tasks, first-pass accuracy of 42% rose to 76% after feedback-driven refinement, and experts judged the model's failure explanations correct in 69% of the failing cases. ScriptSmith is being deployed in IBM Instana's intelligent remediation pipeline as a tech preview.

IBM INSTANA REMEDIATION PIPELINE · MODELS · CATALOG RETRIEVE OR GENERATE ASSESS · REFINE · REVIEW · EXECUTION-FREE Recommended actions INPUT root-cause diagnosis → natural- language remediation steps LLMs PEER REVIEW generate: Llama3 70B · Gemini 1.5 Pro assess: Llama3 8B · Gemini 1.5 Flash Knowledge catalog GROWS SRE-verified scripts (Postgres), embedded for nearest-neighbour search Script generation CODE LLM code LLM drafts the Bash script; script extracted from the raw output Catalog retrieval EMBEDDINGS embed the action text, ANN search; high-confidence hit → shown to SRE Results AAAI 2025 +7–10% script accuracy 100 + 153 Bash tasks CodeSift assessment NO EXECUTION syntax check → code-func → similarity & difference → ensemble verdict Refinement FEEDBACK LLM explains why the script fails; the explanation prompts a rewrite SRE review HUMAN approve · edit · reject; approved scripts join the catalog action step catalog miss hit → SRE script fails refined passes approved 1 2 3 4 5 6 7 8 9
  1. 1
    Action step: each natural-language remediation step from the action-recommendation service is turned into a script
  2. 2
    Retrieve: catalog script descriptions are embedded as vectors; the step text is embedded and matched by approximate nearest-neighbour search
  3. 3
    Miss: no high-confidence match, so a code LLM generates a new Bash script (post-processed to extract the script from the raw output)
  4. 4
    Hit: a high-confidence match is shown directly to the SRE
  5. 5
    Assess: CodeSift validates the script without an execution bed; in the peer-review setting a smaller model (Llama3 8B) judges the larger model's script
  6. 6
    Fails: the LLM is prompted to explain briefly why the script does not perform the action, and the explanation is fed back as feedback to refine the script
  7. 7
    Refined: the regenerated script is proposed to the SRE
  8. 8
    Passes: a script that CodeSift labels correct goes to the SRE as is
  9. 9
    Approved: the SRE approves, edits or rejects; the final recommendation is published to the Postgres knowledge catalog, so future steps are answered by retrieval

CodeSift: Reference-Less Code Validation with LLMs

LLMs as a first-line filter for generated code, with no execution or reference code needed.
2023 – 2024 · IBM Research
LLM-AS-A-JUDGECODE VALIDATIONAIOPSBASHPYTHONBENCHMARK

CodeSift is an IBM Research framework that uses an LLM as a first-line filter for the functional correctness of generated code, without execution, reference code or human feedback. LLMs have made code generation cheap (SREs increasingly let them draft incident-remediation scripts), but checking that the code actually does what the task asked is still slow and error-prone: match-based metrics such as BLEU and CodeBLEU need a reference solution, execution-based checks need test cases and a secure sandbox, and neither scales to the volume of code now being generated. CodeSift validates the task-code pair directly, so only code that passes goes on to expert review or a controlled environment.

Generated code first passes a syntax check (ShellCheck for Bash, PyLint for Python; on an error the LLM is re-prompted with the error message and usually fixes it). The same LLM then runs three prompts: it rewrites the code as a text description of its purpose and logic (the code-func), judges whether that functionality accomplishes the task (similarity analysis) and lists any discrepancies between the two (difference analysis); the ensemble marks code correct only if it is similar and shows no discrepancies. The key insight is that LLMs compare text to text far better than text to code. On HumanEval, MBPP+ and a new 100-task Bash benchmark with test cases (contributed with the paper), judging code from Starcoder, Codellama, GPT-3.5 and Mistral, CodeSift with Mistral or Mixtral evaluators outperforms the ICE-Score and reference-guided grading baselines in accuracy, catches issues unit tests miss (e.g. "do not use recursion"), and can rank code-generation models without any ground truth. Deployed in an internal script-catalog pipeline, three subject-matter experts agreed with its validation output 83% of the time (and with the extracted functionality 78%) over 105 instances. ScriptSmith (AAAI 2025) builds on it.

INPUT · OUTPUT SYNTAX CORRECTNESS ENSEMBLE SYNTHESIS SEMANTIC VALIDATION · SAME LLM · 3 PROMPTS Inputs TASK + CODE natural-language task description + LLM-generated code (Python / Bash) Verdict FIRST-LINE FILTER correct → expert review / sandbox incorrect → filtered out early Syntax check LINTERS ShellCheck (Bash) PyLint (Python) LLM repair ON ERROR error message + code → LLM rectifies the code Ensemble AND correct only if similar and no discrepancies Code → functionality PROMPT 1 LLM rewrites the code as text: its purpose and logic (code-func) Similarity analysis PROMPT 2 can code-func accomplish the task? → similar / not similar Difference analysis PROMPT 3 list any discrepancies between code-func and the task code error clean code text code-func + task similar? differs? verdict 1 2 3 4 5 6 7 8

Cloud reliability & security IBM RESEARCH · NC STATE

Environment-Aware Risk Quantification

Prioritizing hardening risks by each customer's running environment.
01/2021 – 07/2021 · IBM Research★ 2021 IBM Research Accomplishment
DOCKERPOSTGRESQLPYTHON

Resistance Strength, also called Health Check by GTS, is the best practice for hardening IT infrastructure. It is governed by standard tech specs such as CIS benchmarks and STIG documents.

Customers' running environments vary, which results in many observed deviations, so prioritizing those risks with the customer's environment in mind matters. We quantify environment-aware resistance strength risk to help customers handle the volume of non-compliant controls. The quantification scheme is integrated with IBM X-Force Red Vulnerability Management Services (VMS).

X-FORCE RED VMS RISK PIPELINE · OURS STORAGE Scanners API · GUI Ansible · Nessus · Qualys plus analyst uploads X-Force VMS Web WEB receives raw scan files serves risk queries VMS UI UI findings ranked by environment-aware risk Filesystem QUEUE raw data saved by type, one queue per type Data Feed PYTHON polls queues, enriches with techspecs Risk Analyzer PYTHON environment-aware risk quantification Database techspecs · enriched findings · risk scores POSTGRESQL upload display save by type poll trigger enrich + save score + save query risk 1 2 3 4 5 6 7 8
  1. 1
    Upload: scanners (Ansible, Nessus, Qualys, or an analyst through the GUI) upload raw data files to X-Force VMS Web
  2. 2
    Categorize: VMS Web saves the raw data by type into a matching queue
  3. 3
    Poll: Data Feed periodically pulls unprocessed raw data from the queues
  4. 4
    Enrich: it retrieves techspecs, enriches the data and saves it (CVSS, utility, opportune, exploit)
  5. 5
    Trigger: Data Feed triggers risk quantification
  6. 6
    Score: Risk Analyzer reads the enriched data, calculates risks and saves them
  7. 7
    Query: VMS Web queries risk information from the database
  8. 8
    Display: VMS UI shows findings ranked by environment-aware risk

Policy-based Compliance Checking and Remediation in Multi-Clouds

Ansible-operator policy controllers for CIS benchmarks on RHEL, AWS and Azure.
01/2020 – 12/2020 · IBM Research★ 2021 IBM Research Accomplishment
CP4MCMKUBERNETESANSIBLEPYTHONYAML

IBM Cloud Pak for Multi Cloud Management (CP4MCM) is a digital consumption and delivery platform with integration and orchestration layers that supports multiple technology stacks across a multi-vendor platform. Governance, Risk and Compliance (GRC) is a critical component of CP4MCM that lets customers manage compliance with pre-defined and custom policies.

We worked with the GRC team to enhance the component:

  • End-to-end solution with Ansible Operators that extends the policy controller to Virtual Machines and Cloud Providers.
  • Policy controllers for the CIS Red Hat Enterprise Linux (RHEL) 7, CIS AWS and CIS Azure benchmarks.
  • Communication between the Ansible Operator and Ansible Tower, enabling customer-specified policies written in an inventory.
  • Design and visualization of scan and risk data in the GRC Dashboard.
Media: IBM Research Blog IBM Developer Recipes [1][2][3]
This work is part of IBM CP4AIOps.
HUB CLUSTER · MCM MANAGED CLUSTERS ANSIBLE TOWER MULTI-CLOUDS Visibility Dashboard UI compliance across clusters Policy Propagator POLICY pushes policies to clusters Status Aggregator POLICY rolls up evidence, status K8s API Server K8S Policy CRD · Inventory CRD cluster × policy × inventory MCM Klusterlet AGENT one per managed cluster Policy Controller CIS checks via Tower Operator OPERATOR watches policy CRDs, reports evidence Project GIT ID · token · playbook git Jobs API ID · project · inventory logs · output Inventory HOSTS ID · hosts · credentials Clouds & VMs IBM Cloud · AWS Azure · VMs Ansible Engine runs playbooks CRD 1 2 3 3 3 4 4 5 6 7 8
  1. 1
    Create: Policy Propagator creates the policy and inventory in the hub's K8s API server (policy = a set of CIS control IDs)
  2. 2
    Propagate: the hub propagates them to each managed cluster's Klusterlet operator
  3. 3
    Create job: the policy controller creates an Ansible Tower job that links the project (CIS controls as playbooks) and the inventory
  4. 4
    Execute: Tower runs the playbook on VMs or cloud servers through the Ansible Engine
  5. 5
    Stream: logs and output stream back to the job
  6. 6
    Collect: the policy controller collects evidence (system logs before and after each control) and compliance status
  7. 7
    Report: the operator reports evidence and status back to the hub
  8. 8
    Aggregate: the status aggregator rolls them up for the visibility dashboard

Automatically Detecting Risky Scripts in Infrastructure Code

Detecting risky scripts embedded in Ansible infrastructure code.
09/2019 – 05/2020 · IBM Research★ 2021 IBM Research Accomplishment
ANSIBLEANSIBLE-LINTSHELLCHECKPSSCRIPTANALYZERPYTHONYAMLSHELLPOWERSHELL

Infrastructure code supports embedded scripting languages such as Shell and PowerShell to manage infrastructure resources and conduct life-cycle operations. Risky patterns in embedded scripts have widespread negative impact across the whole infrastructure.

We propose an analysis framework that automatically extracts and composes the embedded scripts from infrastructure code, then detects their risky code patterns with correlated severity levels and impacts. SecureCode implements the framework for Ansible playbooks. Integrated with the DevOps pipeline in IBM Cloud and tested on 45 IBM Services community repositories, it identified 3419 true issues (1691 high severity) with 116 false positives in minutes.

SecureCode is currently owned by Kyndryl.
INPUT · KNOWLEDGE BASE · OUTPUT SECURECODE FRAMEWORK OPEN-SOURCE ANALYZERS Infrastructure code ANSIBLE Ansible playbooks KB RULES risky-code rules Issue details OUTPUT line, severity, impact SRT generation CODE parse playbooks into a structured repr. tree Script detection CODE detect embedded scripts, compose them per task Impact rating RULES categorize each issue, assign its severity Line mapping CODE map issues back to original source lines Script analyzers OSS ShellCheck · PSScriptAnalyzer · Ansible-lint 1 playbooks 2 SRT 3 script 4 issue IDs, line# 5 rules 6 7 issues

Automatically Fixing Software Hang Bugs for Production Cloud Systems

Localize the hang, match a root-cause pattern, generate a patch; fixed 40 of 42 real bugs.
09/2018 – 05/2020 · NC State
SOOTJAVA

Software hang bugs are notoriously difficult to debug and often cause serious service outages in cloud systems.

HangFix automatically fixes a hang bug that is triggered and detected in production. It localizes the hang function with stack trace analysis, classifies the bug by matching likely root-cause patterns, and generates code patches for the identified pattern. Evaluated on 42 real-world hang bugs in 10 commonly used cloud server applications, HangFix fixed 40 of them in seconds.

INPUT · OUTPUT LOCALIZE FIX ROOT-CAUSE PATTERNS · INFINITE LOOP BLOCKING Inputs JAVA bytecode + failing test Patched app OUTPUT 40 of 42 bugs fixed Localization TRACE find the function where execution hangs Pattern matching SOOT classify the hang into one of 4 patterns Patch generation CODE pattern-specific code patch Patch validation TEST re-run the triggering test case P1 Return values LOOP unexpected return values P2 Config params LOOP misconfigured parameters P3 Exceptions LOOP bad exception handling P4 Blocking ops BLOCK blocking without loops 1 stack trace 2 3 classify 4 5 6 patched

Detecting Data Corruption Hang Bugs in Cloud Server Systems

Statically detecting data-corruption hang bugs in cloud servers.
02/2017 – 05/2018 · NC State
SOOTJAVA

Cloud server systems such as Hadoop and Cassandra power many data-intensive applications, but they present data-corruption and performance problems that are hard to debug for lack of diagnosis information.

DScope statically detects data-corruption hang bugs. It analyzes I/O operations and loops, identifies loops whose exit conditions can be affected by I/O through returned data, error codes or exception handling, then prunes false positives with loop bound and stride analysis. On 9 common cloud server systems it detected 42 real hang bugs, 29 of them new, most of which existing tools miss.

INPUT DSCOPE · STATIC ANALYSIS OUTPUT Bytecode JAVA cloud servers, e.g. Hadoop Loop paths SOOT each loop’s paths and exit conditions I/O loops CODE exit depends on I/O data or I/O errors Pruning CODE loop bound & stride drop false positives Hang bugs BUGS 42 real bugs (29 new) 1 2 3 4

A Hybrid Approach to Performance Bug Diagnosis in Production Cloud Infrastructures

Hybrid static and runtime diagnosis of performance bugs.
08/2015 – 05/2018 · NC State
LTTNGCLUSTERINGLLVMFINDBUGSC/C++JAVA

Server applications in production cloud infrastructures are prone to performance problems such as hangs and slowdowns, and developers often have little to go on when diagnosing them.

Hytrace combines rule-based static analysis with runtime inference to localize performance bugs more accurately than purely static or purely dynamic approaches. It needs no source code and works on both compiled and interpreted programs such as C/C++ and Java. Experiments with real bugs from seven common server applications show significantly better diagnosis accuracy than existing techniques.

PHYSICAL HOST VM Kernel tracing moduleLTTNGkernel-level system call tracing ApplicationC/C++ · JAVAserver app, compiled or interpreted HYTRACE Hytrace-dynamicRUNTIMEruntime inference on the syscall trace Hytrace-staticLLVM · FINDBUGSrule-based analysis of bitcode/bytecode Consolidated rankingCODEmerges both rankings into likely root cause functions Xen/KVM hypervisorHOST Anomaly alertfrom monitoring Root causesOUTPUTranked functions 1 2 syscall trace 3 bitcode / bytecode 4 dynamic ranking 5 static ranking 6

Studying, Detecting and Fixing Timeout Bugs in Cloud Server Systems

A study of 156 timeout problems, TScope to identify timeout bugs, TFix to fix them.
02/2017 – 04/2019 · NC State★ IC2E best paper nominee
LTTNGSOMDAPPER TRACINGJAVA

Timeouts are commonly used to handle unexpected failures in server systems, but improper use can make systems hang or degrade. Our study of 156 real-world timeout problems in 11 cloud server systems shows they are widespread.

TScope identifies timeout bugs using kernel-level system call tracing with machine-learning-based anomaly detection and feature extraction; it correctly classified 18 of 19 real server performance bugs with a 0.8% false positive rate. TFix is a drill-down protocol that narrows down the root-cause variable of a timeout bug and recommends a fix; on 13 real cloud timeout bugs it localized the misused timeout variables and suggested proper values.

PHYSICAL HOST TScope & TFixANALYSISdetects and fixes timeout bugs on an anomaly alert APPLICATION & VM Kernel tracingLTTNGsystem call trace Function tracingDapper-style call trace Xen/KVM hypervisorHOST 1 syscall trace 2 function trace TSCOPE · DETECT System call selectionLTTNGkeep timeout-related system calls Feature extractionSOMfrequency and timing features per window Timeout bug identificationMLtimeout bug or other performance bug? detail 3 4 TFIX · FIX Classify bugMININGmisused timeout? viasyscall episode mining Find functionsTRACEtime and frequencychanges per function Find variableTAINTtaint analysis finds themisused variable RecommendCONFIGproper timeout valuefrom normal runs 5 timeout bug 6 7 8

Supporting Privacy-Preserving, Auditable Smart Contracts in Hyperledger Fabric

Privacy-preserving, auditable smart contracts on Hyperledger Fabric.
06/2018 – 03/2019 · NC State · IBM Research
HYPERLEDGER FABRICZERO-KNOWLEDGE PROOFGOLANG

On a blockchain network, transaction data are exposed to all participants. FabZK preserves privacy and confidentiality while keeping data immutable: it stores only encrypted transaction data (e.g., payment amount) on the shared ledger and anonymizes the relationship between payer and payee.

It achieves both privacy and auditability with verifiable Pedersen commitments and zero-knowledge proofs. FabZK extends open-source Hyperledger Fabric with APIs for client code and chaincode, and supports on-demand, automated auditing on encrypted data with reasonable performance.

SPENDING ORGANIZATION OTHER ORGANIZATIONS × N OFF-CHAIN ON-CHAIN · FABRIC Private ledger own records, plaintext Preparation CLIENT encrypt amounts, build proofs Notification CLIENT read new blocks, update private ledger Execution ENDORSER runs chaincode 2-step validation* ZKP proof checks, auditing Ordering service orders endorsed transactions from all organizations into blocks ORDERER Committer PEER validates, commits blocks Public ledger LEDGER encrypted, shared Notification CLIENT read new blocks, update ledger 2-step validation* ZKP proof checks, auditing Committer + public ledger PEER commit the same block 1 2 3 4 5 6 7 4 6 7
  1. 1
    Preparation: the spending organization's client node reads its private ledger, encrypts the amounts and builds proofs (FabZK step 1)
  2. 2
    Execution: its endorser runs the chaincode on the encrypted transaction (FabZK step 2)
  3. 3
    Ordering: the ordering service orders endorsed transactions from all organizations into blocks
  4. 4
    Commit: every organization's committer validates and commits the block
  5. 5
    Public ledger: the block is appended to the encrypted, shared ledger
  6. 6
    Notification: each client node reads the new block and updates its private ledger (FabZK step 3)
  7. 7
    2-step validation: endorsers check the zero-knowledge proofs of the encrypted transaction; auditing is part of this step (FabZK step 4)

A Study on Container Vulnerability Exploit Detection

How well static and dynamic schemes detect container exploits.
11/2018 – 06/2019 · NC State
DOCKERSYSDIGJMETERCLAIRML

Containers are increasingly popular for deploying cloud applications but are prone to security attacks. This study evaluates static and dynamic attack detection schemes on 28 real-world vulnerability exploits common in Docker images.

Static scanning detected only 3 of 28; dynamic anomaly detection caught 22; combining both reached 86% (24 of 28). Dynamic detection also gave more than 20 seconds of lead time for common attacks that try to gain a shell and execute arbitrary code.

INPUT COLLECT ANALYZE JMeter WORKLOAD benign requests Exploit ATTACK 28 real exploits Container DOCKER app under test, Docker image Sysdig TRACE records the syscall log Features ML processes the syscall log Detection ML anomalies in processed log Results OUT caught, lead time 1 2 3 4 5 6

Cloud Configuration Management System for Elastic Application Deployment in Private Clouds

Elastic application deployment and auto-scaling in private clouds.
01/2015 – 08/2015 · NC State · Credit Suisse
OPENSTACKDOCKERZOOKEEPERCADVISORJAVAPYTHONSHELL

Cloud infrastructures and distributed applications keep growing more complex, which calls for an easy-to-use deployment tool that stays elastic in dynamic environments: geographically distributed hosts, system anomalies and shifting workloads.

CCM provides automatic component composition and instantiation, plus an elastic auto-scaling mechanism that handles overload, resource contention and system anomalies.

Code
CCM CONTROL PLANE CCM ControllerCONTROLrequest mapping, scaling PredictionMLpredicts overload, anomalies Metric CollectorMETRICSaggregates resource usage APP / COMPONENT / INSTANCE REPOSITORY RegistrationREPOregister / delete instances DiscoveryREPOselect components MANAGED HOSTS HOST 1 HOST 2 1 request mapping 2 3 deploy 4 scale · configure CCM daemonAGENTapplies config DockerDAEMONruns containers MonitorCADVISORcontainer metrics 5 6 CCM daemonAGENTapplies config DockerDAEMONruns containers MonitorCADVISORcontainer metrics 5 6 7 resource usage 8 9 anomaly alert
  1. 1
    Request mapping: the controller looks up components in the repository (discovery / selection)
  2. 2
    Register: new component instances are registered or deleted
  3. 3
    Component deployment: selected components are deployed through a host's Docker daemon
  4. 4
    Configure / scale: the controller sends configuration and scaling commands to each host's CCM daemon
  5. 5
    Apply: the CCM daemon starts, stops or reconfigures containers through Docker
  6. 6
    Monitor: a metric monitor (cAdvisor) watches each host's containers
  7. 7
    Resource usage: monitors on every host report to the metric collector
  8. 8
    Aggregate: aggregated resource usage feeds the prediction module
  9. 9
    Anomaly alert: predicted overload or anomalies trigger the controller to rescale