Tracking AI-Generated Code in Production Vulnerabilities: A Git Forensics Pipeline

Hook

What if the vulnerability in your production system wasn't written by a developer, but by an AI that left no trace except a subtle pattern in git metadata?

Context

We're in the middle of a seismic shift in software development. GitHub Copilot, ChatGPT, Claude, and dozens of other AI coding assistants are generating millions of lines of production code daily. But here's the uncomfortable question nobody wants to ask: when vulnerabilities appear in codebases that use these tools, how do we know if the AI introduced them?

Traditional security research relies on synthetic benchmarks—academic exercises where researchers feed AI models contrived prompts and measure the output. But these don't tell us what's actually happening in the wild. When a CVE gets published for a popular open-source library, when a security researcher discovers a buffer overflow or SQL injection, was that code written by a human or suggested by an autocomplete model? The vibe-security-radar project from Georgia Tech's SSLab tackles this question head-on with an ambitious approach: analyze real CVEs at scale, use git forensics to identify the commits that introduced vulnerabilities, then determine whether AI tools were involved. It's not a production security scanner—it's a research pipeline for understanding the real-world security impact of AI-generated code.

Technical Insight

The architecture is a five-stage pipeline that processes vulnerability data through increasingly sophisticated layers of analysis. It starts by aggregating CVE data from OSV (Open Source Vulnerabilities), GitHub Advisory Database, and NVD (National Vulnerability Database). For each vulnerability, it identifies the fix commit—the moment a maintainer patched the security issue.

Here's where it gets interesting: the system uses SZZ-style git blame analysis to work backward from the fix. When you see a security patch that changes line 42, git blame tells you which commit originally wrote line 42. But modern repositories use squash merges, rebase workflows, and other operations that obscure history. The pipeline includes squash-merge decomposition logic to reconstruct the true origin of vulnerable code:

# Simplified concept from the blame analysis stage
def trace_vulnerable_lines(repo, fix_commit, vulnerable_file):
    """Trace lines modified in fix commit back to their origin."""
    blame_results = []
    
    # Get diff from fix commit
    modified_lines = get_modified_lines(fix_commit, vulnerable_file)
    
    # Blame each line in the parent commit (pre-fix state)
    parent_commit = fix_commit.parents[0]
    
    for line_num in modified_lines:
        # Handle squash merges by checking commit message patterns
        origin_commit = git_blame(repo, parent_commit, vulnerable_file, line_num)
        
        if is_squash_merge(origin_commit):
            # Decompose into constituent commits if possible
            origin_commit = decompose_squash(origin_commit)
        
        blame_results.append({
            'line': line_num,
            'origin_commit': origin_commit.hash,
            'author': origin_commit.author,
            'timestamp': origin_commit.timestamp
        })
    
    return blame_results

Once the system identifies origin commits, it scans for AI tool signatures. This is where the research gets creative—and shows its limitations. The pipeline looks for 15+ different AI coding assistant patterns: co-author trailers like Co-authored-by: GitHub Copilot <copilot@github.com>, bot email addresses, commit message patterns specific to tools like Cursor, Cody, or Amazon CodeWhisperer, and even timestamp clustering that suggests rapid AI-assisted development sessions.

But metadata detection is inherently incomplete. Most developers don't announce when they use AI assistance, and most AI tools don't automatically inject signatures. The researchers acknowledge this openly: their methodology provides a lower bound. They're finding the cases they can detect, knowing that many AI-generated vulnerabilities slip through unidentified.

This is why the final stage uses LLM-based verification. For commits flagged by signature detection, the system feeds the actual code diff, commit context, and repository metadata to a language model with a specialized prompt:

# Conceptual LLM verification stage
def verify_ai_involvement(commit_data, cve_details):
    """Use LLM to assess likelihood of AI involvement."""
    prompt = f"""
    Analyze this commit that introduced a security vulnerability:
    
    CVE: {cve_details['id']}
    Vulnerability Type: {cve_details['type']}
    
    Commit Hash: {commit_data['hash']}
    Commit Message: {commit_data['message']}
    Author: {commit_data['author']}
    
    Code Diff:
    {commit_data['diff']}
    
    Detected Signals: {commit_data['ai_signatures']}
    
    Based on:
    1. Coding patterns consistent with AI generation
    2. Commit metadata and signatures
    3. The nature of the vulnerability
    4. Commit message style and context
    
    Assess the likelihood (low/medium/high) that AI tools 
    contributed to introducing this vulnerability.
    """
    
    response = llm_client.complete(prompt, max_tokens=500)
    
    return {
        'confidence': extract_confidence(response),
        'reasoning': extract_reasoning(response),
        'ai_likely': response.confidence in ['medium', 'high']
    }

The multi-stage LLM approach uses an initial triage pass at approximately 80% precision to filter candidates, then performs deep investigation with up to 50 tool-specific API calls for high-confidence cases. When the primary LLM service fails or rate limits apply, the system falls back to Claude Agent SDK for continued analysis.

The output isn't just research data—it's structured for web visualization. The pipeline generates JSON datasets that power interactive dashboards showing trends over time: which AI tools appear most frequently in vulnerable commits, what types of vulnerabilities correlate with AI assistance, and how the landscape is evolving. This makes the research accessible beyond academic papers.

Gotcha

Let's be brutally honest about the limitations. First, you need approximately 2TB of storage for full analysis. This isn't a tool you clone and run on your laptop—it's infrastructure-dependent research software that expects dedicated compute resources and substantial GitHub API quota. If you're thinking about reproducing their analysis, budget for cloud storage costs and API rate limits.

Second, and more fundamentally, the detection methodology is metadata-dependent by necessity. When a developer accepts a Copilot suggestion without any commit signature, uses ChatGPT in their browser and manually copies code, or employs an AI tool that doesn't leave telemetry, this pipeline cannot detect it. The researchers are transparent about this: they're measuring a lower bound. The real prevalence of AI-introduced vulnerabilities is unknowable with current techniques. This has profound implications for interpreting results—a finding that '10% of CVEs show AI involvement' actually means 'at least 10%, possibly much higher.' The project documentation explicitly warns that results may contain errors and the methodology is under active development. This isn't production-ready tooling for making security decisions about your codebase. It's an experimental research platform that's still being validated and refined.

Verdict

Use if: You're conducting academic or industry research on AI coding assistant safety, you need empirical data about real-world AI-generated vulnerabilities for a conference paper or security policy, you're analyzing trends across the open-source ecosystem rather than individual projects, or you have the infrastructure budget for multi-terabyte analysis pipelines and want to contribute to this emerging research area. Skip if: You need a practical security scanner for your own repositories, you want actionable remediation advice for specific vulnerabilities, you're looking for lightweight tooling that runs in CI/CD, you lack dedicated research infrastructure and API access, or you need high-confidence attribution that holds up to audit scrutiny. This is a research telescope pointed at the ecosystem, not a microscope for your codebase.