DET0805: Detection of Code Repositories
DET0805 is about detecting activity related to public code repositories as a reconnaissance source. The business issue is not just that code exists online;...
Analyst context for executives and security teams
DET0805 is about detecting activity related to public code repositories as a reconnaissance source. The business issue is not just that code exists online; it is that public repositories can expose names, infrastructure clues, secrets, configuration details, or development patterns that help an adversary prepare targeting before an incident is visible inside the network.
Executive priority
Leaders should treat this as an exposure-management and incident-readiness question: do we know which public repositories represent the organization, what sensitive information they contain, and who is accountable for remediation when risky content is found? Because the ATT&CK object has no official detection text or platform details, priority should be on governance, audit evidence, and validation of repository monitoring rather than assuming SOC coverage exists.
Technical view
This detection strategy is linked to T1593.003 Code Repositories under reconnaissance on PRE. SOC, threat intelligence, and exposure-management teams should validate whether they can observe or assess public code-hosting activity involving organizational repositories on services such as GitHub, GitLab, SourceForge, and BitBucket, as referenced by the related ATT&CK technique. Detection engineering should focus on repository exposure signals, suspicious access or cloning where provider telemetry exists, and findings that indicate sensitive information is present in public code.
Likely telemetry
- Public code repository inventory and ownership records
- Code-hosting provider audit logs where available
- Repository access, clone, download, and API activity where available
- Secret-scanning or sensitive-data findings in repositories
- Web application and command-line git usage logs where collected
Detection direction
- Confirm whether monitoring covers public repositories, not only internal source-control systems.
- Separate normal developer and maintainer activity from unusual access patterns, large-scale cloning, or anonymous/public access where telemetry supports that distinction.
- Tune alerts around confirmed organizational repositories and sensitive projects to reduce noise from unrelated public code.
- Use relationship context with T1593.003: this is pre-compromise reconnaissance, so absence of endpoint or network alerts does not mean the behavior is not occurring.
- Document blind spots, especially repositories hosted by third parties where search activity may not be visible to the victim organization.
Mitigation priorities
- Maintain an authoritative inventory of public repositories and responsible owners.
- Review public repositories for secrets, credentials, internal hostnames, configuration details, and other targeting-relevant information.
- Apply repository access controls and publication review processes where private or sensitive code should not be public.
- Use secret-scanning and remediation workflows, including credential rotation when exposed secrets are found.
- Include public repository exposure in incident response and compliance evidence so findings can be triaged, remediated, and tracked.
Analyst notes and limits
The supplied ATT&CK detection strategy has no official description, detection guidance, platforms, or tactics. The practical guidance here is derived from its relationship to T1593.003 Code Repositories and the related technique description, which identifies public code repositories and common access methods such as web applications and git utilities.
Coverage depends heavily on local repository inventory, third-party provider logging, and exposure-monitoring capability. Public search activity against repositories may be invisible to the organization, so teams should not represent this as guaranteed detection without validating available telemetry.
Detection of Code Repositories
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1593.003 | Code Repositories Sub-technique | This object detects Code Repositories. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | ae9511c1f82e… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0805Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.