This agreement is between AELaboratories, which runs Borehole ("Borehole", "we"), and the customer defined in section 1. It forms part of the Terms of Service (section 16). The customer accepts it by ticking the box when it makes a collector token, and the token records the version accepted and when. That is how this agreement is made in writing, in electronic form.

1. Parties and roles

• The customer is the account that runs the collector on a repository it controls or is authorised to survey, whoever bought the key it spends. The customer is the controller of the personal data in that repository.
• Borehole is AELaboratories, 500 Westover Dr #34489, Sanford, NC 27330, United States, support@borehole.dev. Borehole is the customer's processor for the personal data in the bundle the collector sends and in the private report made from it.
• Borehole is the controller, not a processor, of the data about the customer's own account, orders and use of the site. The privacy notice covers that data.
• When the customer shares a report, for example with a buyer through a share link, whoever receives it decides for itself what it does with it. This agreement does not cover that.

2. Subject matter, duration, nature and purpose

3. Personal data and data subjects

Data subjects: people who authored or committed to the repository, typically the customer's employees and contractors, and anyone named in a line the collector quotes.

Personal data in the bundle:

• Each commit's author email address and author name, as hashes made on the customer's machine, with the commit's dates. From collector 0.7.12, each hash is keyed with a random value the collector makes for that one survey and never sends or keeps, so Borehole cannot re-identify an author from the hash. Collectors before 0.7.12 salted it with the repository's head commit, which the bundle carries. With those, Borehole could test a guessed address, and it undertakes not to.
• Each commit's subject as written, with values in it that look like secrets blanked. A subject can contain a name.
• Up to 120 characters of a matched line, where a check quotes its evidence. A quoted line, such as a TODO, can contain a name.
• File paths, the remote's host and path, and the names and dates of tags.
• For a credential-shaped match: its location, its kind and a fingerprint salted for that one survey. Never its value.

Not in the bundle: author names and email addresses, whole files, credential values, and commit trailers, which are counted and never sent. The customer can print the whole bundle before anything is sent, with borehole collect . --dry-run.

In the report: counts and bands about authorship, of which a finding about the top contributor describes one person, and the quoted lines above.

The service is not designed to receive special categories of personal data, and the customer does not send them on purpose.

4. Borehole's obligations

4.1 Instructions. Borehole processes the personal data only to produce and keep the customer's report, as the customer's use of the service directs, unless the law requires otherwise. If it does, Borehole tells the customer first, unless that law forbids it. These are part of the customer's instructions:

• Who may read a private report: the account that ran the survey; anyone GitHub says controls the repository, when the bundle names a repository on github.com; anyone holding a share link the customer makes, until it revokes it; and Borehole's administrators, to run the service and answer support. Nobody else.
• No use for Borehole's own purposes. Borehole does not use a bundle or a private report for anything of its own, including calibrating its checks, analytics or marketing. A private report is never counted in analytics, and the facts in a bundle are never kept to calibrate or re-read.
• Borehole tells the customer if, in its view, an instruction infringes the GDPR or other data protection law.

4.2 Confidentiality. Only the one responder who runs Borehole has access to production data, and is bound to keep it confidential.

4.3 Security. Borehole applies the measures in Annex 1, and keeps them appropriate to the risk (GDPR Article 32).

4.4 Sub-processors. The customer gives a general authorisation for the sub-processors in Annex 2.

• Before adding or replacing a sub-processor that would receive bundle or private-report data, Borehole gives the customer notice by email, to the address on its account, at least 14 days ahead, and updates /docs/subprocessors.
• The customer may object, on reasonable data protection grounds, within those 14 days. If the parties cannot resolve it, the customer may stop using the service before the change. Borehole then deletes the customer's private reports and refunds in full any key the customer bought that still has days left.
• Borehole binds each sub-processor by written contract to the same data protection duties as this agreement, and remains fully liable to the customer for each one's performance of them.

4.5 Requests from data subjects. Borehole passes any request it receives about a private report to the customer without undue delay, and does not answer it unless the customer asks. It helps the customer answer such requests. The customer can delete a private report itself, on its account page.

4.6 Other assistance. Borehole helps the customer meet its duties under GDPR Articles 32 to 36: security, notifying a breach, a data protection impact assessment and prior consultation. It does so by giving the information it holds about the processing, including this agreement and the description at /docs/trust.

4.7 Personal data breaches. Borehole notifies the customer without undue delay, and within 48 hours of becoming aware of a breach affecting the customer's data. The notice says, as far as Borehole knows them: what happened; the categories and approximate number of data subjects and records concerned; the likely consequences; what Borehole has done or proposes to do; and whom to contact. Where Borehole does not yet know everything, it sends what it knows and the rest as it learns it.

4.8 End of processing. The bundle is deleted as section 2 describes. A private report is deleted when the customer deletes it, or deletes its account with its reports. A deleted report leaves only its verification code, which then says it was deleted. Borehole keeps no other copy, except where the law requires it.

4.9 Information and audits. Borehole makes available the information needed to show it meets this agreement, including the description at /docs/trust. The customer, or an auditor it appoints who is bound to confidentiality, may audit Borehole's compliance:

• first by written questions, which Borehole answers within 30 days;
• by an inspection on site only where a supervisory authority requires it, or the written answers do not settle the question;
• with 30 days' notice, at most once a year unless a supervisory authority requires more, during business hours, and at the customer's cost.

5. The customer's obligations

• The customer has a lawful basis for having its repository's personal data processed, and the right to survey the repository.
• The customer tells its developers about the survey, as the law that applies to it requires.
• The customer's instructions comply with data protection law.

6. Transfers

Borehole is in the United States. Bundle and report data are stored in the EU, with Google Cloud in europe-west1 (Belgium), and can be reached from the United States. Where the customer is subject to the GDPR, the parties incorporate by reference the standard contractual clauses adopted by the European Commission in Decision (EU) 2021/914, Module 2 (controller to processor), with the customer as data exporter and Borehole as data importer:

• Clause 7, the docking clause, applies.
• Clause 9: option 2, general written authorisation, with 14 days' notice, as section 4.4 says.
• Clause 11: the optional wording does not apply.
• Clause 13: the competent supervisory authority is the one that clause names for the customer.
• Clauses 17 and 18: the law of Ireland and the courts of Ireland.
• Annex I: the parties are in section 1, the processing in sections 2 and 3. Annex II is Annex 1 below. Annex III is Annex 2 below.

Where the customer is subject to the UK GDPR, the International Data Transfer Addendum to those clauses, issued by the UK Information Commissioner (version B1.0), also applies, completed with the details above. Neither party may end it under its section 19. If the clauses conflict with this agreement or the terms, the clauses prevail.

Each sub-processor's own transfer mechanism is on /docs/subprocessors.

7. Liability

Between the parties, the limits in section 9 of the terms apply to claims under this agreement, as far as the law allows. They do not limit the rights of data subjects under GDPR Article 82, or either party's liability under the standard contractual clauses where those clauses do not allow it.

8. Customers in California

For personal information subject to the California Consumer Privacy Act, Borehole is the customer's service provider. Borehole:

• processes it only to produce and keep the customer's reports;
• does not sell or share it, and does not keep, use or disclose it outside the direct business relationship with the customer;
• does not combine it with personal information from elsewhere, except as the Act allows;
• gives it the protection the Act requires, and tells the customer if it can no longer do so. The customer may then take reasonable steps to stop any use it has not authorised.

9. Governing law and order of precedence

This agreement is governed by the law of Ireland, and the courts of Ireland decide any dispute about it. Where the customer is established in the United Kingdom, the law of England and Wales governs it instead, and the courts of England and Wales decide. For the processing of personal data, this agreement prevails over the terms.

10. Changes

A new version appears here with its number and date. A token made afterwards accepts it. A change that reduces the customer's protection applies to an existing customer only after notice by email and 30 days.

Annex 1: security measures

• Source stays with the customer. The collector reads the repository on the customer's machine, or in Confidential Compute in the customer's own cloud account, and sends only the bundle in section 3.
• In transit: every connection uses TLS, and the site sends Strict-Transport-Security.
• At rest: in Google Cloud, europe-west1 (Belgium), encrypted at rest by the provider.
• Access to reports: only the readers in section 4.1. Anyone else who asks for a private report is told it does not exist. Administrator rights follow a list of GitHub accounts set in the service's configuration.
• Collector tokens: shown once, stored as a hash, limited to the scopes ticked when made, and revocable on the account page.
• Logging: every request to the service is logged with its address, path and time, and kept for 30 days in europe-west1 (Belgium).
• Backups: the database is backed up by Google Cloud, and backups are kept 30 days.
• Error reports are scrubbed before they leave the process, by key name and by value shape, and never carry a bundle.
• Incidents: errors and alarms reach the responder, who handles a breach as section 4.7 says.

Annex 2: sub-processors

Rendered from the same list as /docs/subprocessors. These receive bundle or private-report data:

These receive no bundle data: Stripe (payments), Google Workspace (the mailboxes at borehole.dev: support@, billing@, takedown@ and security@), OSV (Google Open Source Security) (known-vulnerability lookups), NVD (US National Vulnerability Database) (known-vulnerability lookups for a public repository), Anthropic (review of paid reports on public repositories), Resend (transactional email), Sentry (error reports), PostHog (product analytics).

See also the Terms of Service (version 1.14), the Privacy Policy and the sub-processors.