Parallel session tugas mandat

Summary

The presentation described a machine-learning approach for classifying software vulnerabilities and locating them at the source-code line level. The goal was to go beyond scanners that flag a vulnerable function or file without identifying the affected line or type of weakness—information developers need to act on a finding.

Approach

• The study focused on C and C++, using a Code Property Graph (CPG) to represent code structure.
• It combined code-language-model information with a graph neural network. The researchers compared a language-model-only approach, a graph-based approach, and a hybrid.
• The system aimed to identify vulnerability types from 25 CWE categories, as well as determine whether code was vulnerable.
• Rather than manually adding line-level labels, the researchers started with function-level dataset annotations and sought to infer the vulnerable line and CWE from them.

Findings and limitations

• The system correctly identified both the vulnerable line and the vulnerability type in about 40% of cases. In many other cases, it detected a vulnerability but either misplaced it or assigned the wrong CWE.
• Results were described as slightly below a full-explainer baseline, although the comparison involved approaches operating at different levels of detail.
• Combining graph and sequence information did not perform as well as expected. The researchers suggested that graphs may add less value when functions are simple and have limited dependencies.
• Fine-tuning the model on new vulnerability data caused forgetting: performance on previously learned data often declined. Possible causes included limited or poor-quality feedback and too little new data relative to the original dataset.
• The speaker emphasized the challenge of false positives in static analysis: incorrect alerts create extra work for developers.

Practical considerations

• The confidence threshold involves a trade-off: stricter thresholds can reduce false positives but may also miss vulnerabilities.
• The speaker recommended choosing thresholds according to the development stage and the risk of the software component. Teams may be more conservative for critical components and adjust thresholds as release needs and investigation capacity change.
• Although the initial dataset was imbalanced, the study used partitions intended to balance classes and cross-validation. In real use, developer feedback may be skewed because developers are less likely to report non-vulnerable cases. One-class classification was mentioned as a possible direction, but more data would be needed.

Reviews, guides, or tutorials

This was a research presentation and discussion, not a product review, guide, or tutorial.

Main speakers and sources: The research presenter, addressed in the session as Mr. D; a session moderator or chair who introduced the Q&A and closed the session; and audience members who asked questions about dataset balance and confidence thresholds.