Code Repository: Data Point Intelligence Guide

A repository is an organisational confession: who builds what, on which infrastructure, with which mistakes, timestamped to the minute.

Understanding the Code Repository as an intelligence artifact

A code repository data point is a hosted source tree identified by host, owner and name, whether on a public platform or a self-managed instance. Beyond source files it contains commit history with author names, addresses and timestamps; branches and tags; issues and pull requests; continuous integration workflow definitions; dependency manifests and lockfiles; and configuration such as container and infrastructure-as-code files. Each commit is a record of who changed what and when, which makes a repository one of the richest structured datasets an organisation exposes voluntarily.

Analytically distinct variants include forks, mirrors and archived copies that retain content deleted upstream; monorepos versus many small repositories, which changes how ownership is inferred; and self-managed instances whose mere existence reveals internal infrastructure. Deleted or force-pushed content frequently survives in platform event APIs, in forks and in caches. Lockfiles pin exact resolved dependency versions, and their presence is what makes credible supply-chain assessment possible.

Why it matters

Repositories anchor supply-chain risk to code you actually run, and they expose the human layer of an organisation: developer identities, working hours, team structure and outsourcing relationships. For defenders they are where secrets, internal hostnames and architectural detail escape. For investigators, a repository ties a persona to verifiable work product, and commit metadata provides timestamps far more reliable than self-reported profile data. For due diligence, manifests reveal inherited risk that no questionnaire ever captures.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

Commit author names and addresses, including corporate addresses that link a pseudonymous account to an employer.
Commit timestamps with timezone offsets, indicating working hours, probable location and holiday patterns of contributors.
Internal hostnames, bucket names and endpoints in configuration, mapping infrastructure that is not otherwise public.
Workflow files revealing deployment targets, cloud accounts and the secrets the pipeline is expected to hold.
Dependency manifests and lockfiles giving exact versions in use for vulnerability and supply-chain assessment.
Contributor graph and review patterns exposing team structure, seniority and single points of failure.
Forks and mirrors that retain content deliberately removed from the upstream repository.
Issue and pull request discussion disclosing customer names, incident detail and unreleased functionality.

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

GitHub code search and REST API — Searches code, commits and events across public repositories, including forks and dangling commit artifacts.
GitLab and Bitbucket search — Equivalent coverage for projects hosted outside GitHub, including publicly reachable self-managed instances.
TruffleHog and gitleaks — Scan the full commit graph for secrets that persist in old commits after the file was deleted.
OSV.dev — Maps manifest entries to known vulnerabilities across ecosystems through a free open API.
deps.dev — Resolves transitive dependency graphs, licences and package health signals for a project manifest.
Software Heritage — Archives public repositories and commits, preserving code removed from the original host.
OpenSSF Scorecard — Automated checks on repository security practice such as branch protection, review and signed releases.
Wayback Machine — Snapshots of repository pages and READMEs captured before deletion or a switch to private.

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

Establish provenance — Record host, owner, default branch, creation date, fork relationship and whether the project mirrors or vendors another codebase.
Mine history, not the tip — Scan the full commit graph, because secrets and internal references usually survive only in older commits and dangling objects.
Profile contributors — Aggregate author names, addresses and commit timing to map the team and identify likely corporate affiliations.
Extract infrastructure — Pull hostnames, endpoints, bucket names, cloud account references and deployment targets from configuration and workflow files.
Assess dependencies — Resolve manifests and lockfiles through OSV and deps.dev to enumerate vulnerable, abandoned or unexpectedly transitive components.
Check for shadow exposure — Compare findings against your asset inventory to identify unsanctioned public repositories belonging to your own organisation.
Preserve and pivot — Archive relevant state with hashes, then pivot developer addresses and handles into other repositories, packages and platforms.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Collected by these disciplines

Technical Intelligence — Technology Capability, Design, and Exploitation
Cyber Intelligence — Adversary Activity in Networks and Systems
Academic Intelligence — Research Output, Collaboration, and Expertise
Patent Intelligence — Patents, Filings, and Innovation Signals
Corporate Intelligence — Understanding Companies, Structure, and Control

Investigated in these domains

Pivots to these data points

Software Package — A published dependency (npm, PyPI, Maven) — the vector for supply-chain compromise.

Inside the platform: where Code Repository lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

datapoint.php?dp=dp_git_repo — Data point hub
domain.php?d=emergingtech — Emerging Technology & AI Security dashboard
domain.php?d=econspy — Economic Espionage dashboard
domain.php?d=supply — Supply Chain Security dashboard
search.php — Advanced search, filter and pivot
correlate.php — Correlation graph
cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

Enrichment Runner
Enrichment → Local
Correlate Infrastructure
Summarise (Copilot)
Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Establish provenance is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
Building the picture. A single indicator is rarely the story. Profile contributors turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
Producing something actionable. Analysis that ends in a document nobody can use is wasted. Preserve and pivot feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses Code Repository

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Defence organisations use repository analysis for software supply chain assurance across the industrial base and for operational security review of their own and contractors' public code. Manifests and lockfiles reveal inherited components in fielded systems that no questionnaire captures, which supports airworthiness, accreditation and vulnerability management decisions. Public repositories belonging to programme staff and contractors routinely disclose internal hostnames, deployment targets and architecture. Constraints: commit metadata is personal data, contractor code is licensed and often proprietary, and any exposure found in another party's repository must be reported through disclosure channels rather than tested. Products are supply chain risk annexes and operational security advisories to programme offices.

🕵 National intelligence

For national intelligence public repositories are a rich, requirements-relevant open source: they expose the technical capability, tooling choices and development practice of organisations of interest, and commit metadata provides timing and locale signals more reliable than self-reported profile data. Repositories associated with proliferation-relevant, surveillance or offensive tooling projects are worth standing collection. Handling should record that collection was passive and terms-compliant, since bulk scraping is prohibited by hosts and creates an avoidable attribution risk. Analytic products must distinguish what a repository proves, which is that code exists and who committed it, from what it suggests about intent or deployment, which requires corroboration.

👮 Law enforcement

Investigators use repositories to tie a persona to verifiable work product, since commit metadata carries timestamps, configured identities and often corporate email addresses. Preserve with hashes and a documented collection method, and note that author fields are self-declared and forgeable, so only signed commits carry identity assurance. Subscriber and access log data behind an account requires legal process to the host, typically a preservation request followed by a production order or warrant, and mutual legal assistance where the host is foreign. Repositories containing tooling used in an offence support charging decisions, but authorship must be evidenced by more than a configured name in a commit.

🔍 Private investigation and corporate security

Corporate security uses repository analysis for shadow IT discovery, leak detection, insider risk and technical due diligence in acquisitions. Public repositories owned by staff personally are a recurring exposure route for organisational secrets and internal architecture. In diligence, manifests and lockfiles reveal licence obligations and inherited vulnerabilities that materially affect valuation. Constraints matter: bulk scraping breaches host terms and gets tokens revoked, contributor email addresses are personal data, and where you find another organisation's secrets or vulnerabilities you must report through their disclosure channel and never test them. Client authority does not extend to probing third-party systems.

📰 Journalism and OSINT media

Repositories are among the most underused sources in technology and accountability reporting. Commit history documents who built a system and when, issues and pull requests disclose customer names, incident detail and unreleased functionality, and deleted content frequently survives in forks and archives. Verification requires care: author fields are self-declared, forks inflate apparent authorship, and a public repository may be a deliberate open source release rather than a leak. Corroborate before characterising. Protect sources by not publishing details that identify who pointed you at a commit. Give the organisation right of reply, and do not publish live secrets or exploitable detail found in code.

🌍 NGO, humanitarian and human rights

Civil society and digital rights organisations analyse repositories to document surveillance and censorship tooling, to support open source security for at-risk groups, and to check their own exposure. Contributor data is personal data and publishing it can expose individual developers to reprisal in some jurisdictions, so minimise and consider whether naming individuals is proportionate to the finding. Do-no-harm applies: identifying a developer working on repressive tooling may be accountability, or may endanger someone with no choice in their employment. Where your own repositories serve at-risk users, scanning for secrets and dependency risk is a protection obligation rather than an IT task.

🎓 University and research

Repository data supports research on software engineering practice, supply chain risk, open source sustainability and developer behaviour. Ethics approval is normally required because commit metadata identifies individuals, and several institutional boards now treat mining public repositories as human subjects research. Respect host terms and rate limits, and prefer curated research datasets and official APIs to scraping. Reproducibility depends on pinning commit hashes and dataset versions, since repositories are mutable and history can be rewritten. Report sampling honestly: popular repositories are heavily over-represented in most datasets. Publish extraction code, and pseudonymise developer identifiers in released data.

Playbook: working Code Repository end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Establish provenance

Record host, owner, repository name, creation date, default branch, visibility history where observable, fork relationship and whether the project vendors or mirrors another codebase. Determine whether the repository is an intentional open source release, an internal project made public in error, or a fork of someone else's work. This framing determines everything downstream, because the same finding means different things in a deliberate release and an accidental exposure. Output is a provenance header on the assessment that a reviewer can check independently.

Phase 2 — Clone and preserve

Clone with full history including all branches and tags, and record the head commit hash, clone time and method. Repositories are mutable: history is rewritten, repositories are deleted or made private, and content disappears between observation and reporting. Hash the archive. Where the material may support an investigation, capture the rendered web pages for issues and pull requests as well, since those are not in the git objects. Note explicitly that a clone captures the state at a moment, not the account's activity history.

Phase 3 — Mine history, not the tip

Scan the full commit graph rather than the current working tree. Secrets, internal hostnames, credentials and revealing configuration typically survive only in older commits and in dangling objects after a file was deleted at the tip. Look at merge commits, abandoned branches and tags. Where the host exposes an events API, deleted and force-pushed content is sometimes still retrievable. Stop when the graph is fully covered rather than when the current files look clean, which is the error most first-time reviewers make.

Phase 4 — Scan for secrets and report responsibly

Run secret detection across the whole history and any build artefacts. For your own organisation, revoke exposed credentials immediately through the issuing provider before any further analysis. For third-party repositories, do not use, validate or retain the credential: notify the owner through their security contact and the issuing provider so it can be revoked. Record the finding location by commit hash and path. Never authenticate with a credential found in someone else's code; that is unauthorised access rather than research.

Phase 5 — Profile contributors proportionately

Aggregate author names, configured email addresses, commit timing and time zone offsets to map team composition, working patterns and probable corporate affiliation. Treat this as personal data with a stated purpose and a retention limit. Author fields are self-declared and trivially set, so distinguish configured identity from verified identity: only cryptographically signed commits with a validated key carry assurance. Minimise before publication, and record why identifying any individual contributor is proportionate to the finding you are making.

Phase 6 — Extract infrastructure and configuration

Pull internal hostnames, endpoints, bucket and storage names, cloud account references, database connection targets, deployment environments and CI workflow definitions. Workflow files disclose which secrets a pipeline expects to hold and which cloud accounts it deploys to. Infrastructure-as-code reveals the intended architecture, sometimes more accurately than production. Record each item with the commit and path. Do not resolve, connect to or probe any discovered host belonging to another organisation; enumeration from public DNS records is the limit of passive work.

Phase 7 — Assess dependencies

Resolve manifests and lockfiles rather than top-level declarations, since transitive dependencies carry most of the risk. Query OSV and deps.dev to enumerate known vulnerabilities, licence obligations, abandonment signals and unexpected transitive inclusions. Distinguish theoretical version-range matches from reachable code paths, because unreachable findings drown teams and destroy triage discipline. Where lockfiles are absent, note that resolved versions can change silently between builds, which is itself the finding. Output is a component inventory with prioritised, reachability-aware findings.

Phase 8 — Evaluate development practice

Check branch protection, review requirements, signed commits and releases, dependency update automation, security policy presence and issue response behaviour. OpenSSF Scorecard automates much of this. Practice quality predicts future risk better than a point-in-time vulnerability count, which is what makes it valuable in diligence and in supplier assurance. Record the evidence for each judgement rather than only the score, because scorecard checks measure observable signals and can be gamed by projects that know they are being measured.

Phase 9 — Check for shadow exposure

Compare public repositories against your asset inventory and your organisation's naming conventions, and search code hosts for your internal domains, package names, project identifiers and copyright strings. Include repositories under personal accounts of current and former staff, which is where a large share of accidental exposure lives. Establish an internal route for staff to report and remediate without blame. The output is a list of unsanctioned public repositories with an owner and a remediation action, reviewed on a schedule rather than once.

Phase 10 — Search forks, mirrors and archives

Deletion does not remediate. Check forks, network mirrors, Software Heritage, web archives and package registries for copies of content removed upstream. This matters both defensively, because your exposure persists after cleanup, and investigatively, because removed content is often the most informative. Record where each copy resides and when it was captured. Where you are assessing your own exposure, this step is what converts an optimistic remediation report into an accurate one.

Phase 11 — Pivot and correlate

Take contributor identities, email domains, handles, package names and infrastructure references into other repositories, package registries, messaging platforms and corporate records. A developer email domain frequently links a pseudonymous project to an employer; a distinctive internal package name links a public repository to an internal estate. Record the evidence on each link rather than the conclusion, and keep persona records separate from person records until the identification is properly corroborated.

Phase 12 — Report with minimisation and disclosure discipline

Publish findings at the level of detail the conclusion requires. Do not include live secrets, exploitable detail or unnecessary contributor personal data. Where the finding concerns another organisation's exposure, follow coordinated disclosure: notify the security contact, allow a remediation window, and escalate to a CERT if unreachable. Preserve the evidence with hashes under access control. Record the observation date and head commit hash, since a reader checking later will find a repository that has moved or vanished.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
GitHub REST and GraphQL APIs	Registration	Programmatic access to repositories, commits, events, issues and pull requests within published rate limits.	Terms-compliant collection of repository metadata, commit history and event data including some deleted content.
GitHub code search	Registration	Full-text search across public repository contents with language, path and organisation filters.	Locates internal hostnames, package names and configuration patterns belonging to your own organisation.
GitLab	Registration	Hosted and self-managed repository platform with its own search, API and public project namespace.	Covers projects outside GitHub, including publicly reachable self-managed instances run by organisations.
Software Heritage	Open	Universal archive of public source code preserving repositories, commits and file content permanently.	Recovers content removed from the original host and provides stable identifiers for citation.
OSV.dev	Open	Open vulnerability database with a free API mapping package versions to advisories across ecosystems.	Converts a manifest or lockfile into a precise list of known vulnerable components.
deps.dev	Open	Open dataset and API for transitive dependency graphs, licences, advisories and package health signals.	Resolves the full dependency tree behind a manifest and exposes indirect risk and licence obligations.
OpenSSF Scorecard	Open	Automated checks on repository security practice including branch protection, review, signing and dependency updates.	Provides a repeatable practice assessment for supplier assurance and technical due diligence.
TruffleHog	Open	Secret scanning across git history, filesystems and container images with provider-aware detectors.	Finds credentials surviving in old commits after the file was deleted from the current tree.
gitleaks	Open	Rule-based secret detection over git history with configurable detectors and hooks.	Second-opinion scanning and developer-side prevention of secret introduction.
GitHub Advisory Database	Open	Curated security advisories with affected version ranges and remediation guidance per ecosystem.	Authoritative advisory matching for dependencies discovered in repository manifests.
Sigstore	Open	Keyless signing and transparency log infrastructure for artefacts and commits.	Establishes whether releases and commits carry verifiable provenance rather than self-declared identity.
SLSA framework	Open	Supply chain levels for software artefacts, defining build integrity requirements and provenance attestation.	Benchmark for assessing whether a project's build pipeline produces verifiable artefacts.
Internet Archive Wayback Machine (archived)	Open	Web archive covering repository landing pages, READMEs and documentation sites.	Evidences what a repository page said before deletion or a change to private visibility.
Software Package Data Exchange	Open	Open standard for expressing software bills of materials including licence and provenance fields.	Format for recording the component inventory derived from a repository in an interchangeable way.
Open Source Initiative licence list	Open	Authoritative list of approved open source licences with full texts and conditions.	Determines licence obligations attaching to code found in or vendored into a repository.

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against Code Repository. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

git with full-history clone — Retrieves the complete commit graph including deleted file content in old commits. Limitation: does not capture issues, pull requests or account activity, which live outside git.
TruffleHog and gitleaks — Complementary secret scanners over history and artefacts. Limitation: verification features must never be pointed at third-party services, and entropy detection is noisy.
OSV-Scanner — Reads lockfiles and SBOMs and queries OSV for affected versions. Limitation: reports version-range matches without reachability, inflating the finding count.
deps.dev — Resolves transitive graphs and licence data without running the build. Limitation: coverage varies by ecosystem and can lag very recent releases.
OpenSSF Scorecard — Automated repository practice assessment producing comparable scores. Limitation: measures observable signals that a project aware of the checks can satisfy superficially.
SBOM generators — Produce CycloneDX or SPDX inventories from builds and lockfiles. Limitation: manifest-only generation misses transitive and system-level components entirely.
Software Heritage lookup — Retrieves archived copies of deleted repositories and files with stable identifiers. Limitation: archival coverage and freshness vary, so absence proves nothing.
Host APIs with rate limit management — Terms-compliant bulk metadata collection. Limitation: rate limits make estate-wide sweeps slow, and exceeding them gets tokens revoked.
Commit signature verification — Distinguishes cryptographically signed commits from self-declared authorship. Limitation: signing adoption remains low, so most history carries no identity assurance at all.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
Enrichment → Local — Materialises enrichment into the local store so dashboards render from your own database instead of a live third-party call.
Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

Scan the graph, not the tree. Secrets and internal references almost always survive in earlier commits and dangling objects after the file was deleted, which is why tip-only scanning consistently reports a clean repository that is not clean.
Commit author fields are configuration, not identity. Anyone can set a name and address, so treat them as a lead and reserve identity assurance for cryptographically signed commits with a validated key.
Determine whether a public repository is a release or a leak before escalating. Escalating an intentional open source publication as an exposure damages credibility and wastes the engineering relationship you will need later.
Deletion is not remediation. Forks, network mirrors, archives and package caches retain content indefinitely, so a remediation report that omits a fork search is measuring effort rather than exposure.
Lockfiles are where supply chain assessment becomes real. Top-level manifests describe intent; lockfiles record what was actually resolved, and the gap between them is where unexpected transitive risk lives.
Vendored code and merge commits inflate apparent authorship dramatically. Determine which files a party actually wrote before attributing a project's design or its defects to them.
Development practice predicts future risk better than a current vulnerability count. Branch protection, review enforcement and dependency automation tell you what the next year looks like; a CVE list tells you about last year.
Respect rate limits and use official APIs. Aggressive scraping gets tokens revoked, breaches terms, and in an investigative context creates an avoidable and traceable footprint against your own organisation.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on Code Repository is producing anything, and they are worth baselining before you change process or tooling.

Proportion of organisational public repositories covered by automated secret and dependency scanning with a named owner.
Median time from a secret being committed to its detection and to provider-confirmed revocation, measured across the whole repository estate.
Share of secrets prevented at push time versus detected post-publication, measuring whether prevention controls are effective.
Number of unsanctioned public repositories identified per review cycle, tracked downward as onboarding controls mature.
Percentage of dependency findings triaged with a reachability judgement rather than closed in bulk.
Rate of repositories meeting a defined practice baseline for branch protection, review and signed releases.
Time from discovery of a third-party exposure to notification through their disclosure channel.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

Commit author fields are self-declared and trivially forged; only cryptographically signed commits carry any identity assurance.
Vendored code and forks inflate apparent authorship, so determine which files a party actually wrote before attributing work.
A public repository may be an intentional open-source release rather than a leak; check licence and intent before escalating.
Archived and mirrored copies mean deletion does not remediate, so scanning only the live repository understates real exposure.
Bulk API scraping violates host terms and gets tokens revoked; respect rate limits and use official search endpoints.
Developer addresses are personal data, and publishing contributor details broadly is rarely proportionate to the analytical value.

Legal and ethical considerations

Public repositories are readable but licensed, and licence terms govern reuse of the code itself, not merely attribution. Respect host terms of service and rate limits, since automated bulk collection is frequently prohibited. Commit metadata contains personal data, so minimise before publishing contributor details. Where you find another organisation's secrets or vulnerabilities, follow coordinated disclosure to their security contact and never test the exposure. Retain evidence with hashes if the matter may become a formal incident.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for Code Repository, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 5 intelligence disciplines, 3 mission domains, 1 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Is scraping public repositories lawful?

Reading public code is generally lawful; bulk automated collection usually breaches host terms of service and can get accounts and tokens revoked permanently. Commit metadata also contains personal data, which in the European Union and United Kingdom means you need a lawful basis, a purpose and a retention period rather than an open-ended archive. The defensible pattern is to use official APIs and search endpoints within published rate limits, prefer curated research datasets and Software Heritage for bulk work, document your access route, and minimise contributor personal data at the point of storage rather than at publication.

We deleted the repository. Is the exposure closed?

No. Forks, network mirrors, clones on developer machines, package caches, web archives and Software Heritage all retain copies, and search engines may have indexed the content. Deletion prevents further discovery through the original path and is worth doing, but it does not remediate. For exposed credentials, revocation at the issuing provider is the control that ends the exposure. For exposed architecture and internal hostnames, assume the information is permanent and treat it as an input to your threat model rather than something you can withdraw.

How do I tell whether a contributor really works for a company?

A corporate email address in a commit is configuration and can be set by anyone, so treat it as a lead. Stronger signals are commits verified by a signature tied to a key associated with the organisation, membership displayed on the organisation's public profile, contributions to repositories under the organisation's namespace with review by known staff, and consistent activity within the organisation's working hours and time zone. Corroborate with professional profiles and public statements. In an investigative context, none of this is proof, and provider records under legal process are the reliable route.

Manifests or lockfiles for dependency assessment?

Lockfiles, always, plus the built artefact where possible. A manifest declares intent and version ranges; a lockfile records the exact versions actually resolved with integrity hashes. Assessing a manifest alone misses the transitive layer where most vulnerable and abandoned components live, and where ranges are unpinned the resolved versions can change between two builds of the same commit. Where no lockfile exists, that absence is itself a finding worth reporting, because the build is not reproducible and its component inventory is undefined.

We found another company's credentials in their public repository. What do we do?

Do not use them, do not validate them, and do not retain them beyond what is needed to report. Notify the organisation through its published security contact or disclosure programme, and notify the issuing provider, who can often revoke without anyone authenticating. Record what you sent and when. If the owner cannot be identified or does not respond, escalate to a national CERT or the code host's abuse channel. Once revocation is confirmed, delete the material and record the deletion. Testing the credential converts a responsible disclosure into a criminal offence.

How do we find repositories our staff created without telling us?

Search code hosts for your internal domain names, package prefixes, project code names, copyright strings and distinctive configuration patterns, and monitor those searches continuously rather than running them once. Review the public repositories of accounts associated with your corporate email domain. Combine with an amnesty process: staff will disclose repositories if the response is help rather than discipline, and they will not if it is punitive. Track discovered repositories to a named owner with a remediation decision, and re-run the sweep on a defined schedule.

What is worth preserving if a repository may become evidence?

A full-history clone with the head commit hash recorded, the rendered web pages for issues, pull requests and releases, the repository metadata from the API, and hashes of everything, with the collection time, method and collector logged. Capture forks and archived copies separately, since the original may be deleted or rewritten. Where the host holds account and access data you will need, send a preservation request immediately and follow with the appropriate legal process, because a clone shows content but not who accessed or pushed it from where.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

SLSA supply chain levels, defining build integrity and provenance requirements for artefacts produced from a repository.
OpenSSF Scorecard checks, providing a repeatable measure of repository security practice used in supplier assurance.
SPDX and CycloneDX specifications, defining interchangeable software bill of materials formats including licence fields.
Open source licence obligations, including copyleft conditions that attach to derived and vendored code.
Coordinated vulnerability disclosure norms including ISO/IEC 29147, governing notification of exposures found in third-party repositories.
Computer misuse legislation, which prohibits testing credentials or probing infrastructure discovered in another organisation's code.
UK GDPR and EU GDPR, which govern lawful basis and minimisation when processing contributor names, addresses and activity data.
NIST Secure Software Development Framework, which sets practice expectations for source control, review and secret handling.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

Software Heritage archive — Inria and UNESCO. Universal archive of public source code with permanent identifiers.
OSV.dev — Open Source Vulnerabilities project. Open vulnerability database and API covering package ecosystems.
deps.dev — Google Open Source Insights. Open dataset of dependency graphs, licences and advisories.
OpenSSF Scorecard — Open Source Security Foundation. Automated repository security practice assessment tool and criteria.
GitHub Advisory Database — GitHub. Curated ecosystem advisories with affected version ranges.
SLSA framework — Open Source Security Foundation. Supply chain integrity levels and provenance requirements for builds.
Sigstore — Open Source Security Foundation. Keyless signing and transparency logs for commits and artefacts.
SPDX specification — Linux Foundation. Open standard for software bill of materials and licence expression.
Open Source Initiative licence list — Open Source Initiative. Authoritative catalogue of approved open source licences and their terms.
NIST Secure Software Development Framework — National Institute of Standards and Technology. Practice framework covering source control, review and protection of secrets.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: continuously maps repositories to owners, contributors, exposed secrets and dependency risk across your code estate. Explore the platform, or browse the rest of the library by following any tag above.