Code Repositories: A Wealth of Information and Potential Threats. How River Security Protects Your Assets
A public code repository may look like a collection of source files. To a penetration tester or attacker, it can be a map of an organisation.
Repositories can reveal credentials, internal systems, cloud environments, third-party integrations, development practices, and infrastructure that may not otherwise be visible from the internet. Even a repository that appears outdated or harmless can contain enough information to uncover new assets or build a credible attack path.
This is why River Security includes repository tracking as part of its work for both customers and penetration testers.
More Than Source Code
The security value of a repository is not limited to the application code it contains. A repository may expose:
- API keys and access tokens
- Database credentials and connection strings
- Private keys and certificates
- Internal hostnames and IP addresses
- Cloud account identifiers
- CI/CD configuration
- Deployment scripts
- Infrastructure-as-code files
- Authentication endpoints
- Webhook secrets
- Third-party services and integrations
- Developer usernames and email addresses
- References to staging, testing, and legacy environments
Individually, some of these findings may appear insignificant. When combined, they can reveal how systems communicate, where trust relationships exist, and which services may be worth investigating further. This is why River Security collects it to our platform.
An internal hostname may lead to an undocumented internet-facing service. A configuration file may identify the cloud provider and account structure behind it. An old token may still grant access to a forgotten environment. The real risk often lies in the relationship between multiple findings.
Deleted Does Not Mean Gone
Removing a secret from the current version of a file does not necessarily remove it from the repository. Git preserves historical versions of files through commits, branches, and tags. Sensitive information may therefore remain accessible long after it has been deleted from the latest version. Copies can also continue to exist in forks, cached data, local clones, build logs, or archived projects.
For this reason, deleting an exposed credential is not enough. The credential should also be revoked or rotated, and the organisation should assess whether it has already been used. Repository history can be particularly valuable during a penetration test because it may reveal:
- Previously used credentials
- Deprecated infrastructure
- Removed security controls
- Old API endpoints
- Internal project names
- Changes in authentication mechanisms
- Systems that were migrated but remain accessible
An old repository does not necessarily represent an old risk.
Public Does Not Always Mean Intentionally Public
Repositories become exposed for many reasons. A developer may create a project under a personal account. A repository may be assigned the wrong visibility during a migration. A contractor may fork internal code into an unmanaged workspace. A test project may be published temporarily and then forgotten.
In one case, River Security identified a public repository maintained by consultants working for a customer that exposed sensitive information, including credentials.
Other repositories may not contain proprietary code at all, but still reference an organisation’s domains, services, employees, infrastructure, or suppliers. This creates a visibility problem. Organisations cannot protect repositories they do not know exist.
Repository tracking helps identify code and configuration connected to the organisation, including repositories outside centrally managed accounts.
Secret Scanning Is Only Part of the Solution
Automated secret scanning is valuable, but it does not provide the full picture. A scanner can detect patterns that resemble passwords, keys, or tokens. It may not determine whether a finding is valid, active, correctly scoped, or capable of providing access to a real system.
It may also overlook information that is highly useful to an attacker but does not match the format of a traditional secret.
Examples include:
- Internal naming conventions
- Cloud architecture
- Service dependencies
- Custom authentication schemes
- Hardcoded identifiers
- Debugging endpoints
- Trust relationships
- Deployment workflows
- Comments and commit messages that reveal operational context
This is where penetration-testing expertise becomes important.
Automated tools identify possible findings. Penetration testers determine what those findings mean, how they relate to the wider attack surface, and whether they contribute to a practical attack path.
From Repository Finding to Attack Path
Consider a repository containing an internal hostname and a token that appears to belong to a test environment.
On their own, neither finding may appear critical.
The hostname may reveal an undocumented service that is also reachable from the internet. The token may have limited permissions but allow access to service metadata. That metadata may expose identifiers, account names, or references to another application.
The repository may also contain deployment configuration showing how the systems communicate.
Together, these details may allow a tester to discover a previously unknown asset, understand its role, authenticate to part of the environment, and identify a path towards more sensitive systems.
No single scanner result tells the full story. The value comes from correlation, context, and validation.
How River Security Approaches Repository Tracking
River Security uses repository tracking to improve visibility into information that may be associated with a customer’s organisation and attack surface. The process includes several stages as clarified below.
Repository discovery
We identify repositories that may be connected to the customer through organisation names, domains, employee accounts, source-code references, package metadata, infrastructure details, and other attributable information.
Ownership and relevance assessment
Not every search result belongs to the customer. Repositories may be owned by employees, former employees, contractors, partners, suppliers, or unrelated third parties. We assess whether the repository is relevant and whether the exposed information can reasonably be connected to the organisation.
Exposure analysis
Relevant repositories are reviewed for sensitive information, including credentials, certificates, configuration, infrastructure references, integrations, and historical content.
The assessment is not limited to the current state of the repository. Available commit history, branches, and related projects may also contain important information.
Contextual validation
Potential findings are assessed to determine whether they represent a credible risk. This may include establishing whether a credential is active, whether a referenced service is reachable, whether access is appropriately restricted, and whether several findings can be combined into a larger attack path.
Validation is performed carefully to minimise unnecessary access and avoid increasing the customer’s exposure.
Reporting and remediation
Confirmed findings are reported with the context required to support remediation and prioritisation. Depending on the finding, recommended actions may include:
- Revoking or rotating exposed credentials
- Restricting repository access
- Removing sensitive files
- Cleaning repository history
- Reviewing forks and copies
- Investigating credential use
- Correcting excessive permissions
- Migrating secrets to a managed secret store
- Improving development and deployment controls
Continuous tracking
Repository exposure is not a one-time problem. New repositories are created, developers change roles, projects move between accounts, and sensitive values may be committed at any time.
Continuous tracking helps identify new exposure earlier and reduces the gap between publication and remediation.
Reducing Repository Risk
Organisations can significantly reduce repository-related risk by combining technical controls with clear ownership and development practices.
Recommended measures include:
- Use managed secret stores instead of hardcoding credentials
- Enable secret scanning across repositories
- Enable protections that prevent secrets from being committed
- Scan the complete repository history, not only current files
- Use short-lived and narrowly scoped credentials
- Rotate exposed credentials rather than only deleting them
- Review public repository ownership and visibility
- Remove access for former employees and contractors
- Audit deploy keys, webhooks, applications, and CI/CD integrations
- Add repository scanning to development pipelines
- Maintain an inventory of organisation-related repositories
- Train developers to recognise sensitive information before publishing code
Controls should also account for repositories hosted outside the organisation’s primary development platform.
A well-managed internal GitHub or GitLab organisation does not prevent a developer, contractor, or supplier from publishing related material somewhere else.
Repositories Should Be Treated as Part of the External Attack Surface
Code repositories are not simply development resources. They can expose identities, infrastructure, credentials, relationships, and historical information that help attackers understand an organisation.
The most serious risk may not be a password sitting plainly inside a source file. It may be a collection of small clues that reveals an asset the organisation did not know was exposed or an attack path that had never been considered.
By combining repository discovery, automated analysis, and penetration-testing expertise, River Security helps customers understand what their repositories reveal and whether that information can be turned into a practical security risk.
Do you know which public repositories reference your organisation, infrastructure, or employees? River Security can help you identify unmanaged repositories, validate exposed information, and understand whether it creates a practical attack path.
