Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

MINES: Explainable Anomaly Detection through Web API Invariant Inference

T0 review · 3 major / 5 minor · reviewed 2026-08-03 · deepseek-v4-flash

Pith's one-line read MINES claims that web-API anomalies can be detected by deducing API, database, and session invariants from schema-level structures instead of learning from raw log instances, achieving near-100% precision and recall gains of more than 14 po

desk verdict Schema-level invariant inference is a real idea, but the SOTA claim rests on a fragile naming assumption and a metric that flatters the method. read the letter →

arxiv 2512.06906 v2 pith:SQ622P3P submitted 2025-12-07 cs.SE cs.CRcs.DBcs.LG

classification cs.SEcs.CRcs.DBcs.LG
keywords webAPIanomalydetectioninvariantinferenceschema-baseddeductionentity-relationshipdiagramLLM-basedspecificationminingtamperattackexplainabledatabaseconstraints
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that the true normal behavior of a web API is encoded in its schema — API signatures, database tables, and session context — and that a system deducing invariants from those artifacts can catch attacks that log-only learners miss because the anomaly lives in the database, not the log text. The authors build MINES, which converts API signatures into entity types in an augmented entity-relationship diagram, asks a large language model to guess reference and check constraints among API, database, and environment entities, filters those guesses against known-normal logs, and compiles the survivors into executable Python checkers. Across five web applications, they report recall between 0.83 and 0.95 with 100% precision, exceeding model- and rule-learning baselines by over 14 percentage points while keeping false positives near zero. For a reader, the significance is that explainable, specification-driven detection appears to be a practical alternative to black-box log models, and that it extends detection to anomalies defined purely by database state or session state.

What carries the argument

The augmented ER diagram is the load-bearing object: API entities (API name as table name, parameters/returns as flattened attributes) sit beside existing database tables and an environment entity, and the system infers three relationship families — API-DB foreign keys, API-API temporal dependencies, and API-Env session links. The LLM performs the semantic guessing of relationships and of five invariant categories (common-sense, format, database, environment, and related-API constraints). Three cheap heuristics (attribute-value overlap, HMM-based sequence probability, session presence) prune implausible relationships, and an iterative feedback loop executes candidate Python invariants agains

What would settle it

Obfuscate every API name, table name, and column name in Train-Ticket or NiceFish with random meaningless strings while keeping schemas, logs, and attack scripts unchanged, then rerun MINES: if recall does not fall well below the reported 0.94/0.92 values, the naming-semantics premise is not the operative mechanism; if it collapses toward the 0.5–0.7 range of the baselines, the premise is confirmed.

Watch

Extended reading notes

Core claim

The central claim is that anomaly detection reduces to a specification-inference problem over an augmented entity-relationship diagram. Each API signature is normalized into an action entity whose attributes are its parameters and return fields; this entity is placed beside the database tables and a session/environment entity. Treating API fields as potential foreign keys lets the system infer invariants such as 'a refund call must reference an order row whose status is paid,' a fact that no log-only learner can recover because the deciding information is in the database. The key discovery is that these constraints can be guessed by an LLM from names and types and then made trustworthy by a

Load-bearing premise

Everything rests on the premise that an LLM can recover real API-to-database and API-to-session semantic relationships from the names and types in the schema before heuristics and the normal-log filter are applied; if those names are opaque, the invariants weaken and recall drops toward baseline levels.

Editorial extensions

If this is right

  • Web applications with descriptive API and database names can obtain explainable anomaly detectors trained only on normal logs, with no attack samples needed during training.
  • Attacks that change database rows or session context without altering log text become detectable, since invariants reference database tables and environment entities directly.
  • Schema-based prompts shrink LLM input size by up to two orders of magnitude compared with raw-log induction, lowering cost while preserving or improving accuracy.
  • Detection runs offline at throughput above 200,000 logs per second, so the learned checkers can be deployed without runtime overhead.
  • The approach carries across different web frameworks and database backends, and across multiple large language models with only modest variation in recall.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the schema-deduction mechanism is as general as reported, the same augmented-ER construction could be applied to any stateful system with a schema-like contract — message queues, configuration stores, or event streams — turning them into invariant checkers without log-based training.
  • Because the refinement loop is what drives precision to 100%, a plausible testable extension is that a weaker LLM plus more validation logs could match a stronger LLM, letting organizations trade model cost against the normal-log volume they already collect.
  • The binary-log replay mechanism suggests a natural next step: temporal integrity invariants such as 'a refund cannot follow a cancellation' are not expressible as plain reference/check constraints, but the same replay machinery could support them.
  • The paper's own seatClass example implies a low-cost improvement: feeding type documentation or enum definitions into the schema prompt should recover invariants that pure name-based inference misses, offering a concrete way to harden the weakest link identified in RQ4.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes MINES, an LLM-based pipeline for explainable web-API anomaly detection. MINES converts API signatures, database schema, and session/environment information into an augmented entity-relationship diagram, uses LLMs to infer API-DB, API-API, and API-Env relationships and candidate invariants, refines these candidates against normal logs, and translates the surviving invariants into executable Python checks. It is evaluated on web-tamper attacks on Train-Ticket and NiceFish, with additional generalization benchmarks on Gitea, Mastodon, and NextCloud, comparing against LogRobust, LogFormer, and WebNorm. The paper reports 100% precision and recall improvements over 14% on the primary benchmarks, and claims a new state-of-the-art.

Significance. The core idea is timely and useful: moving from raw-log learning to schema-level invariant inference can address observability beyond logs and reduce spurious correlations. MINES contributes a concrete pipeline, an executable-invariant representation, a replicable attack dataset, and an ablation study that decomposes the contribution of each relationship type and of refinement. If the empirical claims are properly supported, the approach would be a meaningful advance for explainable web-application anomaly detection. The paper also demonstrates cross-LLM stability and evaluates on popular open-source applications, which strengthens the practical relevance.

major comments (3)
  1. [§5.1 (Metrics)] The metric definition is load-bearing for the SOTA claim. 'For attack logs, detection of any attacks results in True Positive (TP) for all logs' converts log-level detection into window-level recall: a detector that catches one log in a 20-log attack window receives full credit for all 20 logs, while one that catches the other 19 but misses that particular log receives zero. Since precision is effectively guaranteed for rule-based pipelines by the refinement step, recall is the only discriminating metric, so this windowing can materially inflate the reported margins. Please provide log-level TP/FN counts or justify the window-level aggregation with a sensitivity analysis.
  2. [Abstract vs. Table 12] The abstract states that MINES 'achieves high recall (more than 14% over LogRobust, LogFormer, and WebNorm)' after listing all five benchmarks. Table 12 directly contradicts this for LogRobust: on Gitea, Mastodon, and NextCloud, LogRobust recall is 0.970, 1.000, and 1.000, respectively, all higher than MINES's 0.956, 0.833, and 0.906. The 'more than 14% over LogRobust' claim is therefore false for three of the five applications. Please qualify the claim to the two primary benchmarks (Train-Ticket and NiceFish) or revise the abstract to match the reported data.
  3. [§5.4, Table 10; §5.3, Table 6; §6] The claimed SOTA margin is contingent on LLM relationship inference from identifier semantics. Removing API-Env relationships (Table 6) drops recall to 0.780 on Train-Ticket and 0.750 on NiceFish, essentially at baseline levels (LogFormer: 0.764/0.702; WebNorm: 0.704/0.750). Extreme abbreviation (Table 10) drops recall to 0.84. Since the refinement loop (§3.4) only deletes or revises candidates and cannot add relationships the LLM failed to propose, the >14% margin depends on the LLM's semantic inference succeeding on well-named schemas. The paper's own limitation statement in §6 acknowledges this. The abstract's unconditional 'new state-of-the-art' claim should be qualified (e.g., 'for systems with descriptive identifiers') or supported by a realistic naming-quality sensitivity analysis.
minor comments (5)
  1. [Figure 2] Figure 2 labels 'Entity-Relation Inference (§ 3.2)' and 'Invariant Generation (§ 3.3)', but relationship inference appears in §3.3 and invariant generation in §3.4. Please correct the cross-references.
  2. [Table 8] The row 'Number of False Negatives (w/ Refinement)' appears mislabeled. Based on the accompanying text, it should read 'Number of False Positives (w/ Refinement)' and 'False Positive Rate (w/ Refinement)'.
  3. [Table 9] The header has a typo: 'Percision' should be 'Precision'.
  4. [§3.3] The heuristic thresholds (attribute overlap, HMM probability, session presence, temporal window δ) are described as not application-specific, but no concrete values or default settings are reported. Reporting them would aid reproducibility and let readers assess sensitivity.
  5. [§5.1] For normal logs, 'A window is marked False Positive (FP) if any attacks are detected' would be clearer as 'if any anomaly is flagged'. Also, since Table 3 reports exactly 1.000 precision, the abstract's 'almost zero false positives' could be stated as 'zero false positives on the evaluated benchmarks'.

Circularity Check

1 steps flagged · score 3.0 of 10

No flat circularity, but one precision claim is by construction: the zero false-positive rate on training logs is guaranteed by the refinement loop; held-out precision and recall remain independent.

  1. fitted input called prediction [Section 3.4 'Invariant Refinement' and Section 5.3 'Effect of Invariant Refinement' (Table 8)]
    "Each candidate invariant is evaluated against the training logs. If any violations are detected, i.e., the invariant fails to hold on normal logs, these violations, along with relevant contextual information and error messages, are fed back to the LLM within the same conversation thread. The LLM is then prompted to revise or discard the problematic invariant. ... The refinement step is crucial for filtering false positives, reducing their rate from several percent to zero (Table 8)."

    Table 8's dataset sizes (168,799 and 40,654) are exactly the ManualNorm training-log counts from Table 2. The refinement loop discards or revises any candidate invariant that fires on those logs. Therefore, reporting zero false positives on those same logs is a consequence of the selection procedure, not an empirical finding about held-out data. The paper's headline held-out precision (Table 3) is evaluated on LLMNorm logs and is not forced, so this is a local, non-central instance of a fitted input being reported as a result.

full rationale

The central derivation is not circular. MINES infers candidate relationships and invariants from API signatures, database schema, and environment schema using LLMs; it does not fit invariants to attack labels. The ManualAbnormal and InjectAbnormal attack recordings are constructed independently of the invariant synthesis process, so the recall advantage over LogRobust/LogFormer/WebNorm is not definitional. Relationship-filter thresholds are tuned on a small validation set, which is ordinary hyperparameter adjustment rather than a prediction-fitted-to-answer. WebNorm [31] is an overlapping-author self-citation used to align benchmarks and as a baseline, but the method does not import a load-bearing uniqueness theorem from it; external baselines support the comparison. Section 6's acknowledged dependence on naming quality is a real limitation (RQ4 recall degrades to 0.84), but it concerns external validity, not circularity. The only construction artifact is the zero-FPR claim on the refinement training logs noted above; it does not by itself explain the held-out 1.000 precision on LLMNorm.

Assumptions & free parameters 6 free parameters · 5 assumptions · 0 invented entities

MINES introduces API-as-entity and Env-as-entity table abstractions, but these are representational transforms of existing API/session information, not new postulated entities with independent falsifiable handles. The load-bearing assumptions are LLM semantic competence, descriptive naming, representative normal logs, and binary-log availability. Free parameters are concentrated in relationship-filtering thresholds and the evaluation window.

free parameters (6)
  • API object flattening depth threshold th
    Section 3.2: chosen by hand; controls how deeply API object trees are expanded into table attributes, affecting which attributes the LLM sees.
  • API-DB attribute overlap threshold
    Section 3.3: used to discard proposed foreign keys with low value overlap; authors say thresholds are adjustable using a small validation set.
  • API-API HMM sequence probability threshold
    Section 3.3: filters temporal API-API relationships; threshold value not reported.
  • API-Env session presence threshold
    Section 3.3: discards environment relationships when relevant info is absent from session logs; threshold value not reported.
  • API-API temporal window delta
    Section 3.3: API-API joins use 0 < time difference < delta; delta is not given and directly shapes which inter-API invariants are possible.
  • Evaluation window size (20 logs) = 20
    Section 5.1: precision and recall are computed over 20-log windows, not individual logs; the reported numbers depend on this choice.
assumptions (5)
  • domain assumption LLMs can infer meaningful API-DB, API-API, and API-Env relationships from schema/identifier names
    Both inference stages (Sections 3.3 and 3.4) delegate semantic reasoning to LLMs; RQ4 shows performance collapses when identifiers are meaningless.
  • domain assumption System identifiers are descriptive and consistently named
    Section 5.5 states that MINES 'fundamentally relies on semantically meaningful identifiers'; obfuscated naming is acknowledged as a limitation.
  • domain assumption Training normal logs are representative of all normal behavior
    Invariant refinement (Section 3.4) deletes any candidate that fires on ManualNorm; a deployment with novel benign behavior would see false positives.
  • domain assumption Database binary logs are enabled and replayable
    Section 3.5 relies on replaying binary logs to reconstruct historical DB states; if binlogs are unavailable, API-DB invariants cannot be checked offline.
  • domain assumption API signatures and database schema are available and accurate
    Section 3.1 lists these as required inputs; errors or incompleteness in the schema propagate into the generated invariants.

how reviews work

0 comments
Cite this review

Pith. "Pith review of MINES: Explainable Anomaly Detection through Web API Invariant Inference." pith.science (2026). https://pith.science/paper/SQ622P3P

@misc{pith2026251206906,
  author       = {Pith},
  title        = {Pith review of: MINES: Explainable Anomaly Detection through Web API Invariant Inference},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SQ622P3P}},
  note         = {Machine review of arXiv:2512.06906}
}
read the original abstract

Detecting the anomalies of web applications, important infrastructures for running modern companies and governments, is crucial for providing reliable web services. Many modern web applications operate on web APIs (e.g., RESTful, SOAP, and WebSockets), their exposure invites intended attacks or unintended illegal visits, causing abnormal system behaviors. However, such anomalies can share very similar logs with normal logs, missing crucial information (which could be in database) for log discrimination. Further, log instances can be also noisy, which can further mislead the state-of-the-art log learning solutions to learn spurious correlation, resulting superficial models and rules for anomaly detection. In this work, we propose MINES which infers explainable API invariants for anomaly detection from the schema level instead of detailed raw log instances, which can (1) significantly discriminate noise in logs to identify precise normalities and (2) detect abnormal behaviors beyond the instrumented logs. Technically, MINES (1) converts API signatures into table schema to enhance the original database shema; and (2) infers the potential database constraints on the enhanced database schema to capture the potential relationships between APIs and database tables. MINES uses LLM for extracting potential relationship based on two given table structures; and use normal log instances to reject and accept LLM-generated invariants. Finally, MINES translates the inferred constraints into invariants to generate Python code for verifying the runtime logs. We extensively evaluate MINES on web-tamper attacks on the benchmarks of TrainTicket, NiceFish, Gitea, Mastodon, and NextCloud against baselines such as LogRobust, LogFormer, and WebNorm. The results show that MINES achieves high recall for the anomalies while introducing almost zero false positives, indicating a new state-of-the-art.

Figures

Figures reproduced from arXiv: 2512.06906 by the authors.

Figure 1
Figure 1. A log anomaly example caused by a real web attack on [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Approach Overview: Given a web application, MINES parses API signatures and database schema into an augmented [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Specifically, given a complex input object as tree [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (3 more)
Figure 7
Figure 7. Figure 7: Candidate invariant generation over the joined ta [PITH_FULL_IMAGE:figures/full_fig_p006_7.png]
Figure 8
Figure 8. Figure 8: Invariant generation process. MINES first generates [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]
Figure 9
Figure 9. Figure 9: Histogram of the number of tokens in the input [PITH_FULL_IMAGE:figures/full_fig_p009_9.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Context Contamination in LLM Analysis of Network Security Logs: Poison with Passive Prompt Injection and Mitigation Evaluation

    cs.CR 2026-07 conditional novelty 6.0 of 10

    Malicious text hidden in log fields hijacks LLM-based security analysis up to 88.2% of the time, and layered defenses reduce but do not eliminate the risk.

Reference graph

Works this paper leans on

76 extracted references · 7 canonical work pages · cited by 1 Pith paper

  1. [1]

    Mithun Acharya, Tao Xie, Jian Pei, and Jun Xu. 2007. Mining API patterns as partial orders from source code: from usage scenarios to specifications. In ESEC/FSE. https://doi.org/10.1145/1287624.1287630

  2. [2]

    Md Rakibul Alam, Ilias Gerostathopoulos, Christian Prehofer, Alessandro At- tanasi, and Tomas Bures. 2019. A framework for tunable anomaly detection. In 2019 IEEE International Conference on Software Architecture (ICSA). IEEE, 201–210

  3. [3]

    Crispin Almodovar, Fariza Sabrina, Sarvnaz Karimi, and Salahuddin Azad. 2024. LogFiT: Log anomaly detection using fine-tuned language models.IEEE Trans- actions on Network and Service Management21, 2 (2024), 1715–1723. https: //doi.org/10.1109/TNSM.2024.3358730

  4. [4]

    Hen Amar, Lingfeng Bao, Nimrod Busany, David Lo, and Shahar Maoz. 2018. Using finite-state models for log differencing. InESEC/FSE. https://doi.org/10. 1145/3236024.3236069

  5. [5]

    2024.Claude 3.7 Sonnet and Claude Code

    Anthropic PBC. 2024.Claude 3.7 Sonnet and Claude Code. https://www.anthropic. com/news/claude-3-7-sonnet

  6. [6]

    Vaggelis Atlidakis, Patrice Godefroid, and Marina Polishchuk. 2019. RESTler: Stateful rest api fuzzing. InICSE. https://doi.org/10.1109/ICSE.2019.00083

  7. [7]

    Ivan Beschastnikh, Yuriy Brun, Sigurd Schneider, Michael Sloan, and Michael D Ernst. 2011. Leveraging existing instrumentation to automatically infer invariant- constrained models. InESEC/FSE. https://doi.org/10.1145/2025113.2025151

  8. [8]

    Jakub Breier and Jana Branišová. 2015. Anomaly detection from log files using data mining techniques. InInformation Science and Applications. 449–457. https: //doi.org/10.1007/978-3-662-46578-3_53

Show all 76 references
  1. [9]

    Andy Brown, Aaron Tuor, Brian Hutchinson, and Nicole Nichols. 2018. Recurrent neural network attention mechanisms for interpretable system log anomaly detection. InMLCS. https://doi.org/10.1145/3217871.3217872

  2. [10]

    2016.Gitea

    CommitGo. 2016.Gitea. https://about.gitea.com/

  3. [11]

    2016.NiceFish

    Da Mo Qiong Qiu. 2016.NiceFish. https://gitee.com/mumu-osc/NiceFish

  4. [12]

    Gelei Deng, Zhiyi Zhang, Yuekang Li, Yi Liu, Tianwei Zhang, Yang Liu, Guo Yu, and Dongjin Wang. 2023. NAUTILUS: Automated RESTful API Vulner- ability Detection. InUSENIX Security. https://www.usenix.org/conference/ usenixsecurity23/presentation/deng-gelei

  5. [13]

    Min Du, Feifei Li, Guineng Zheng, and Vivek Srikumar. 2017. DeepLog: Anomaly detection and diagnosis from system logs through deep learning. InCCS. https: //doi.org/10.1145/3133956.3134015

  6. [14]

    Wenlong Du, Jian Li, Yanhao Wang, Libo Chen, Ruijie Zhao, Junmin Zhu, Zhengguang Han, Yijun Wang, and Zhi Xue. 2024. Vulnerability-oriented test- ing for restful apis. InUSENIX Security. https://www.usenix.org/conference/ usenixsecurity24/presentation/du

  7. [15]

    Asbat El Khairi, Marco Caselli, Andreas Peter, and Andrea Continella. 2024. REPLI- CAWATCHER: Training-less Anomaly Detection in Containerized Microservices. InNDSS. https://doi.org/10.14722/ndss.2024.24286

  8. [16]

    Yuanyuan Fu, Kun Liang, and Jian Xu. 2023. Mlog: Mogrifier lstm-based log anomaly detection approach using semantic representation.IEEE Transactions on Services Computing16, 5 (2023), 3537–3549. https://doi.org/10.1109/TSC.2023. 3289488

  9. [17]

    Maayan Goldstein, Danny Raz, and Itai Segall. 2017. Experience report: Log-based behavioral differencing. InISSRE. https://doi.org/10.1109/ISSRE.2017.14

  10. [18]

    Hongcheng Guo, Jian Yang, Jiaheng Liu, Jiaqi Bai, Boyang Wang, Zhoujun Li, Tieqiao Zheng, Bo Zhang, Junran Peng, and Qi Tian. 2024. Logformer: A pre-train and tuning pipeline for log anomaly detection. InAAAI. https://doi.org/10.1609/ aaai.v38i1.27764

  11. [19]

    Haixuan Guo, Shuhan Yuan, and Xintao Wu. 2021. Logbert: Log anomaly detec- tion via bert. InIJCNN. https://doi.org/10.1109/IJCNN52387.2021.9534113

  12. [20]

    Lynn Vonder Haar, Timothy Elvira, and Omar Ochoa. 2023. An analysis of ex- plainability methods for convolutional neural networks.Engineering Applications of Artificial Intelligence117 (2023), 105606. https://doi.org/10.1016/j.engappai. 2022.105606

  13. [21]

    Xiao Han, Shuhan Yuan, and Mohamed Trabelsi. 2023. LogGPT: Log anomaly de- tection via GPT. InBigData. https://doi.org/10.1109/BigData59044.2023.10386543

  14. [22]

    Hansen and E

    Stephen E. Hansen and E. Todd Atkins. 1993. Automated System Monitoring and Notification With Swatch. InLISA. https://dl.acm.org/doi/10.5555/1024753. 1024780

  15. [23]

    Shilin He, Pinjia He, Zhuangbin Chen, Tianyi Yang, Yuxin Su, and Michael R Lyu. 2021. A survey on automated log analysis for reliability engineering.ACM computing surveys (CSUR)54, 6 (2021), 1–37. https://doi.org/10.1145/3460345

  16. [24]

    O’Reilly Media, Inc

    Andrew Hoffman. 2024.Web application security. " O’Reilly Media, Inc. "

  17. [25]

    Shaohan Huang, Yi Liu, Carol Fung, Rong He, Yining Zhao, Hailong Yang, and Zhongzhi Luan. 2020. HitAnomaly: Hierarchical transformers for anomaly de- tection in system log.IEEE transactions on network and service management17, 4 (2020), 2064–2076. https://doi.org/10.1109/TNSM....

  18. [26]

    Aaron Hurst, Adam Lerer, Adam P Goucher, Adam Perelman, Aditya Ramesh, Aidan Clark, AJ Ostrow, Akila Welihinda, Alan Hayes, Alec Radford, et al. 2024. GPT-4o system card.arXiv(2024). https://arxiv.org/abs/2410.21276

  19. [27]

    Qiao Kang, Ankit Agrawal, Alok Choudhary, Alex Sim, Kesheng Wu, Rajkumar Kettimuthu, Peter H Beckman, Zhengchun Liu, and Wei-keng Liao. 2019. Spa- tiotemporal real-time anomaly detection for supercomputing systems. In2019 IEEE International Conference on Big Data (Big Data). I...

  20. [28]

    Ivo Krka, Yuriy Brun, and Nenad Medvidovic. 2014. Automatic mining of specifications from invocation traces and method invariants. InFSE. https: //doi.org/10.1145/2635868.2635890

  21. [29]

    Van-Hoang Le and Hongyu Zhang. 2021. Log-based anomaly detection without log parsing. InASE. https://doi.org/10.1109/ASE51524.2021.9678773

  22. [30]

    Xiaoyun Li, Pengfei Chen, Linxiao Jing, Zilong He, and Guangba Yu. 2020. Swiss- Log: Robust and unified deep learning based log anomaly detection for diverse faults. InISSRE. https://doi.org/10.1109/ISSRE5003.2020.00018

  23. [31]

    Yifan Liao, Ming Xu, Yun Lin, Xiwen Teoh, Xiaofei Xie, Ruitao Feng, Frank Liaw, Hongyu Zhang, and Jin Song Dong. 2024. Detecting and Explaining Anomalies Caused by Web Tamper Attacks via Building Consistency-based Normality. In ASE. https://doi.org/10.1145/3691620.3695024

  24. [32]

    Aixin Liu, Bei Feng, Bing Xue, Bingxuan Wang, Bochao Wu, Chengda Lu, Cheng- gang Zhao, Chengqi Deng, Chenyu Zhang, Chong Ruan, et al. 2024. Deepseek-v3 technical report.arXiv(2024). https://arxiv.org/abs/2412.19437

  25. [33]

    Jiashuo Liu, Zheyan Shen, Yue He, Xingxuan Zhang, Renzhe Xu, Han Yu, and Peng Cui. 2021. Towards out-of-distribution generalization: A survey.arXiv preprint arXiv:2108.13624(2021). https://arxiv.org/abs/2108.13624

  26. [34]

    Davide Lorenzoli, Leonardo Mariani, and Mauro Pezzè. 2008. Automatic gener- ation of software behavioral models. InICSE. https://doi.org/10.1145/1368088. 1368157

  27. [35]

    Siyang Lu, Xiang Wei, Yandong Li, and Liqiang Wang. 2018. Detecting anomaly in big data system logs using convolutional neural network. InDASC. https: //doi.org/10.1109/DASC/PiCom/DataCom/CyberSciTec.2018.00037

  28. [36]

    Scott Lupton, Hironori Washizaki, Nobukazu Yoshioka, and Yoshiaki Fukazawa

  29. [37]

    Chenyang Lyu, Jiacheng Xu, Shouling Ji, Xuhong Zhang, Qinying Wang, Binbin Zhao, Gaoning Pan, Wei Cao, Peng Chen, and Raheem Beyah. 2023. MINER: A Hybrid Data-Driven Approach for RESTAPI Fuzzing. InUSENIX Security. https: //www.usenix.org/conference/usenixsecurity23/presentation/lyu

  30. [38]

    Alberto Martin-Lopez. 2020. Automated analysis of inter-parameter dependencies in web APIs. InProceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Companion Proceedings. 140–142

  31. [39]

    Alberto Martin-Lopez, Sergio Segura, and Antonio Ruiz-Cortés. 2020. RESTest: Black-box constraint-based testing of RESTful web APIs. InService-Oriented Com- puting: 18th International Conference, ICSOC 2020, Dubai, United Arab Emirates, De- cember 14–17, 2020, Proceedings 18. ...

  32. [40]

    2016.Mastodon

    Mastodon gGmbH. 2016.Mastodon. https://joinmastodon.org/

  33. [41]

    Weibin Meng, Ying Liu, Yichen Zhu, Shenglin Zhang, Dan Pei, Yuqing Liu, Yihao Chen, Ruizhi Zhang, Shimin Tao, Pei Sun, et al. 2019. LogAnomaly: Unsupervised detection of sequential and quantitative anomalies in unstructured logs.. InIJCAI. https://doi.org/10.24963/ijcai.2019/658

  34. [42]

    2018.TrainTicket

    Microservice.System.Benchmark. 2018.TrainTicket. https://github.com/ FudanSELab/train-ticket/

  35. [43]

    Andy Neumann, Nuno Laranjeiro, and Jorge Bernardino. 2018. An analysis of public REST web service APIs.IEEE Transactions on Services Computing14, 4 (2018), 957–970. https://doi.org/10.1109/TSC.2018.2847344

  36. [44]

    2016.NextCloud

    NextCloud GmbH. 2016.NextCloud. https://nextcloud.com/

  37. [45]

    Anthonia Njoku, Heng Li, and Foutse Khomh. 2025. Kernel-Level Event-Based Performance Anomaly Detection in Software Systems under Varying Load Con- ditions. InCompanion of the 16th ACM/SPEC International Conference on Perfor- mance Engineering. 26–30

  38. [46]

    Alina Oprea, Zhou Li, Ting-Fang Yen, Sang H Chin, and Sumayah Alrwais. 2015. Detection of early-stage enterprise infection by mining large-scale log data. In DSN. https://doi.org/10.1109/DSN.2015.14

  39. [47]

    Michael Pradel and Thomas R Gross. 2009. Automatic generation of object usage specifications from large method traces. InASE. https://doi.org/10.1109/ASE. 2009.60

  40. [48]

    James E Prewett. 2003. Analyzing cluster log files using logsurfer. InProceedings of the 4th Annual Conference on Linux Clusters. Citeseer State College, PA, USA, 1–12

  41. [49]

    Jiaxing Qi, Shaohan Huang, Zhongzhi Luan, Shu Yang, Carol Fung, Hailong Yang, Depei Qian, Jing Shang, Zhiwen Xiao, and Zhihui Wu. 2023. LogGPT: Exploring ChatGPT for log-based anomaly detection. InHPCC. https://doi.org/10.1109/ HPCC-DSS-SmartCity-DependSys60770.2023.00045

  42. [50]

    Lianyong Qi, Wenmin Lin, Xuyun Zhang, Wanchun Dou, Xiaolong Xu, and Jinjun Chen. 2022. A correlation graph based approach for personalized and compatible web apis recommendation in mobile app development.IEEE Transactions on Knowledge and Data Engineering35, 6 (2022), 5444–545...

  43. [51]

    John P Rouillard. 2004. Real-time Log File Analysis Using the Simple Event Correlator (SEC). InLISA. https://dl.acm.org/doi/10.5555/1052676.1052694

  44. [52]

    Sudip Roy, Arnd Christian König, Igor Dvorkin, and Manish Kumar. 2015. Per- fAugur: Robust diagnostics for performance anomalies in cloud services. InICDE. https://doi.org/10.1109/ICDE.2015.7113365

  45. [53]

    Vilc Queupe Rufino, Mateus Schulz Nogueira, Alberto Avritzer, Daniel Sadoc Menasche, Barbara Russo, Andrea Janes, Vincenzo Ferme, Andre Van Hoorn, Henning Schulz, and Cabral Lima. 2020. Improving predictability of user-affecting metrics to support anomaly detection in cloud se...

  46. [54]

    Sigurd Schneider, Ivan Beschastnikh, Slava Chernyak, Michael D Ernst, and Yuriy Brun. 2010. Synoptic: Summarizing system logs with refinement. InWorkshop on Managing Systems via Log Analysis and Machine Learning Techniques (SLAML 10)

  47. [55]

    2025.State of API Security Report 2025

    Salt Security. 2025.State of API Security Report 2025. Technical Report. Salt Security. https://content.salt.security/state-api-report.html Accessed: March 11, 2025

  48. [56]

    Andrea Stocco and Paolo Tonella. 2020. Towards anomaly detectors that learn continuously. In2020 IEEE international symposium on software reliability engi- neering workshops (ISSREW). IEEE, 201–208

  49. [57]

    Shimin Tao, Yilun Liu, Weibin Meng, Zuomin Ren, Hao Yang, Xun Chen, Liang Zhang, Yuming Xie, Chang Su, Xiaosong Oiao, et al. 2023. Biglog: Unsupervised large-scale pre-training for a unified log representation. InIWQoS. https://doi. org/10.1109/IWQoS57198.2023.10188759

  50. [58]

    Emanuele Viglianisi, Michael Dallago, and Mariano Ceccato. 2020. Resttestgen: automated black-box testing of restful apis. InICST. https://doi.org/10.1109/ ICST46399.2020.00024

  51. [59]

    Neil Walkinshaw and Kirill Bogdanov. 2008. Inferring finite-state models with temporal constraints. InASE. https://doi.org/10.1109/ASE.2008.35

  52. [60]

    Zhiwei Wang, Zhengzhang Chen, Jingchao Ni, Hui Liu, Haifeng Chen, and Jiliang Tang. 2021. Multi-scale one-class recurrent neural networks for discrete event sequence anomaly detection. InKDD. https://doi.org/10.1145/3447548.3467125

  53. [61]

    Xingfang Wu, Heng Li, and Foutse Khomh. 2023. On the effectiveness of log representation for log-based anomaly detection.Empirical Software Engineering 28, 6 (2023), 137

  54. [62]

    Ming Xu, Chuanwang Wang, Jitao Yu, Junjie Zhang, Kai Zhang, and Weili Han

  55. [63]

    Ming Xu, Jitao Yu, Xinyi Zhang, Chuanwang Wang, Shenghao Zhang, Haoqi Wu, and Weili Han. 2023. Improving real-world password guessing attacks via bi- directional transformers. In32nd USENIX Security Symposium (USENIX Security 23). 1001–1018

  56. [64]

    InProceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security

    Chunk-level password guessing: Towards modeling refined password composition representations. InProceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security. 5–20

  57. [65]

    Lin Yang, Junjie Chen, Zan Wang, Weijing Wang, Jiajun Jiang, Xuyuan Dong, and Wenbin Zhang. 2021. PLELog: Semi-supervised log-based anomaly detection via probabilistic label estimation. InICSE. https://doi.org/10.1109/ICSE43902. 2021.00130

  58. [66]

    Kenji Yamanishi and Yuko Maruyama. 2005. Dynamic syslog mining for network failure monitoring. InKDD. https://doi.org/10.1145/1081870.1081927

  59. [67]

    Ting-Fang Yen, Alina Oprea, Kaan Onarlioglu, Todd Leetham, William Robertson, Ari Juels, and Engin Kirda. 2013. Beehive: Large-scale log analysis for detecting suspicious activity in enterprise networks. InACSAC. https://doi.org/10.1145/ 2523649.2523670

  60. [68]

    Wenqian Ye, Guangtao Zheng, Xu Cao, Yunsheng Ma, and Aidong Zhang

  61. [69]

    Jun Zeng, Zheng Leong Chua, Yinfang Chen, Kaihang Ji, Zhenkai Liang, and Jian Mao. 2021. WATSON: Abstracting Behaviors from Audit Logs via Aggregation of Contextual Semantics.. InNDSS. https://www.ndss-symposium.org/ndss-paper/watson-abstracting-behaviors- from-audit-logs-via-...

  62. [70]

    Chenxi Zhang, Xin Peng, Chaofeng Sha, Ke Zhang, Zhenqing Fu, Xiya Wu, Qingwei Lin, and Dongmei Zhang. 2022. DeepTraLog: Trace-log combined microservice anomaly detection through graph-based deep learning. InICSE. https://doi.org/10.1145/3510003.3510180

  63. [71]

    Yali Yuan, Sripriya Srikant Adhatarao, Mingkai Lin, Yachao Yuan, Zheli Liu, and Xiaoming Fu. 2020. Ada: Adaptive deep log anomaly detector. InIeee Infocom 2020-ieee Conference on Computer Communications. https://doi.org/10.1109/ INFOCOM41043.2020.9155487

  64. [72]

    Xu Zhang, Yong Xu, Qingwei Lin, Bo Qiao, Hongyu Zhang, Yingnong Dang, Chunyu Xie, Xinsheng Yang, Qian Cheng, Ze Li, et al. 2019. Robust log-based anomaly detection on unstable log data. InESEC/FSE. https://doi.org/10.1145/ 3338906.3338931

  65. [73]

    Nengwen Zhao, Junjie Chen, Zhaoyang Yu, Honglin Wang, Jiesong Li, Bin Qiu, Hongyu Xu, Wenchi Zhang, Kaixin Sui, and Dan Pei. 2021. Identifying bad software changes via multimodal anomaly detection for online service systems. InESEC/FSE. https://doi.org/10.1145/3468264.3468543

  66. [74]

    2025.Details of MINES

    Wenjie Zhang, Yun Lin, Chun Fung Amos Kwok, Xiwen Teoh, Xiaofei Xie, Frank Liauw, Hongyu Zhang, and Jin Song Dong. 2025.Details of MINES. https: //sites.google.com/view/mines-anomaly-detection/home

  67. [2021]

    In2021 28th Asia-Pacific Software Engineering Conference (APSEC)

    Literature review on log anomaly detection approaches utilizing online parsing methodology. In2021 28th Asia-Pacific Software Engineering Conference (APSEC). IEEE, 559–563

  68. [2024]

    https://arxiv.org/abs/2402.12715

    Spurious correlations in machine learning: A survey.arXiv preprint arXiv:2402.12715(2024). https://arxiv.org/abs/2402.12715

Pith tools

Reviewed August 3, 2026 · model on record in the stance chip above.