Data for: A Dataset Characterizing the Hashing Status of Leaked Secrets in Public Student GitHub Repositories
Description
This dataset characterizes hardcoded secrets (credentials such as passwords, API keys, and tokens) detected in the public GitHub repositories of student coursework and undergraduate capstone ("tugas akhir"/"skripsi") projects, primarily from Indonesian university students. Candidate repositories were identified via the GitHub Search API and scanned with Gitleaks across their full commit history, yielding 1,706 raw candidate findings. Each finding was manually reviewed and classified into one of five categories describing how the value was actually stored or used: plaintext_secret (a live, functional credential), hash (a recognizable one-way cryptographic hash), mock_test_data (a value confined to automated test code), dummy_placeholder (an unfilled template value never replaced with a real credential), or false_positive (not a secret at all). This classification, particularly the distinction between plaintext and hashed credentials, is not captured by existing secret-detection benchmarks, which typically label findings only as true or false positives.
Files
Steps to reproduce
1. Repository sampling Query the GitHub Search API using keywords associated with student/capstone coursework ("tugas-akhir", "skripsi", "final-year-project", "capstone-project", "college-project"), combined with a repository size filter (50 KB–200 MB). Deduplicate results by repository ID across queries. Target sample size: 500 repositories. 2. Automated secret scanning For each candidate repository, clone with full commit history (not just the latest snapshot) and scan using Gitleaks (open-source secret-detection tool, https://github.com/gitleaks/gitleaks), which applies regex- and entropy-based rules to flag candidate secrets. 3. Redaction and aggregation For each detected finding, mask all but the first and last four characters of the matched value. Aggregate all per-repository scan results into a single table with the following fields per finding: repository name, file path, commit hash, commit date, detection rule, redacted value preview, and value length. 4. Manual verification For each candidate finding, inspect the surrounding file content (via the GitHub API or website) and assign one of five labels: plaintext_secret, hash, mock_test_data, dummy_placeholder, or false_positive, based on the definitions provided in the accompanying README. Record supporting notes for ambiguous cases, including cross-references to duplicate findings. Tools required: Python 3, a GitHub Personal Access Token, Gitleaks (any recent version), and a spreadsheet application (e.g., Microsoft Excel) for the manual verification stage.