Security and permissions
What Lockhound can see in your GitHub, and what it does with it
To check your dependencies, Lockhound has to read your repositories. This page lists what GitHub allows it to do, what it actually reads, what it keeps, and how to cut it off at any time.
Read-only access to code. It never pushes, merges or comments.
Never clones a repository, installs packages or runs your code.
Disconnect or uninstall at any time; scans and writes stop at once.
What GitHub lets the app do
Lockhound connects through a GitHub App, never a personal access token. You choose which repositories it can see: all of them, or only the ones you select. It asks for no organization or account permissions.
| Permission | Access | Why |
|---|---|---|
| Contents | Read-only | List the files of the default branch and read dependency files, plus the few files the malware check looks at (below). It also delivers push events, so a changed lockfile is scanned right away. |
| Metadata | Read-only | Required by GitHub for every app: repository names, default branch, visibility and archived state. |
| Checksoptional | Read and write | Post the Lockhound check on pull requests. It cannot change code, comment or merge. |
| Pull requestsoptional | Read-only | Receive pull request events (branch and commit ids) to know which pull requests to check. Comments and reviews are never read. |
| Issuesoptional | Read and write | Only when someone clicks “Create issue” in Fix with AI: open one issue listing what to fix, keep that same issue up to date, and comment on it and close it once everything is fixed. No other issue is read or changed. |
An honest limit: GitHub has no “lockfiles only” permission. Contents: read lets an app read any file in the repositories you choose. What Lockhound reads is limited by its own code, as listed below, and every scan uses a short-lived token that GitHub narrows to one repository and read-only access.
What it actually reads
File names. The list of file paths on the default branch, to find dependency files. Not their contents.
Dependency files, wherever they are in the repository:
composer.jsoncomposer.lockpackage.jsonpackage-lock.jsonnpm-shrinkwrap.jsonyarn.lockpnpm-lock.yamluv.lockpoetry.lockPipfile.lockrequirements.txtgo.modCargo.lockGemfile.lockgradle.lockfileA few files where malware hides. Attacks such as PolinRider plant code in editor tasks and build configuration, so the malware check also reads at most 60 files of up to 2 MB per scan: .vscode/tasks.json, package.json, .bat scripts, font files (.woff, .woff2, .ttf, .otf, .eot), index.js and app.js within two folders of the repository root, and these build files:
postcss.config.mjspostcss.config.jstailwind.config.jstailwind.config.mjseslint.config.mjsnext.config.mjsnext.config.jsbabel.config.jsastro.config.mjsvite.config.jsvite.config.mjswebpack.config.jsgridsome.config.jsvue.config.jstruffle.jsThey are checked in memory and discarded. On a pull request, only the files it changes are checked. Folders of installed code (node_modules, vendor, bower_components, .git) are never read.
Pull request events, if you grant them: the pull request number, its branch names and commit ids.
Nothing else: not your other source code, not issues, comments, secrets, wikis or Actions logs.
What it writes
Only with the optional permissions above: one check run per pull request, and one issue per repository when you ask for it, which it updates and closes once everything is fixed. It never writes code, opens pull requests, comments anywhere else or merges. Upgrades stay in your hands, or your AI coding agent's.
What it keeps
- Dependency files are held encrypted for at most 6 hours while they are parsed, then discarded.
- The inventory: package names, versions and the paths of the files they came from, with the findings and their history.
- Malware detections: the file path, the rule that matched and a short matched string, never the file.
- Repository details: names, visibility, default branch and last push date.
- GitHub webhook deliveries, which can include commit messages and author names: encrypted, and the body deleted as soon as it is processed. A fingerprint of each delivery is kept for 14 days so it is processed exactly once.
Access tokens from GitHub are never stored in the database: they are cached encrypted until shortly before they expire, within an hour, and revoked at GitHub when you disconnect.
How it is protected
- Every webhook from GitHub is verified against its signature, and each one is processed once.
- Each workspace sees only its own repositories. Connecting a GitHub organization requires access to every repository the installation covers.
- Slack webhook URLs, email recipient lists and other secrets are encrypted at rest. API tokens for AI agents are stored only as hashes, and are revoked when the member who created them leaves.
- Lockfiles are parsed as data, with size and depth limits. Nothing from a repository is executed.
- Vulnerability lookups send only public package names and versions to OSV, never repository names or files. See the privacy policy for every service involved.
Removing access
- In Lockhound: Integrations → Disconnect. Scans, checks and issues stop immediately, and its GitHub tokens are revoked.
- On GitHub: Settings → Applications → Installed GitHub Apps → Lockhound → Configure. Remove single repositories, or uninstall the app. GitHub tells Lockhound, which confirms it with GitHub and stops scanning; from then on it has no access at all.
- Delete the data: deleting a workspace deletes its GitHub connections, repositories, inventory and findings. Until then, history stays so you can still see past findings.
Found a security issue? Email [email protected].
Get started free