Published on: August 12, 2026
3 min read
Learn how GitLab's improved Scope+Offset fingerprinting keeps vulnerability tracking stable across comments, blank lines, and reformatting.
Every day, security scans face the same problem: an agent or a developer adds a comment, reformats a file, or moves a function, and a naive vulnerability tracker suddenly reports the same finding twice. Security teams end up re-triaging issues they already dismissed, which causes futile auditing effort and erodes trust in the scan results.
In 2022, we introduced advanced vulnerability tracking to tackle exactly this problem of code volatility. It is based on our Scope+Offset fingerprinting method: instead of identifying a finding by file and line number, we identify it by its narrowest enclosing scope (module, class, function) plus its line offset within that scope. That made tracking robust against code moving around the file and reduced futile re-auditing by about 30% compared to line-based tracking.
But one class of edits still slipped through: non-functional changes. The offset counted every line between the scope boundary and the finding, including comments and blank lines. Add a comment above a vulnerable statement, and the offset shifts. The tracker sees a "new" vulnerability; you see a duplicate.
Our improved method addresses this by simply ignoring non-functional code (comments and blank lines) when computing the fingerprint. Since these lines do not affect the program's behavior, they should not affect the identity of a vulnerability either. With this normalization in place, adding a comment or reformatting a file no longer changes the fingerprint, while the precision of the tracking remains the same as before. The details of the approach are described in our accompanying research paper.
We evaluated the normalized method on a targeted benchmark: 439 source files across C/C++, C#, Go, Java, JavaScript, Python, and Ruby. We generated 2,247 commits, each inserting a single comment or blank line directly before a known vulnerability, and scanned the code as the history was replayed. The benchmark deliberately stresses the worst case: every commit is a non-functional edit right next to a finding.
On this benchmark, the original Scope+Offset method accumulated 1,361 duplicate fingerprints, a 77% growth over the baseline. The normalized method produced zero duplicates and reduced unique fingerprints by 43% overall.
Normalized Scope+Offset ships in GitLab as the scope_offset_compressed
tracking algorithm, supporting C#, C/C++, Go, Java, JavaScript, Python, Ruby, and PHP. It reuses the parse tree the scanner already constructs, so scan times are unaffected. The security report format is unchanged, so it composes with any combination of SAST tools in a heterogeneous setup.
The preprint of our study "Vulnerability Tracking using Normalized Scope+Offset" by Julian Thome, Hua Yan, Lucas Charles, Craig Smith, and Jason Leasure will be presented at the ASE 2026 Industry Showcase.
Hua Yan, Lucas Charles, Craig Smith, and Jason Leasure contributed to this article and study.
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedbackStart building faster today
See what your team can do with the intelligent orchestration platform for DevSecOps.
Facts Only
* GitLab published a technical update on August 12, 2026.
* The update introduces the `scopeoffsetcompressed` tracking algorithm.
* The method identifies vulnerabilities using a combination of the narrowest enclosing scope and a line offset.
* The updated version excludes comments and blank lines from the offset calculation.
* A benchmark was conducted using 439 source files in C/C++, C#, Go, Java, JavaScript, Python, and Ruby.
* The benchmark consisted of 2,247 commits, each adding one comment or blank line before a vulnerability.
* The original Scope+Offset method generated 1,361 duplicate fingerprints in this benchmark.
* The normalized method generated zero duplicates.
* Supported languages include C#, C/C++, Go, Java, JavaScript, Python, Ruby, and PHP.
* A research paper titled "Vulnerability Tracking using Normalized Scope+Offset" is scheduled for the ASE 2026 Industry Showcase.
* Authors of the study include Julian Thome, Hua Yan, Lucas Charles, Craig Smith, and Jason Leasure.
Executive Summary
GitLab has updated its vulnerability tracking mechanism to address "code volatility," where non-functional changes like comments or blank lines trigger duplicate vulnerability reports. The previous Scope+Offset method identified findings by their narrowest enclosing scope and the line offset within that scope. However, because this offset included all lines, simple reformatting often shifted the fingerprint, leading to futile re-triaging of dismissed issues.
The new normalized approach, implemented as the `scopeoffsetcompressed` algorithm, ignores non-functional code when calculating fingerprints. Testing on a benchmark of 439 source files across seven languages showed that while the original method produced 1,361 duplicate fingerprints during a series of non-functional edits, the normalized method produced zero. This update supports C#, C/C++, Go, Java, JavaScript, Python, Ruby, and PHP, utilizing existing parse trees to ensure scan times remain unaffected.
Full Take
This content functions in ACADEMIC MODE, as it presents a specific methodology, benchmark data, and a forthcoming peer-reviewed presentation at ASE 2026.
The methodology is sound for its narrow objective: reducing false-positive duplicates caused by non-functional edits. By utilizing the parse tree to normalize the offset, the researchers isolate the functional identity of the code from its visual representation. However, a peer reviewer would note that the benchmark is an "extreme worst-case" scenario—inserting comments directly before vulnerabilities—which proves the mechanism works but doesn't necessarily quantify the real-world frequency of this specific problem.
The claims are proportionate to the evidence; the authors do not claim to have solved all vulnerability tracking issues, only the specific "non-functional edit" problem. This extends existing knowledge of Scope+Offset tracking by adding a normalization layer. For this to matter outside the lab, the parse trees used must be consistently accurate across the diverse language set mentioned; any deviation in how different languages handle "non-functional" lines could reintroduce instability.
The root cause of this development is the tension between human-readable code (which requires comments and spacing) and machine-readable identifiers (which prefer static offsets). It echoes the broader evolution of compilers and linters moving toward AST-based (Abstract Syntax Tree) analysis rather than text-based analysis.
Bridge Questions:
1. How does this method handle "functional" changes that don't change the logic but change the scope (e.g., wrapping a block in a new try-catch)?
2. Would the introduction of automated code formatters (like Prettier or Black) render this specific normalization redundant or even more critical?
Counterstrike Scan: This is a standard technical disclosure of a product improvement backed by scholarly intent. It does not align with any coordinated influence campaign.
Sentinel — Human
This content reads like a technical announcement or blog post detailing a specific software engineering solution and its experimental validation, exhibiting the structure of human-authored technical communication.