My privacy scan found 412 leaks. 374 of them were one line of my own tooling.

A privacy scan of a repository revealed 412 potential leaks, with 374 of them originating from a single line of code. Initially, the scan appeared to identify sixteen files that needed review, but upon closer inspection, it became clear that the majority of the issues were due to one defect being repeated 374 times. The scan flagged a discrepancy in the path used by the control runs, with 35 path spans spanning 15 documents. However, 3 of the hits were false positives resulting from an ordinary word matching the pattern.

The scan found that one of the issues was related to a code generator faithfully producing the same line of code two hundred times. The number of hits was the least useful piece of information, as it only provided a broad overview of the situation. Classifying the hits by shape allowed the scan to narrow down the findings to one line of code and a small tail: a class fix for the generator's root line. The rewrite of the emitter path to a relative form and a scanner improvement also contributed to resolving the issue.

The grouping of the hits allowed for a diagnosis, where the 412 hits were categorized as one pipe. The scanner prints the path, line, and text, and normalizing the variable part of each hit before counting turned a list of 412 issues into a diagnosis. One of the changes required was modifying the scanner to use a token instead of an absolute path. The equality check in the log performed on the field kept working, as it was only comparing the field to itself across runs and never required the path to be real.

A key takeaway from this experience was that a violation count is a symptom count, not a cause count. It is essential to group by shape before deciding on the necessary work. Additionally, it is crucial to check what your own tooling prints into permanent records, as application code and build controls often do not receive the same level of scrutiny as other parts of the codebase.