<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>CPG on RORO's blog</title><link>https://blog.rodolpheg.xyz/tags/cpg/</link><description>Recent content in CPG on RORO's blog</description><generator>Hugo</generator><language>fr-fr</language><managingEditor>contact@rodolpheg.xyz (0xRo)</managingEditor><webMaster>contact@rodolpheg.xyz (0xRo)</webMaster><lastBuildDate>Tue, 05 Aug 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.rodolpheg.xyz/tags/cpg/index.xml" rel="self" type="application/rss+xml"/><item><title>Understanding Code Property Graphs</title><link>https://blog.rodolpheg.xyz/posts/understanding-code-property-graphs/</link><pubDate>Tue, 05 Aug 2025 00:00:00 +0000</pubDate><author>contact@rodolpheg.xyz (0xRo)</author><guid>https://blog.rodolpheg.xyz/posts/understanding-code-property-graphs/</guid><description>&lt;p>When I first started developing tools for source code auditing, my primary need was to track tainted data flows through complex codebases during manual code reviews. Initially, I turned to Tree-Sitter, which proved excellent for single-file analysis with its fast, incremental parsing capabilities. However, as I scaled to larger codebases with complex cross-file dependencies and data flows, Tree-Sitter&amp;rsquo;s AST-only approach became limiting. The challenge wasn&amp;rsquo;t just parsing individual files. It was understanding how data flows between functions, across modules, and through various execution paths during thorough manual security assessments.&lt;/p></description></item></channel></rss>