Technical Summary: Feature Engineering Is the Bottleneck in ML-Based Security-Relevant Method Detection

1. Problem Statement

Static Application Security Testing (SAST) tools rely on curated lists of Security-Relevant Methods (SRMs)—sources, sinks, sanitizers, and propagators—to trace untrusted data flows. While Machine Learning approaches for SRM detection (ML4SRM) report strong cross-validation results on training datasets, they exhibit significant performance degradation when applied to unseen, real-world code. Prior research has not systematically investigated the root causes of this generalization gap. The paper posits that the failure stems not from the choice of machine learning classifiers, but from the nature of the features used and the instability of model reliance on those features when the input distribution shifts.

2. Methodology

To investigate this gap, the authors introduce a comprehensive framework and dataset designed to enable rigorous, explainable comparisons of ML4SRM approaches.

2.1 WEAVE (WEKA Automated eValuator & Explainer)

The authors developed WEAVE, a tool integrating three components to ensure a fair and deep evaluation:

• Automated Model Selection (AutoML): Utilizing ML(2)-Plan, WEAVE searches a vast pipeline space (including base learners and meta-algorithms) to select optimal models, serving as a control against the manual, limited model selection typical in prior work.
• Repeated Cross-Validation: Using jaicore-experiments, the tool performs 100 repetitions of cross-validation to distinguish genuine performance differences from sampling variance.
• Explainable AI (XAI): WEAVE integrates SHapley Additive exPlanations (SHAP) via a prediction bridge. It connects Python-based SHAP processes with WEKA/MEKA-based models to generate both global explanations (aggregate feature importance) and local explanations (feature reliance for specific instances).

2.2 SRM-Dataset

The authors constructed SRM-Dataset, a consolidated collection of 10,180 labeled Java methods. This dataset aggregates and reconciles labels from existing sources (TaintBench, SecuCheck, CoDoC, and the prior SRM list) and includes manually labeled methods from the OWASP Benchmark. It serves as a uniform training and evaluation substrate to eliminate dataset mismatch as a variable.

2.3 Experimental Design

The study evaluates three state-of-the-art ML4SRM approaches: Dev-Assist, SSCM, and SWAN. For each approach, the authors compare:

1. The Published Model: The original pipeline and classifier from the literature.
2. The WEAVE Model: An AutoML-selected pipeline trained on the same SRM-Dataset.

The evaluation addresses three Research Questions (RQs):

• RQ1: How do AutoML-selected pipelines compare to published ones in terms of feature groups and performance?
• RQ2: Which feature groups drive global predictions, and how do they differ between published and AutoML models?
• RQ3: How does feature reliance change when models classify previously unseen methods (local explanations) compared to training data (global explanations)?

For local explanations, the models were tested on GXA (Gene Expression Atlas), a Java web application with independent SRM labels, to simulate a distribution shift.

3. Key Contributions

1. Explainability Findings: The paper provides evidence that ML4SRM models rely heavily on surface-level lexical features (method names, parameter signatures) rather than behavioral features (method bodies). Crucially, it demonstrates that the direction in which these models interpret features is unstable; a feature group that pushes a prediction toward the SRM class in training data may push it away in unseen code.
2. WEAVE Tool: An integrated apparatus for AutoML, repeated cross-validation, and SHAP-based explainability specifically for WEKA/MEKA pipelines, enabling head-to-head comparisons of ML4SRM approaches.
3. SRM-Dataset: A consolidated, traceable dataset of 10,180 Java methods, correcting errors in prior datasets and providing a larger, more diverse foundation for training and evaluation.

4. Key Results

4.1 Model Selection vs. Feature Engineering (RQ1)

• Performance: AutoML-selected models (WEAVE) generally matched or slightly outperformed published models in aggregate metrics (e.g., micro-F1 scores often reached 0.99).
• The Illusion of Improvement: Aggregate metrics masked poor performance on minority classes. For example, on the CWE79 task, models achieved a micro-F1 of 0.99 while the positive-class F1 was only 0.15–0.17.
• Conclusion: Better model selection (AutoML) did not resolve the generalization failure, suggesting the bottleneck lies elsewhere.

4.2 Global Feature Reliance (RQ2)

• Surface Features Dominate: Across all models, 50–59% of the attribution came from method names and parameter signatures.
• Neglect of Behavior: Features encoding behavioral, rename-invariant evidence (the method body, e.g., whether a method invokes a known sink) received minimal attention (often ≤6% of attribution).
• Data-Flow Neglect: Despite being a large group in feature sets, data-flow features were negligible in many models.
• AutoML Impact: AutoML broadened feature usage in only 4 of 7 detection targets; in many cases, it simply repaired degenerate models rather than fundamentally changing the reliance on lexical shortcuts.

4.3 Local Feature Instability (RQ3)

• Directional Shift: When classifying unseen methods (GXA), the models' reliance on feature groups shifted significantly. Of 59 comparable group-model pairs, 43 shifted significantly in direction (up to 62 percentage points).
• Reversal of Logic: In 14 cases, the direction crossed the neutral point, meaning a feature group that pushed predictions toward the SRM class in training pushed them away in unseen code.
• Magnitude vs. Direction: While the magnitude (share of total attribution) of features often appeared stable, the direction (whether the feature supports or opposes the SRM class) was highly volatile.
• Implication: The models learn spurious correlations specific to the training distribution (e.g., specific naming conventions) that do not hold in real-world code.

5. Significance and Claims

The paper argues that feature engineering, not model selection, is the primary bottleneck for ML-based SRM detection.

• The Bottleneck: Current ML4SRM approaches rely on "shortcut learning" using lexical tokens (identifiers, signatures) that are brittle to renaming and obfuscation. The models do not learn the semantic security relevance of the code (the method body).
• Metric Deception: Standard aggregate metrics (like micro-F1) hide the instability of feature reliance and the poor detection of minority classes. The paper advocates for per-class metrics and the comparison of global vs. local explanations as necessary diagnostic tools.
• Role of AutoML: AutoML optimizes the proxy metric (F1 on training data) but does not fix the underlying reasoning flaws. It can even reinforce shortcut learning by finding the most efficient way to exploit the provided feature set.
• LLMs and Explainability: The paper suggests that while Large Language Models (LLMs) offer potential, they currently lack the auditability of traditional ML4SRM. The ability to pinpoint why a model fails (via feature attribution) is a unique advantage of current ML approaches. The authors propose that LLMs could be used to generate features or explain decisions, but the core detection logic should remain auditable.
• Future Direction: The field must move beyond hand-crafted bag-of-words features toward robust, rename-invariant representations (e.g., ASTs, control-flow graphs) and must rigorously stress-test models against obfuscation and distribution shifts.

In summary, the paper concludes that without addressing the fragility of feature engineering, improvements in model selection or dataset size will not yield generalizable security tools. The instability of feature reliance under distribution shift is the fundamental cause of the documented generalization failure.