Table 5.

Summary of open-ended responses on classifying true vs. false positives (A1.6)

Category*	Description	Example	Count(%)
Dummy secret for testing (TR)	Data used to drive security test cases.	“It was a test input to verify end to end flow in test pass”	5 (33%)
Secret for test asset (DR)	Actual secrets used to secure test assets.	“It was an actual credential, but only for unit test purposes, so we will not remove it”	2 (13%)
Legacy secret (TR)	Potential secret was already exposed, not newly introduced.	“It was a possible credential pulled from a public open source GitHub repo into our private fork”	2 (13%)
False positive (TR)	Detection was a false positive with insufficient detail to classify as placeholder, dummy, etc.	“It was a variable name or string containing the word Password only”	2 (13%)
Secret placeholder (TR)	Detection was a placeholder, i.e., a value that is expanded or transformed at run-time.	“Not an actual credential, but I didn’t include the “placeholder” text to clarify that”	1 (7%)
Not a secret (TR)	The detected code is not an actual, dummy or placeholder secret.	“The GUID flagged looked like a secret but is not a secret”	1 (7%)
Developer error (DR)	A potential secret was bypassed unintentionally.	“I actually made a mistake. I had reset to the first change I had made, rather than the change before. I thought [XSDT] was failing to see that I had reset, so I had it bypass.”	1 (7%)
No better alternative (DR)	The developer did not perceive a better solution for securing the secret.	“It was an actual credential, and unfortunately the alternate ways to pass in the password to [...] apart from plaintext is no more safer than it”	1 (7%)

*For XTech’s internal use, the categories are interpreted as follows. Dummy secret for testing, False positives, Secret placeholder, and Not a secret are treated as A1.1, Secret for test asset as A1.2, Developer error, No better alternative as A1.3, Legacy secret as A1.5