Skip to content

Where is my Code Vulnerable: Matching CVEs and Source Code

David A. BarrettPeter Shin

Blue TeamThe Linux Foundation33 minOpen on YouTube ↗

Investigates where is practitioner Code Vulnerable: Matching CVEs and Source Code and evaluates key implications for security practitioners.

Summary

### Overview At an open source conference, David Barrett presents work conducted by the Canvas Labs team on automated source-code-to-source-code matching to identify vulnerabilities. In modern software engineering, deployed systems heavily rely on open source software. However, tracking dependencies, managing long-term legacy codebases (such as embedded systems), and identifying known Common Vulnerabilities and Exposures (CVEs) becomes difficult when code is copied, modified, or not pushed back upstream. Canvas Labs developed a two-part automated pipeline to link source code directly to known CVEs and their corresponding fixes in the National Vulnerability Database (NVD).

### Key Topics - **Extracting Package and Version Data from NVD Descriptions:** NVD vulnerability entries describe affected packages and versions using unstructured English text. Canvas Labs uses natural language processing (NLP) and machine learning models (specifically BERT) to tokenize descriptions, extract product names, parse version ranges, and generate mathematical, machine-readable queries. - **Abstract Syntax Tree (AST) Source Code Matching:** Instead of treating source code as a bag of words or matching solely on metadata, the system builds an index based on the code's compiler structure. By generating ASTs, it abstracts away specific function names, parameter identifiers, and local variables. This enables detection even if developers modified variable names or added lines. - **Mapping to Fixes:** By mining commit histories in code repositories like GitHub that reference CVE IDs, the system back-propagates from vulnerabilities to their exact patches, exposing the vulnerable lines alongside their fixes. - **Human-in-the-Loop Verification and Feedback:** The presenters stress explainability and semi-supervised active learning. Allowing engineers to flag false positives or approve fixes directly via an intuitive GUI feeds data back into the machine learning models, rapidly improving accuracy.

### Technical Details - **Indexing and Data Pipeline:** The architecture splits into a pre-processing pipeline and a runtime query pipeline. The pre-processing phase indexes open source repositories (including Linux kernel, Android, and Java projects) and pairs AST representations with parsed NVD entries. - **Demonstration:** In a demo, pasting a sample code snippet matched 29 instances in the repository, three of which corresponded to known NVD entries (two in OpenSSL and one in Android within `t1Lib.c` across functions `decrypt_ticket`, `processed_ticket`, and `process_heartbeat`). The UI highlights the vulnerability, affected versions, and patch diffs. - **Performance and Hardware:** Precomputing and indexing large repositories requires time (AST generation, lexing, parsing, and I/O), but lookups take under a second per file. The demonstration system runs on three-year-old server machines with fewer than 100 cores, and interactive demos run directly from a laptop. It can be integrated into CI/CD pipelines via build plugins. - **Open Source vs. Proprietary:** Canvas Labs open-sourced the version-parsing components and training data (utilizing BERT), while keeping the deep AST scanning engine proprietary.

### Takeaways Automating the link between natural language CVE descriptions and concrete source code requires robust NLP combined with structural AST-based code matching. However, complete automation should not entirely replace human engineers; maintaining human-in-the-loop workflows ensures reliable audit trails and drastically reduces false positive rates.

Related talks