Skip to main content

​
What is Fingerprinting?

Fingerprinting is Corgea’s intelligent method of uniquely identifying security vulnerabilities in your codebase. Think of it as a “DNA” for each security issue—a unique identifier that allows Corgea to recognize the same vulnerability across different scans, even if the code changes slightly over time.
Fingerprinting works automatically in the background. You don’t need to configure or maintain it—it’s designed to “just work” from the moment you start scanning your code.

​
How Does It Work?

When Corgea scans your code and identifies a security issue, it creates a fingerprint based on key characteristics of that issue, including:
  • Location: The file path and line number where the issue occurs
  • Context: The specific line of code and its surrounding structure
  • Classification: The type of security vulnerability (e.g., SQL Injection, XSS, etc.)
These elements are combined to create a unique, consistent identifier that persists across multiple scans of your codebase.

​
AST-Based Intelligence

Corgea uses Abstract Syntax Tree (AST) analysis to make fingerprinting more intelligent and resilient to code changes.
An Abstract Syntax Tree is a structural representation of your code that understands the meaning and relationships between different code elements—not just the text itself.Traditional fingerprinting methods that only look at exact text or line numbers can break easily when you:
  • Add or remove blank lines or comments
  • Reformat your code (change indentation, spacing, etc.)
  • Refactor variable names or function signatures
Why AST matters for you: By incorporating AST information into fingerprints, Corgea can:
  • Recognize the same vulnerability even when superficial code changes occur
  • Focus on semantic meaning rather than just text matching
  • Maintain tracking through code reorganization and refactoring
  • Reduce false positives when similar-looking but different issues appear
AST-based fingerprinting means you get more stable, reliable tracking of security issues throughout your development lifecycle—even as your code evolves.

​
Where Is Fingerprinting Used?

When you run multiple scans over time, Corgea uses fingerprints to recognize when an issue has:
  • Persisted from previous scans
  • Been fixed and is no longer detected
  • Reappeared after being resolved

​
When and Why Fingerprints Change

While Corgea’s fingerprinting is designed to be stable through minor code changes, there are legitimate scenarios where a fingerprint will change. Understanding these helps you interpret your scan results correctly.
Understanding when fingerprints change is important for accurate issue tracking and security management.

​
Situations That Will Generate a New Fingerprint

What happens: If you move a file to a different directory or rename it, the vulnerability will get a new fingerprint.Example: Moving src/utils/database.py to src/core/db.py creates a new fingerprint even if the vulnerable code is identical.Why: The file path is a core component of the fingerprint. This is intentional—it helps track where vulnerabilities exist in your project structure.What you’ll see: The old issue may appear as “fixed” and a new issue will be detected in the new location.
If you’re doing large-scale file reorganization, coordinate with your security team so they understand the context.
What happens: Major refactoring that changes the structure or context of the vulnerable code will generate a new fingerprint.Example: Converting a vulnerable inline SQL query into a database helper function with the same vulnerability would change the AST structure significantly.Why: While AST-based fingerprinting handles minor refactoring, substantial structural changes indicate the code context has meaningfully changed.What you’ll see: The original issue closes and a new one appears, even though the underlying vulnerability pattern remains.
When doing major refactoring, treat these as opportunities to fix the vulnerability rather than just moving it.
What happens: Large insertions or deletions that significantly shift where the vulnerable code sits may change the fingerprint.Example: Adding 200 lines of new code above a vulnerability might shift its context enough to change the fingerprint.Why: While fingerprinting is resilient to small line number changes, dramatic shifts suggest the code’s context within the file has changed.What you’ll see: The issue might appear to resolve and reappear at a different line number.
This is rare due to AST intelligence, but if it happens, verify the issue is truly the same before marking it as a duplicate.
What happens: If Corgea’s analysis determines that an issue should be reclassified (e.g., from “Potential SQL Injection” to “Confirmed SQL Injection”), it gets a new fingerprint.Example: Additional context in later scans might elevate or change how a vulnerability is classified.Why: The classification is part of what makes an issue unique. Different classifications may require different remediation approaches.What you’ll see: One issue closes and another with a different severity or type appears at the same location.
Pay attention to classification changes—they often indicate important new information about the security risk.
What happens: Modifying the actual vulnerable line of code (even without fixing it) may change the fingerprint.Example: Changing this:
query = "SELECT * FROM users WHERE id=" + user_id
To this:
query = "SELECT id, name FROM users WHERE id=" + user_id
Maintains the SQL injection vulnerability but changes the fingerprint.Why: The specific code context is part of the fingerprint. This is actually helpful—it shows that someone touched the code, and it’s an opportunity to fix it properly.What you’ll see: The old issue appears resolved, and a new, similar issue appears.
When modifying vulnerable code, take the opportunity to fix the security issue properly rather than just changing it superficially.

​
Situations That Won’t Change the Fingerprint

The following changes typically won’t affect the fingerprint:
  • Adding or removing comments
  • Changing whitespace or indentation
  • Renaming local variables (in most cases)
  • Adding code before or after the vulnerable line (within reason)
  • Reformatting according to style guides
  • Adding logging or debugging statements nearby

​
How to Handle Fingerprint Changes

1

Check the Issue History

Corgea tracks all historical events by fingerprint, so you can see the timeline of the original issue.
2

Review the Code Changes

Use your version control system to understand what changed between scans.
3

Update Tracking

If you’re tracking issues in external systems (JIRA, etc.), you may need to update references.
4

Consider It an Opportunity

A changed fingerprint often means someone modified the vulnerable code—this is a perfect time to ensure the fix is complete and proper.
5

Contact Support

If you believe a fingerprint changed incorrectly or unexpectedly, our team can help investigate.
You might wonder: “Why not keep the same fingerprint no matter what?” Here’s why Corgea’s approach is beneficial:
  • Accuracy: When code context genuinely changes, a new fingerprint ensures you’re tracking the current reality of your codebase.
  • Visibility: Fingerprint changes highlight that code was modified, which is valuable information for security teams.
  • Flexibility: It prevents “stale” issue tracking where an issue is marked as fixed but the vulnerability persists in a slightly different form.
  • Compliance: Audit trails are more accurate when they reflect actual code changes, not just continued existence.

​
Key Benefits

Get an accurate understanding of your security posture without false inflation from duplicate detections. Understand when code changes affect tracked vulnerabilities.

​
Questions?

If you have questions about how fingerprinting affects your specific use case, notice unexpected fingerprint changes, or want to understand more about how issues are tracked in your environment, please reach out to your Corgea support team.

Need Help?

Contact our support team for assistance with fingerprinting or any other questions.