On this page
Review five surfaces
General information, not legal advice.
Public exposure. Search the collection’s known names, package markers, domains, repository references and published releases. Check public mirrors and forks where relevant. Record the date, query or method, and the result. A clean search result means “not found by this method,” not “never public.”
Full history. Review the complete history that will be offered, not only the current files. The official secret-scanning guidance says its scan covers the entire Git history on all branches for supported hardcoded credentials GitHub Docs, (opens in a new tab). That supports a useful technical principle: current-file review alone is not enough. It does not prove that every secret or every sensitive field was detected.
Contributors and third parties. List employees, contractors, clients, open-source components, data suppliers and customer material. A private repository can still contain code written under a client agreement or a component with obligations that do not match the proposed license.
Personal and confidential fields. Look for names, email addresses, phone numbers, tokens, credentials, customer records, support messages, HR material, legal privilege and internal identifiers. Mark what is excluded, masked or escalated. Do not publish a sample that includes a real value while demonstrating a scan.
Model-generation signals. Record known generated files, assistant metadata and the limits of the check. Do not claim that a scan can identify every model-written line or guarantee that training data has never appeared in an evaluation set.
The evidence worksheet
General information, not legal advice.
| Surface | Evidence reference | Result | Action |
|---|---|---|---|
| Public repositories and mirrors | Dated search log | Found, not found, or incomplete | Exclude, investigate, or document the limit |
| Full history and branches | Scan report and clone state | Complete, shallow, or unknown | Obtain full history or narrow scope |
| Contributors and clients | Assignments and contracts | Owned, permission needed, or unresolved | Request consent or exclude |
| Dependencies and components | Lockfile or SBOM review | License identified or unknown | Disclose, remove, or ask your own lawyer |
| Secrets and personal data | Scan report plus manual sample review | Finding count and scope | Rotate, redact, exclude, or re-scan |
| Prior licenses and terms | Contract register | No conflict, conflict, or unknown | Carve out or get legal advice |
| Model-generation signals | Tool output and owner statement | Signal found or check unavailable | Describe limitation, never overclaim |
Worked fictional example
General information, not legal advice.
Suppose a fictional team has a private repository with complete local history and a public package published years ago. The current files contain no obvious credentials, but the history has an old token and one folder includes client integrations.
| Finding | Safe conclusion | Next step |
|---|---|---|
| Public package marker | Some component was public | Exclude the package and inspect forks and releases |
| Old token in history | A credential was present in the reviewed history | Rotate it, remove the affected history where appropriate, and record the incident review |
| Client integration folder | Title is not established by repository access | Find the client permission or leave it out |
| Full-history clone | The scan covered the intended history | Keep the clone-state evidence with the report |
The safe output is a narrower candidate scope, not a “private” badge for the entire repository. A review can proceed on the internal service after the client folder and public package are excluded, subject to title review and your own lawyer’s advice.
Rules for a safe sample
- Run checks on the owner’s machine or the approved isolated process. Do not upload a private archive to complete this worksheet.
- Keep scan output separate from code, paths, emails and credentials. Share only the bounded report the route requires.
- Record the source revision, scan date, clone state and exclusions.
- Treat a tool result as evidence of what it checked. Keep unresolved areas visible.
- Re-run after remediation. A redaction or history rewrite changes the evidence set.
Rightmark Repo Check is the route-specific technical starting point for private code. The Trust page explains the ownership pack and approval gate. For workplace archives, use the operational data page to define systems and exclusions.
This checklist does not establish that data is private, non-infringing, uncontaminated, accepted by Rightmark or worth a particular amount. It makes the next review question visible.