Github Repository Security Review

Case Study: GitHub Repository Security Review

Source-code repositories are central to modern software delivery, but credentials committed to code can turn routine developer access into a route to cloud platforms, business applications and third-party services.

This case study outlines a two-phase GitHub repository security review conducted by ProCheckUp for a major international organisation. The engagement covered large-scale secret discovery, controlled credential validation, risk prioritisation and recommendations for sustainable secrets governance.

Overview

Following a repository data-exposure incident, the customer commissioned ProCheckUp to assess its GitHub portfolio and determine the risks created by sensitive data held in source control. The engagement covered approximately 800 repositories and was delivered as two linked phases.

Phase 1 – discovery and classification

ProCheckUp used static analysis, contextual review and open-source intelligence techniques to assess repository content, configuration files, commit history, and archived or orphaned material. The review identified more than 2,300 instances of exposed credentials, keys, tokens, passwords and licence data across five principal finding categories.

Phase 2 – consolidation and controlled validation

ProCheckUp consolidated and normalised the Phase 1 dataset, then performed controlled validation of selected credentials against externally accessible cloud and SaaS endpoints. This confirmed three Critical, two High, three Medium and one Low severity findings, including active credentials capable of authenticating to live services.

Assessment at a glance

• - Approximately 800 repositories reviewed
• - More than 2,300 exposed items identified during Phase 1
• - Three Critical, two High, three Medium and one Low findings confirmed during Phase 2
• - Active credentials identified across cloud, mapping, communications and AI services
• - A consolidated master dataset produced for remediation ownership and tracking
• - Validation remained non-destructive and stopped once authentication was confirmed

Challenge

The scale and age of the portfolio created a substantial triage challenge. Secrets appeared across active code, configuration files, infrastructure-as-code, environment files, comments, branches and commit history. Developer turnover also meant that some repositories and credentials no longer had clear owners.

Discovery alone could not establish whether an item was a genuine production secret, demonstration data, a duplicate, an expired credential or an active route into a service. The engagement therefore needed to reduce a large raw dataset into actionable findings and distinguish active, inactive and unverified credentials without causing disruption.

Validation was restricted to authorised public endpoints and confirmation of authentication only. Internal systems, on-premises infrastructure, internal cloud tenants, destructive activity, privilege escalation, data access and resource manipulation were outside scope. Multi-factor authentication, conditional-access controls and mandatory two-factor protections also required careful credential-by-credential testing rather than bulk authentication attempts.

Requirements

The assessment was required to help the customer understand, quantify and mitigate the risk arising from sensitive data in its GitHub repository portfolio following the reported exposure incident.

Phase 1 requirements included:

• - Analysis of main branches, commit history and archived or orphaned content
• - Identification and classification of secrets and credentials
• - Filtering of sample, placeholder and demonstration data
• - Mapping findings to systems and owners where context permitted
• - Production of a structured dataset suitable for coordinated remediation

Phase 2 requirements included:

• - Deduplication and standardisation of the Phase 1 dataset
• - Controlled validation against authorised external services, including AWS, Azure, SendGrid, OpenAI, Mapbox and Google Cloud
• - Prioritisation of credential rotation, containment and incident-review activity
• - Non-destructive testing that stopped after successful authentication was confirmed
• - Evidence-based severity ratings using CVSS 3.1
• - Immediate, medium-term and long-term recommendations
• - A validated master dataset for remediation coordination and tracking

Solution

ProCheckUp applied a phased repository-assurance methodology. Automated pattern matching and static analysis were combined with manual review to locate and classify credentials in source files, configuration, infrastructure-as-code, environment files and historical commits across the repository portfolio.

The Phase 1 output was consolidated during Phase 2 to remove duplicates caused by the same secret appearing in multiple commits, branches or repositories. Classification labels, severity ratings and data fields were normalised to create a single master dataset for validation and remediation tracking.

High-risk credentials were then tested individually against their associated public service endpoints. Validation was limited to determining whether authentication succeeded. No customer data was accessed, and no privileges, configurations or resources were changed.

Findings were correlated to services and repository owners where context allowed and rated using CVSS 3.1. Recommendations combined immediate revocation, incident review and repository cleanup with longer-term controls such as centralised secrets management, least privilege, managed identities, short-lived credentials, automated repository and CI/CD scanning, developer training and periodic governance reviews.

The delivery model followed four stages:

• 1. Discover: review current content, branches, history, archives and orphaned repositories for known, generic and organisation-specific secret patterns.
• 2. Consolidate: remove duplicate occurrences, standardise fields and preserve repository, commit, path, service and ownership context.
• 3. Validate: test authorised high-risk credentials individually against the relevant public endpoints, stopping after authentication was confirmed.
• 4. Prioritise: combine validity, privilege, exposure context and potential impact to direct containment and sustainable remediation.

Vulnerabilities Identified

Repository-wide secret exposure

Phase 1 reported more than 2,300 exposed items across the portfolio. Principal categories included approximately:

• - 1,369 API keys and tokens
• - 593 hardcoded passwords and credential pairs
• - 148 cloud credentials
• - 95 private or application cryptographic keys
• - 10 software licence keys

Four credential categories were rated High and licence-key exposure was rated Medium. The category figures are approximate principal groupings and should be read alongside the complete master dataset.

Critical active SaaS credentials

Phase 2 found four of 11 SendGrid keys active, including one with extensive administrative permissions, and confirmed that the single OpenAI key selected for testing remained active. The credentials created risks including email-account abuse, phishing, service disruption, unauthorised platform use and financial impact.

Active mapping and Google service keys

Thirty-two of 46 Mapbox tokens and 20 of 23 Google Cloud API keys were active. Depending on restrictions and permissions, the keys could enable unauthorised service use, consumption of billable resources or access to configured APIs. Both findings were rated High.

Azure credential exposure

Two of 15 Azure secret keys were active, nine were inactive and four were unverified, producing a Critical finding. Seven Cosmos DB keys, 15 of 24 Storage keys, and three Function or API access keys could not be verified because their endpoints did not resolve. These items were retained as Medium risks and treated as potentially valid pending confirmation.

Private and application cryptographic keys

Phase 1 identified approximately 95 SSH, RSA, JWT, framework, encryption and other application secret keys. Depending on use and ownership, these could support direct system authentication, token forgery, decryption or application compromise. Full validation of JWT signing keys and private SSH or RSA keys was deferred pending target identification and explicit authorisation.

Residual credential-management risk

All 42 AWS access keys tested during Phase 2 were inactive, but their continued presence in source history demonstrated weaknesses in credential handling. Unverified Azure items, historical commits, hardcoded passwords, licence keys and additional active secrets in the validation dataset remained important remediation and governance concerns.

Selected Controlled-Validation Results

• - SendGrid: four of 11 keys active, including one with extensive administrative permissions
• - OpenAI: one of one key active
• - Mapbox: 32 of 46 tokens active
• - Google Cloud API: 20 of 23 keys active
• - Azure secret keys: two active, nine inactive and four unverified from 15 tested
• - AWS access keys: all 42 tested keys inactive
• - Azure Cosmos DB: seven keys unverified because the associated endpoints did not resolve
• - Azure Storage: 15 of 24 keys unverified because the associated endpoints did not resolve
• - Azure Function or API access: three keys unverified because the associated endpoints did not resolve

An unverified result was not treated as evidence that a credential was safe. Where a target endpoint could not be resolved or a control prevented conclusive testing, the credential was retained as potentially valid until the customer could confirm or revoke it.

Testing Boundaries

Validation included:

• - Correlation of candidate credentials with likely service providers and endpoints
• - Individual, authorised authentication checks against externally accessible services
• - Confirmation of active, inactive or unverified status where technically possible
• - Collection of sufficient evidence to support severity and remediation priority
• - Immediate escalation of confirmed active, high-impact credentials

Validation did not include:

• - Access to customer or third-party data
• - Resource creation, modification or deletion
• - Privilege escalation or destructive testing
• - Internal systems, on-premises infrastructure or inaccessible internal cloud tenants
• - Password-spray testing or bulk authentication attempts
• - Full use of JWT signing keys, SSH private keys or RSA private keys without identified targets and explicit approval

Outcome

The engagement converted a large and uncertain repository exposure into a prioritised, evidence-based view of risk. Phase 1 established the breadth and types of sensitive material present, while Phase 2 demonstrated that several credentials were not merely historical artefacts but remained capable of authenticating to live external services.

The customer received a consolidated master dataset and clear priorities for containment:

• - Revoke and rotate confirmed active credentials
• - Investigate relevant service activity, audit records and billing data
• - Remove secrets from current code and repository history
• - Confirm or revoke credentials whose status could not be established
• - Assign owners and remediation status across the repository portfolio
• - Verify that remediation had removed provider-side access as well as repository exposure

The validation results enabled the most consequential exposures to be addressed ahead of inactive or lower-impact findings. The reports also defined a longer-term improvement path based on zero-secrets-in-code practices, centralised secret storage, managed identities and temporary credentials, least privilege, automated scanning, developer awareness and ongoing repository governance.

Internal credential validation, password-spray testing, and full validation of JWT and private-key material were not completed during Phase 2 and remained candidates for authorised follow-up assessment.

How ProCheckUp Helps

ProCheckUp’s GitHub Credential Discovery & Validation Service helps organisations identify sensitive authentication material exposed across source-code repositories and understand the resulting business risk.

The service can include:

• - Assessment of private and public repositories within the agreed scope
• - History-aware credential discovery across agreed branches, tags and revisions
• - Detection of known, generic and organisation-specific credential candidates
• - Correlation of secrets with client IDs, tenant IDs, account names and service endpoints
• - Expert review to distinguish genuine risks from placeholders and public identifiers
• - Controlled validation of selected credentials where expressly authorised
• - Cross-repository duplicate and exposure analysis
• - Immediate escalation of confirmed active, high-impact credentials
• - Cloud identity and persistence review following confirmed exposure
• - Prioritised remediation guidance and optional verification testing

The service complements native repository controls by adding independent investigation, contextual correlation, consultant-led validation and cloud-security analysis. Where exposure may have progressed into unauthorised access, ProCheckUp can extend the work through AWS cloud-security testing and intrusion analysis.