Skip to content
vetkit

Security

Security at vetkit

You trust a code auditor with your source, so security is the product. Here is how we protect your code and how to tell us if we got something wrong.

Last updated

Report a vulnerability

Email security@vetkit.dev with a description of the issue, the steps to reproduce it, the affected URL, endpoint or package version, and the impact you believe it has. Proof-of-concept code or screenshots help. Please do not open public GitHub issues for security problems.

Our security.txt is published at /.well-known/security.txt.

vetkit does not run a paid bug bounty during the beta. We are grateful for every report and, with your permission, will credit you publicly once the issue is fixed.

Scope

In scope:

  • vetkit.dev, app.vetkit.dev and api.vetkit.dev
  • The @vetkit/mcp npm package
  • The vetkit GitHub App, including webhook handling and the audit pipeline

Out of scope:

  • Denial-of-service and volumetric testing, spam or social engineering of staff or users
  • Findings in third-party services we use (report those to the vendor)
  • Missing best-practice headers or TLS settings without a demonstrated impact
  • Reports generated only by automated scanners without a working proof of concept

Test only against accounts, organizations and repositories you own, and never access, modify or retain other users’ data. If you encounter it by accident, stop and tell us.

Safe harbor

If you act in good faith and follow this policy, we will not pursue or support legal action against you for your research, and we will consider your activity authorized. If a third party takes action against you for research that complied with this policy, we will make it known that you acted with our authorization.

Our commitments

  • Acknowledge your report within 3 business days.
  • Keep you informed while we investigate and fix the issue.
  • Coordinate public disclosure with you once a fix is released.

How we protect your code

Least-privilege GitHub access

The vetkit GitHub App requests read-only permissions for contents, metadata and pull requests, plus read access to your email address at sign-in. It cannot push code, change settings or access repositories you have not selected. For each audit we mint an installation token restricted to that single repository and to read-only contents and metadata. It expires within an hour and is never written to disk or to the database; we do not store your GitHub user token at all.

No code execution

Audits never install dependencies, run build scripts or execute tests. Checkouts are shallow, git hooks are disabled, symbolic links are not materialized, and analyzers only read files through a vetted file index. A repository’s own scanner configuration files are ignored, so a repository cannot hide its own findings. Size and file-count limits stop oversized repositories before analysis.

Ephemeral workspaces

Every audit runs in a fresh temporary directory that is removed when the audit finishes, fails or is cancelled. A periodic reaper deletes anything left behind by a crashed worker. Analyzer processes run with timeouts, output limits and an allowlisted environment that does not contain our credentials.

Data minimization

We keep findings, not repositories. Secret values are redacted before storage and only a one-way hash is kept to track a finding across audits. Session tokens and API key secrets are stored as hashes. API keys are scoped, rate-limited, can expire, and are revoked instantly.

Transport and storage

All traffic uses HTTPS; vetkit.dev is on the HSTS preload list as part of the .dev top-level domain. Session cookies are HttpOnly, Secure and SameSite=Lax, and state-changing requests are checked against an origin allowlist. Our database provider encrypts data at rest.

Webhook integrity

GitHub webhook deliveries are verified with an HMAC signature before they are processed, and duplicate deliveries are ignored.

See also our Privacy Policy for what we store and for how long.