Pith. sign in

REVIEW 3 major objections 6 minor 81 references

Checked-In Secret Detection: Strings Are All You Need

T0 review · 3 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper claims that string literals are the critical semantic signal for detecting hardcoded secrets: extracting only nearby strings preserves 81% of the meaning in a third of the text and lets a dual-stream classifier reach weighted F1…

desk verdict Solid, practical secret-detection paper with strong robustness results; the headline 'strings are all you need' claim is weaker than the ablation data for one of the two headline models. read the letter →

arxiv 2608.04523 v1 pith:CE26KD2V submitted 2026-08-05 cs.CR cs.SE

Zhengdong Huang , Kevin Li , Jinqiu Yang , Yepang Liu , Lili Wei This is my paper
classification cs.CRcs.SE
keywords hardcodedsecretssecretdetectionstringliteralscontextextractionobfuscationrobustnesscross-languagegeneralizationTransformerCNN
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper is trying to establish that the strings surrounding a hardcoded secret are the most reliable evidence that a secret is a secret. It argues that comments, identifiers, and syntax all fail under obfuscation or language shift, but string literals such as connection URLs, parameter names, and authentication headers are preserved, language-independent, and densely informative. On that basis it proposes StringGroup, which replaces the usual code-snippet context with the nearby string literals alone, and Secretron, a dual-stream classifier that reads that string context plus the literal itself. If the claim holds, secret detection no longer needs hand-written patterns or huge context windows, and can work on obfuscated or decompiled apps. The reported numbers, weighted F1 0.9874 on SecretBench, 0.9528 under obfuscation, 0.9290 on unseen languages, and 48 verified in-the-wild secrets, are the evidence offered.

What carries the argument

StringGroup is the central object: a line-based context-extraction algorithm that, for a candidate string literal, starts at its line and expands outward by radius $R$ (set to 20) collecting every string literal on each line, compressing multiline strings, dropping high-entropy strings (replaced by a `<RND>` token), removing one-character words, tagging numbers, emails, IPs, and URLs, splitting camelCase and PascalCase words, and subword-tokenizing until a token budget $S$ (set to 500) is reached, then stops. It is the single modification that removes syntax, identifiers, comments, and boilerplate, leaving only the semantic layer the paper claims is obfuscation-proof and language-neutral. Secretron is the second piece, a dual-stream classifier whose Transformer context encoder reads the StringGroup output and whose parallel convolutional secret encoder reads the candidate string's characters, with the two streams fused before a two-head output for detection and categorization.

What would settle it

Take a held-out set of true secrets from SecretBench, apply a string-encryption obfuscator such as StringFog-style static decryption or OLLVM string encryption to the source, and run Secretron; if its F1 does not drop toward the identifier-based baselines, the paper's claim that strings are the load-bearing signal is wrong. A simpler check is to randomly replace every non-secret string literal with an opaque token and measure whether detection accuracy collapses.

Watch

Extended reading notes

Core claim

The central discovery is that string literals are a critical, and largely sufficient, information source for code semantics in the secret-detection setting. StringGroup collects strings in an expanding radius around each candidate literal, filters high-entropy and unusably short strings, tags special formats, and tokenizes; this compresses the input to 33.2% of its original length while retaining 81.37% semantic similarity and 69.96% distributional similarity. Secretron feeds this string context through a Transformer and the candidate through a character-level multi-scale CNN, fuses the two representations, and predicts both whether the candidate is a secret and what type it is. On SecretBench the tool reports weighted F1 0.9874; under language-specific obfuscation plus decompilation, F1 stays at 0.9528 to 0.9581, roughly 97% of its original performance, while all tested baselines drop below 0.77; on five languages never seen in training, F1 is 0.9290 to 0.9466.

Load-bearing premise

The method assumes every real secret is, and stays, a plaintext string literal in the code: if an obfuscator encrypts strings or builds them at runtime, and decompilation cannot recover them, the string context that carries the whole signal disappears and detection collapses.

Editorial extensions

If this is right

  • Secrets with no fixed pattern, such as arbitrary passwords and database keys, become detectable purely from context, replacing the need for hundreds of handcrafted regex rules.
  • If string literals survive renaming, detection accuracy stays near its original level, so scanning decompiled or obfuscated apps works without training on obfuscated code.
  • A model trained on JavaScript, Python, Go, Java, and C++ transfers to PHP, Ruby, C#, Scala, and Swift at F1 around 0.93 to 0.95 despite never seeing those languages.
  • Using only 33.2% of the original context shortens inputs, and the 0.11B-parameter Lite variant runs roughly 10 times faster than the 7B variant, making the approach practical for CI/CD-style scanning.
  • Scanning 900 real Android apps from Google Play yielded 48 verified secrets in 26 apps at 88.9% precision, including secret types absent from the training set.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • An unstated consequence is that any obfuscator that encrypts or dynamically reconstructs string literals, such as StringFog-style string encryption or VM-based obfuscation, should defeat the method; the paper itself concedes this, so a natural extension is to run string-decryption recovery before StringGroup.
  • The same strings-only preprocessing logic could transfer to other code-understanding tasks where identifiers are unreliable, such as malware family classification or decompiled-code analysis; the authors do not claim this extension.
  • The candidate rule, every literal longer than six non-space characters, is an implicit upper bound on recall, since a genuine secret of seven characters or fewer will never be examined; the paper's own ablation shows that lowering the threshold to three retains all secrets but inflates the candidate set 6.3 times.
  • Because extraction is line-based, heavily minified or generated code with many tokens per line could shift performance, and the AST-based alternative named as future work is not evaluated here.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. Secretron is a context-aware secret detection tool. The paper's central idea is StringGroup, a preprocessing step that extracts only string literals around each candidate secret string, discarding identifiers, comments, and syntactic structure. Secretron combines a Transformer context encoder initialized with pretrained code/language models and a character-level CNN secret encoder, with two output heads for detection and secret-type classification. On SecretBench, Ours-Acc reaches weighted F1 0.9874 and Ours-Lite 0.9823, outperforming regex-based and learning-based baselines. The paper also reports robustness to obfuscation (F1 0.9528 for Ours-Lite and 0.9581 for Ours-Acc) and cross-language generalization (F1 0.9290 and 0.9466), plus an in-the-wild study of 900 Google Play apps that found 48 verified secrets in 26 applications. The main claim is that string literals are an obfuscation-resilient, language-independent, compact context source, and that narrowing context to strings yields significant detection gains.

Significance. If the empirical results hold, Secretron is a strong practical contribution to secret detection, and StringGroup is a simple and cheap contextual feature that appears to transfer across languages and survive common obfuscation. The paper's strengths include: evaluation on a large public benchmark with repository-level splits and bootstrap resampling; comparison against multiple baselines, including two LLM-based detectors; statistical tests; release of source code; and a careful in-the-wild verification procedure with two human annotators and inter-rater agreement. I found no circularity in the evaluation: labels come from the external SecretBench dataset, and the self-cited prior Android studies are used as related work and motivating context rather than as the source of the reported numbers. The central caveat is that the component-level ablation does not uniformly support the headline claim: on Ours-Lite, the default non-obfuscated benchmark result is slightly better without StringGroup. The paper is likely right that strings matter, but the claims need to be calibrated to the evidence.

major comments (3)
  1. [§4.3, Tables 3 and 4] The ablation evidence does not support the unqualified claim that StringGroup improves detection accuracy on the main benchmark. In Table 3 the Ours-Lite configuration scores W-F1 0.9823 with StringGroup and 0.9838 without it; Table 4 repeats the identical pair (Origin 0.9823, W/O StrG. 0.9838). For Ours-Acc, by contrast, removing StringGroup lowers W-F1 from 0.9874 to 0.9786. The text's explanation that the Ours-Lite result 'might be attributable to specific pre-trained weights' is not argued for: Ours-Acc also uses pre-trained weights and shows the opposite pattern. Because the abstract and Section 1 claim 'significant gains' from narrowing context to string literals, and the RQ2 takeaway states that StringGroup improves 'prediction accuracy across context models,' the paper must either correct the reported numbers, identify a mechanism explaining the CodeBERT-specific reversal, or explicitly restate the claim so that it is limited to Ours-Acc and to the obfuscation and cross-language robustness settings.
  2. [§4.3, Table 8; §4.4.2] The in-depth analysis of StringGroup (33.2% length, 81.37% average of BERTScore and SBERT similarity, and the rank comparison against Comment, Identifier, and Syntax extraction) measures information preservation, not downstream detection quality. The only end-to-end comparison is the W/O StrG ablation, which is mixed for Ours-Lite. To substantiate the claim that semantic compactness 'significantly improves the signal-to-noise ratio for secret detection,' the authors should report detection F1 when the context encoder is fed Comment, Identifier, or Syntax extraction instead of StringGroup, or explicitly limit the claim to the information-preservation metrics. As written, the link between the similarity analysis and the headline detection gain is asserted rather than demonstrated.
  3. [§4.2, §4.4.1] The experimental setup for the baseline models is ambiguous across RQ1 and RQ3. Section 4.2 states that LLM-based baselines are evaluated 'using their reported best-performing publicly available pretrained models,' while Section 4.4.1 states that 'all tools are trained on the same unobfuscated training set.' These statements are in tension: if the RQ3 baselines were retrained, the training procedure should be described; if they were not, the comparison may be unfair because the obfuscated test-set distribution differs from the baselines' original training distribution. Please clarify the protocol and, if retraining occurred, provide hyperparameters or a reference to the exact procedure.
minor comments (6)
  1. [§4.2] The text refers to 'the best baseline (ContextLLM)' with F1 0.9420, but Table 1 names this row 'Rahman's Tool'; please unify the terminology so the reader can locate the result.
  2. [Table 1] The Naive Bayes row shows three values without separators ('0.52720.99040.6881'); this is a formatting error that makes the table hard to read.
  3. [§3.1.1, Algorithm 1] Algorithm 1 uses 'Valid lines' and 'ExtractStrings' without specifying how string literals are lexically identified; Section 5.2 mentions '9 universal rules' but does not enumerate them. Please add the rules or point to the corresponding code location for reproducibility.
  4. [§4.1.3] The implementation details list optimizer, epochs, and learning rate, but omit batch size, maximum sequence length, CNN kernel sizes, and the exact fine-tuning procedure used for Ours-Acc; please add these or refer precisely to the released code.
  5. [Table 3] The table heading 'Weight F1-Score' should be 'Weighted F1-Score'; the caption 'Secret Classification Ablation Result' should be pluralized for grammatical consistency.
  6. [§5.2] The sentence about 'OLLVM extensions [70]' cites reference [70], which concerns iOS apps; please verify that this is the intended citation for OLLVM-based string protections.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity identified; SecretBench F1 and in-the-wild findings rest on held-out external labels and manual verification, with no input-equivalent prediction.

full rationale

I walked the derivation chain from StringGroup's string-only context extraction to the SecretBench evaluation. The central numbers (F1 0.9874/0.9823, obfuscation F1 0.9528, cross-language F1 0.9290) come from training on external labels (SecretBench) and evaluating on a repository-level held-out split; no equation or fitted parameter is recycled as the measured result. StringGroup's 33.2% length and 81.37% similarity figures are descriptive measurements comparing the transformed context to the original, not predictions whose inputs determine the output. The paper's only self-references ([44,45,72]) are used for Android-detection protocol reuse and related-work context; the SecretBench comparison does not depend on an unverified self-citation. The acknowledged limitations in Sec. 5.2 (string encryption, decompiler dependence) are scope statements, not circular moves. The one serious issue is internal consistency: Tables 3 and 4 report W/O StrG. 0.9838 vs Origin 0.9823 for Ours-Lite, undercutting the claim that StringGroup improves the default Lite model; however, this is a support/validity weakness, not a reduction of the result to its inputs, so it does not raise the circularity score.

Assumptions & free parameters 5 free parameters · 5 assumptions · 0 invented entities

The central empirical claim rests on standard supervised learning assumptions (reliable labels, held-out splits), on the domain assumption that hardcoded secrets appear as string literals that survive obfuscation and decompilation, and on several hyperparameters (R, M, length threshold, loss weights) tuned on the benchmark. No new physical or mathematical entities are introduced.

free parameters (5)
  • Context window radius R = 20
    Ablated in Section 4.3 (R=5,10,20,50); 20 chosen as balance between accuracy and efficiency.
  • Maximum extracted tokens M = 500
    Ablated in Section 4.3 (M=100,200,500,1000); 500 chosen as the point of diminishing returns.
  • Minimum candidate string length = 6
    Section 3.1.3 sets every string literal longer than 6 characters as a candidate; ablation in Table 5 shows len=6 best balances recall and noise.
  • Loss weights w1, w2 = 0.5, 0.5
    Section 4.1.3 sets equal weighting between detection and categorization losses; no sensitivity analysis reported.
  • String filtering thresholds = High-entropy replacement, length filter, special format regexes
    Section 3.1.2 hand-selects Shannon entropy and format regexes; these choices are not individually ablated.
assumptions (5)
  • domain assumption String literals are preserved under common obfuscation and are language-independent.
    The entire StringGroup method rests on this, argued in Section 1 and Section 2 with examples; Section 5.2 concedes string encryption violates it.
  • domain assumption SecretBench provides accurate ground-truth labels for training and evaluation.
    Section 4.1.1 uses SecretBench without re-validating the labels; Section 5.1 notes annotation quality is a known threat.
  • standard math Shannon entropy is a valid indicator of string randomness for filtering context.
    Used in Section 3.1.2 to replace high-entropy strings with <RND>; the filtering ablation in Table 5 suggests entropy filtering hurts recall.
  • domain assumption Decompiled Android source via Jadx retains string literals needed for detection.
    Section 4.5 scans APKs decompiled with Jadx; Section 5.2 notes decompilation quality bounds the approach.
  • domain assumption The top-5 versus bottom-5 language split isolates cross-language generalization without test leakage.
    Section 4.4.2 trains on JavaScript, Python, Go, Java, C/C++ and tests on PHP, Ruby, C#, Scala, Swift; no leakage analysis beyond repo-level split.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Checked-In Secret Detection: Strings Are All You Need." pith.science (2026). https://pith.science/paper/CE26KD2V

@misc{pith2026260804523,
  author       = {Pith},
  title        = {Pith review of: Checked-In Secret Detection: Strings Are All You Need},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CE26KD2V}},
  note         = {Machine review of arXiv:2608.04523}
}
read the original abstract

Hardcoded secrets in source code pose critical security vulnerabilities which can be easily exploited by malicious adversaries. Existing regex-based detection approaches suffer from fundamental limitations, as secrets often lack identifiable patterns, resulting in poor precision and recall. Recent studies have explored context-aware detection methods, as surrounding code can reveal the purpose of candidate strings. However, these methods confront three key challenges: (1) obfuscation robustness where models over-rely on easily obfuscated identifiers, (2) cross-language generalization difficulties due to uneven training data distribution, and (3) lengthy and noisy context that introduces excessive irrelevant tokens and slows inference. We observe that strings serve as a critical information source for code semantics, offering superior contextual density, obfuscation robustness, and language independence. Based on this insight, we propose StringGroup, a novel context extraction algorithm that mines strings surrounding potential secrets. By introducing a relatively simple modification to existing patterns that narrows the analysis specifically to string literals, the method achieves significant gains. With only 33.2% of the original context, it preserves over 80% of semantic information and significantly improves the signal-to-noise ratio for secret detection. We further design a context-aware secret detection tool, Secretron, based on StringGroup methods and Transformer model. Evaluation on the SecretBench dataset demonstrates high accuracy with 98.74% F1-score and strong robustness under obfuscation and cross-language scenarios, outperforming state-of-the-art LLM-based baselines. We deploy our tool in real-world environments and successfully detect 48 previously unknown secret keys from 26 applications, demonstrating the practical effectiveness of our approach.

Figures

Figures reproduced from arXiv: 2608.04523 by the authors.

Figure 1
Figure 1. Design of Secretron where these two streams are then fused for the final determination. We will introduce the details of StringGroup and the classifier in Section 3.1 and Section 3.2 respectively. 3.1 StringGroup Method StringGroup is a new lightweight context extraction method based on string literals. Leveraging the principle of program locality, it efficiently captures meaningful strings around candidate secrets … view at source ↗
Figure 2
Figure 2. Overall performance and distribution analysis of the proposed method. [PITH_FULL_IMAGE:figures/full_fig_p017_2.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

81 extracted references · 56 canonical work pages

  1. [1]

    Combiner l’analyse statique et la génération de tests pour une assurance qualité améliorée : Une exploration des problèmes de compatibilité Android

    2025. Combiner l’analyse statique et la génération de tests pour une assurance qualité améliorée : Une exploration des problèmes de compatibilité Android. doi:10.69777/363482

    work page doi:10.69777/363482 2025

  2. [2]

    Google Play

    2025. Google Play. https://play.google.com. Accessed: 2025-08-16

    2025

  3. [3]

    Our Website

    2025. Our Website. https://anonymous.4open.science/r/Iuhv2veg/README.md

    work page 2025

  4. [4]

    DeepSeek AI. 2025. DeepSeek LLM 7B Base: A 7 Billion-Parameter Bilingual (EN/ZH) Language Model. https: //huggingface.co/deepseek-ai/deepseek-llm-7b-base. Version 1.0

    work page 2025

  5. [5]

    Simone Aonzo, Gabriel Claudiu Georgiu, Luca Verderame, and Alessio Merlo. 2020. Obfuscapk: An open-source black-box obfuscation tool for Android apps.SoftwareX11 (2020), 100403. doi:10.1016/j.softx.2020.100403

    work page arXiv 2020

  6. [6]

    Setu Kumar Basak, Jamison Cox, Bradley Reaves, and Laurie Williams. 2023. A Comparative Study of Software Secrets Reporting by Secret Detection Tools. In2023 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). 1–12. doi:10.1109/ESEM56168.2023.10304853

    arXiv 2023

  7. [7]

    Setu Kumar Basak, K Virgil English, Ken Ogura, Vitesh Kambara, Bradley Reaves, and Laurie Williams. 2025. Assethar- vester: A static analysis tool for detecting secret-asset pairs in software artifacts. In2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE, 01–13

    work page 2025

  8. [8]

    Setu Kumar Basak, Lorenzo Neil, Bradley Reaves, and Laurie Williams. 2023. SecretBench: A Dataset of Software Secrets. In2023 IEEE/ACM 20th International Conference on Mining Software Repositories (MSR). 347–351. doi:10.1109/ MSR59073.2023.00053

    arXiv 2023

Show all 81 references
  1. [9]

    2016–2024

    Benf. 2016–2024. CFR: Another Java Decompiler. https://github.com/leibnitz27/cfr Accessed: 2025-08-08

    2016

  2. [10]

    Yoav Benjamini and Yosef Hochberg. 1995. Controlling the false discovery rate: a practical and powerful approach to multiple testing.Journal of the Royal statistical society: series B (Methodological)57, 1 (1995), 289–300

    1995

  3. [11]

    Chidera Biringa and Gökhan Kul. 2025. Detecting Hard-Coded Credentials in Software Repositories via LLMs.Digital Threats: Research and Practice6, 3 (2025), 1–16

    2025

  4. [12]

    Tianqi Chen and Carlos Guestrin. 2016. Xgboost: A scalable tree boosting system. InProceedings of the 22nd acm sigkdd international conference on knowledge discovery and data mining. 785–794

    2016

  5. [13]

    Xiang Chen, Chaoyang Gao, Chunyang Chen, Guangbei Zhang, and Yong Liu. 2025. An Empirical Study on Challenges for LLM Application Developers.ACM Trans. Softw. Eng. Methodol.34, 7, Article 205 (Aug. 2025), 37 pages. doi:10. 1145/3715007

    2025

  6. [14]

    Charles J Clopper and Egon S Pearson. 1934. The use of confidence or fiducial limits illustrated in the case of the binomial. 404–413 pages

    1934

  7. [15]

    1977.Sampling techniques(3rd ed.)

    William G Cochran. 1977.Sampling techniques(3rd ed.). John Wiley & Sons

    1977

  8. [16]

    2022.Companies are sharing their secret access codes on GitHub—and they may not even know it

    Keith Collins. 2022.Companies are sharing their secret access codes on GitHub—and they may not even know it. https://qz. com/674520/companies-are-sharing-their-secret-access-codes-on-github-and-they-may-not-even-know-it Quartz, Updated July 21, 2022

    2022

  9. [17]

    Nick Craig-Wood and Contributors. 2021. gobfuscate: Obfuscate Go binaries and packages. https://github.com/ unixpickle/gobfuscate. GitHub repository, last updated Dec 8, 2021

    2021

  10. [18]

    Martijn de Vos and Johan Pouwelse. 2021. ASTANA: Practical string deobfuscation for Android applications using program slicing.arXiv preprint arXiv:2104.02612(2021)

    2021 arXiv

  11. [19]

    Alexandre Dey, Loic Beheshti, and Marie-Kerguelen Sido. 2018. Health State of Google’s PlayStore-Finding Malware in Large Sets of Applications from the Android Market.. InICISSP. 538–544

    2018

  12. [20]

    Shuaike Dong, Menghao Li, Wenrui Diao, Xiangyu Liu, Jian Liu, Zhou Li, Fenghao Xu, Kai Chen, Xiaofeng Wang, and Kehuan Zhang. 2018. Understanding android obfuscation techniques: A large-scale investigation in the wild. In International conference on security and privacy in com...

    2018

  13. [21]

    dwyl. 2025. english-words: A text file containing over 466k English words. https://github.com/dwyl/english-words. Accessed: 2026-05-02

    2025

  14. [22]

    Bradley Efron. 1992. Bootstrap methods: another look at the jackknife. InBreakthroughs in statistics: Methodology and distribution. Springer, 569–593

    1992

  15. [23]

    El-Kassas, Cherif R

    Wafaa S. El-Kassas, Cherif R. Salama, Ahmed A. Rafea, and Hoda K. Mohamed. 2021. Automatic text summarization: A comprehensive survey.Expert Systems with Applications165 (2021), 113679. doi:10.1016/j.eswa.2020.113679

    2021

  16. [24]

    Tom Fawcett. 2006. An introduction to ROC analysis.Pattern recognition letters27, 8 (2006), 861–874

    2006

  17. [25]

    Runhan Feng, Ziyang Yan, Shiyan Peng, and Yuanyuan Zhang. 2022. Automated detection of password leakage from public github repositories. InProceedings of the 44th International Conference on Software Engineering. 175–186

    2022

  18. [26]

    Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, et al. 2020. Codebert: A pre-trained model for programming and natural languages. InFindings of the association for computational linguistics: EMNLP 2020. 1536–1547

    2020

  19. [27]

    Daniel Flook. 2024. Python Minifier: Transform Python source code into its most compact representation. https: //github.com/dflook/python-minifier Accessed: 2025-08-08

    2024

  20. [28]

    2011.Introduction to Data Mining

    Guy Fouché and Lynn Langit. 2011.Introduction to Data Mining. Apress, Berkeley, CA, 369–402. doi:10.1007/978-1- 4302-3325-1_14

    2011 doi

  21. [29]

    Milton Friedman. 1937. The use of ranks to avoid the assumption of normality implicit in the analysis of variance. 675–701 pages

    1937

  22. [30]

    GitHub. 2025. Secret scanning. https://docs.github.com/en/code-security/secret-scanning. Accessed: 2025-08-16

    2025

  23. [31]

    GitHub. 2025. Security Advisories. https://github.com/advisories. Accessed: 2025-08-16

    2025

  24. [32]

    glades. 2023. How to Best Obfuscate a Built-In Key in an Application? Stack Overflow (Information Security). https://stackoverflow.com/questions/77037787/how-to-best-obfuscate-a-built-in-key-in-an-application Question ID 77037787

    2023

  25. [33]

    Leonid Glanz, Patrick Müller, Lars Baumgärtner, Michael Reif, Sven Amann, Pauline Anthonysamy, and Mira Mezini

  26. [34]

    Grassi, James L

    Paul A. Grassi, James L. Fenton, Elaine M. Newton, Ray A. Perlner, Andrew R. Regenscheid, William E. Burr, Justin P. Richer, Naomi B. Lefkovitz, Jamie M. Danker, Yee-Yin Choong, Kristen K. Greene, and Mary F. Theofanos. 2017. Digital Identity Guidelines: Authentication and Lif...

    2017 doi

  27. [35]

    Guardsquare NV. 2025. ProGuard: Java optimizer and obfuscator. https://github.com/Guardsquare/proguard Accessed: 2025-08-08

    2025

  28. [36]

    Kilem Li Gwet. 2008. Computing inter-rater reliability and its variance in the presence of high agreement.Brit. J. Math. Statist. Psych.61, 1 (2008), 29–48

    2008

  29. [37]

    Ruidong Han, Huihui Gong, Siqi Ma, Juanru Li, Chang Xu, Elisa Bertino, Surya Nepal, Zhuo Ma, and Jianfeng Ma. 2023. A credential usage study: flow-aware leakage detection in open-source projects.IEEE Transactions on Information Forensics and Security19 (2023), 722–734

    2023

  30. [38]

    Sakshini Hangloo and Bhavna Arora. 2025. Multimodal fusion techniques: review, data representation, information fusion, and application areas.Neurocomputing(2025), 130827

    2025

  31. [39]

    Ernst Hellinger. 1909. Neue begründung der theorie quadratischer formen von unendlichvielen veränderlichen.Journal für die reine und angewandte Mathematik1909, 136 (1909), 210–271

    1909

  32. [40]

    2011.Protect string constant against reverse-engineering

    Anuj Jindal. 2011.Protect string constant against reverse-engineering. Stack Overflow. https://stackoverflow.com/a/ 7436483 Stack Overflow answer, accessed 2025-08-16

    2011

  33. [41]

    Pascal Junod, Julien Rinaldini, Johan Wehrli, and Julie Michielin. 2015. Obfuscator-LLVM – Software Protection for the Masses. InProceedings of the IEEE/ACM 1st International Workshop on Software Protection, SPRO’15, Firenze, Italy, May 19th, 2015, Brecht Wyseur (Ed.). IEEE, 3...

    2015 doi

  34. [42]

    2016–2024

    Timofey Kachalov. 2016–2024. JavaScript Obfuscator: A powerful obfuscator for JavaScript and Node.js. https: //github.com/javascript-obfuscator/javascript-obfuscator Accessed: 2025-08-08

    2016

  35. [43]

    Mikhail V Koroteev. 2021. BERT: a review of applications in natural language processing and understanding.arXiv preprint arXiv:2103.11943(2021)

    2021 arXiv

  36. [44]

    Kevin Li. 2025. Checked-in secret detection in Android apps looking to the future, reflecting on the past. (2025)

    2025

  37. [45]

    Kevin Li, Lin Ling, Jinqiu Yang, and Lili Wei. 2026. Automatically Detecting Checked-In Secrets in Android Apps: How Far Are We?Empirical Software Engineering31, 2 (2026), 31

    2026

  38. [46]

    Jianhua Lin. 2002. Divergence measures based on the Shannon entropy.IEEE Transactions on Information theory37, 1 (2002), 145–151. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA116. Publication date: October 2026. Checked-In Secret Detection: Strings Are All You Need I...

    2002

  39. [47]

    2021.Sampling: design and analysis

    Sharon L Lohr. 2021.Sampling: design and analysis. Chapman and Hall/CRC

    2021

  40. [48]

    Sofiane Lounici, Marco Rosa, Carlo Maria Negri, Slim Trabelsi, and Melek Önen. 2021. Optimizing Leak Detection in Open-source Platforms with Machine Learning Techniques.. InICISSP. 145–159

    2021

  41. [49]

    MegatronKing. 2024. StringFog: An Android plugin for automatic string encryption in bytecode. https://github.com/ MegatronKing/StringFog GitHub repository, version 5.2.0, Apache-2.0 License

    2024

  42. [50]

    Michael Meli, Matthew R McNiece, and Bradley Reaves. 2019. How bad can it git? characterizing secret leakage in public github repositories.. InNDSS

    2019

  43. [51]

    Olha Mykhaylova, Taras Fedynyshyn, and Artem Platonenko. 2024. Hardcoded credentials in Android apps: Service exposure and category-based vulnerability analysis.Cybersecurity Providing in Information and Telecommunication Systems II 20243826 (2024), 206–211

    2024

  44. [52]

    2019–2025

    National Security Agency (NSA). 2019–2025. Ghidra: Software Reverse Engineering Framework. https://github.com/ NationalSecurityAgency/ghidra Accessed: 2025-08-08

    2019

  45. [53]

    2025.PreEmptive Protection DashO™Version 12.5.0 Documentation

    PreEmptive Solutions, LLC. 2025.PreEmptive Protection DashO™Version 12.5.0 Documentation. PreEmptive Solutions, LLC. https://www.preemptive.com/products/dasho/ User Guide, Version 12.5.0

    2025

  46. [54]

    Alec Radford, Jeffrey Wu, Rewon Child, David Luan, Dario Amodei, Ilya Sutskever, et al. 2019. Language models are unsupervised multitask learners.OpenAI blog1, 8 (2019), 9

    2019

  47. [55]

    Md Nafiu Rahman, Sadif Ahmed, Zahin Wahab, SM Sohan, and Rifat Shahriyar. 2025. Secret breach detection in source code with large language models. In2025 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). IEEE, 207–217

    2025

  48. [56]

    Nils Reimers and Iryna Gurevych. 2019. Sentence-bert: Sentence embeddings using siamese bert-networks. In Proceedings of the 2019 conference on empirical methods in natural language processing and the 9th international joint conference on natural language processing (EMNLP-IJC...

    2019

  49. [57]

    Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Romain Sauvestre, Tal Remez, et al. 2023. Code llama: Open foundation models for code.arXiv preprint arXiv:2308.12950 (2023)

    2023 arXiv

  50. [58]

    Aakanksha Saha, Tamara Denning, Vivek Srikumar, and Sneha Kumar Kasera. 2020. Secrets in source code: Reducing false positives using machine learning. In2020 International Conference on COMmunication Systems & NETworkS (COMSNETS). IEEE, 168–175

    2020

  51. [59]

    Seemanta Saha, Ismet Burak Kadron, William Eiers, Lucas Bang, and Tevfik Bultan. 2022. Attack synthesis for strings using meta-heuristics.ACM SIGSOFT Software Engineering Notes43, 4 (2022), 56–60

    2022

  52. [60]

    Victor Sanh, Lysandre Debut, Julien Chaumond, and Thomas Wolf. 2020. DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter. arXiv:1910.01108 [cs.CL] https://arxiv.org/abs/1910.01108

    2020 arXiv

  53. [61]

    C. E. Shannon. 1949. Communication theory of secrecy systems.The Bell System Technical Journal28, 4 (1949), 656–715. doi:10.1002/j.1538-7305.1949.tb00928.x

    1949

  54. [62]

    Shahram Shirani. 2008. Data compression: The complete reference (by d. salomon; 2007)[book review].IEEE Signal Processing Magazine25, 2 (2008), 147–149

    2008

  55. [63]

    Manish Shukla, Shubham Malaviya, and Sachin Lodha. 2024. Poster: Context-Based Effective Password Detection in Plaintext. InProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security. 5066–5068

    2024

  56. [64]

    Skylot. 2025. JADX - Dex to Java Decompiler. https://github.com/skylot/jadx Accessed: 2025-08-24

    2025

  57. [65]

    Smardec Inc. 2025. String Encryption. https://www.smardec.com/allatori/string-encryption Accessed: 2025-08-16

    2025

  58. [66]

    Robert J Tibshirani and Bradley Efron. 1993. An introduction to the bootstrap.Monographs on statistics and applied probability57, 1 (1993), 1–436

    1993

  59. [67]

    Sergey Troshin and Nadezhda Chirkova. 2022. Probing pretrained models of source codes. InProceedings of the Fifth BlackboxNLP Workshop on Analyzing and Interpreting Neural Networks for NLP. 371–383

    2022

  60. [68]

    Truffle Security. 2025. TruffleHog: Find, verify, and analyze leaked credentials. https://github.com/trufflesecurity/ trufflehog. https://github.com/trufflesecurity/trufflehog Accessed: 2025-08-06

    2025

  61. [69]

    Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Łukasz Kaiser, and Illia Polosukhin. 2017. Attention is all you need.Advances in neural information processing systems30 (2017)

    2017

  62. [70]

    Pei Wang, Dinghao Wu, Zhaofeng Chen, and Tao Wei. 2018. Protecting million-user ios apps with obfuscation: motivations, pitfalls, and experience. InProceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice. 235–244

    2018

  63. [71]

    Yue Wang, Weishi Wang, Shafiq Joty, and Steven CH Hoi. 2021. Codet5: Identifier-aware unified pre-trained encoder- decoder models for code understanding and generation. InProceedings of the 2021 conference on empirical methods in natural language processing. 8696–8708

    2021

  64. [72]

    Lili Wei, Heqing Huang, Shing-Chi Cheung, and Kevin Li. 2025. How far are app secrets from being stolen? a case study on android.Empirical Software Engineering30, 3 (2025), 90. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA116. Publication date: October 2026. ISSTA116...

    2025

  65. [73]

    Elliott Wen, Jia Wang, and Jens Dietrich. 2022. Secrethunter: A large-scale secret scanner for public git repositories. In 2022 IEEE International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom). IEEE, 123–130

    2022

  66. [74]

    Robert F Woolson. 2007. Wilcoxon signed-rank test.Wiley encyclopedia of clinical trials(2007), 1–3

    2007

  67. [75]

    Soufian El Yadmani, Olga Gadyatskaya, and Yury Zhauniarovich. 2025. The File That Contained the Keys Has Been Removed: An Empirical Analysis of Secret Leaks in Cloud Buckets and Responsible Disclosure Outcomes. In2025 IEEE Symposium on Security and Privacy (SP). 3180–3198. doi...

    2025

  68. [76]

    Yelp Inc. 2024. detect-secrets: An enterprise friendly way of detecting and preventing secrets in code. https://github. com/Yelp/detect-secrets. Version 1.5.0, accessed August 6, 2025

    2024

  69. [77]

    Jaeku Yun, Shinhyung Choi, Roman Babenko, Yuliia Tatarinova, and Samsung Electronics. 2025. CredSweeper: A Credential Detection Tool. https://github.com/Samsung/CredSweeper. Version 1.12.2, accessed September 2025

    2025

  70. [78]

    Tianyi Zhang, Varsha Kishore, Felix Wu, Kilian Q Weinberger, and Yoav Artzi. 2019. Bertscore: Evaluating text generation with bert.arXiv preprint arXiv:1904.09675(2019)

    2019 arXiv

  71. [79]

    Jiawei Zhou, Zidong Zhang, Lingyun Ying, Huajun Chai, Jiuxin Cao, and Haixin Duan. 2025. Hey, Your Secrets Leaked! Detecting and Characterizing Secret Leakage in the Wild. In2025 IEEE Symposium on Security and Privacy (SP). IEEE, 449–467

    2025

  72. [80]

    Chaoshun Zuo, Zhiqiang Lin, and Yinqian Zhang. 2019. Why does your data leak? uncovering the data leakage in cloud from mobile apps. In2019 IEEE Symposium on Security and Privacy (SP). IEEE, 1296–1310. Received 2026-01-30; accepted 2026-06-25 Proc. ACM Softw. Eng., Vol. 3, No....

    2019

  73. [2020]

    InProceedings of the 15th ACM Asia Conference on Computer and Communications Security(Taipei, Taiwan)(ASIA CCS ’20)

    Hidden in Plain Sight: Obfuscated Strings Threatening Your Privacy. InProceedings of the 15th ACM Asia Conference on Computer and Communications Security(Taipei, Taiwan)(ASIA CCS ’20). Association for Computing Machinery, New York, NY, USA, 694–707. doi:10.1145/3320269.3384745

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.