DevShield handles GitHub credentials, repository source code, AI provider credentials, webhook events, and generated patches. Treat all of these as sensitive.

Never commit:

• AI_API_KEY
• GITHUB_APP_PRIVATE_KEY
• GITHUB_CLIENT_SECRET
• GITHUB_WEBHOOK_SECRET
• SESSION_SECRET
• WORKER_SECRET
• GitHub personal access tokens
• .env files
• .pem or .key private-key files
• Production database credentials

Use .env.example as the public template.

• Use a GitHub App for production access.
• Prefer the smallest repository permissions required.
• Installation tokens are short-lived and should be generated on demand.
• Keep the App private key server-side.
• Verify X-Hub-Signature-256 before processing webhook payloads.
• Use HTTPS for production webhook endpoints.

AI output is untrusted input. DevShield validates generated patch operations before allowing Patch-to-PR actions.

Do not treat AI output as automatically safe. Review generated changes and let CI run before merging.

Do not execute untrusted repository code as part of scanning. Source and dependency analysis should operate on data, not by running arbitrary project scripts.

Use disposable repositories when testing Patch-to-PR and automatic PR workflows.

Protect POST /api/jobs/worker with WORKER_SECRET and call it only from a trusted scheduler or internal network.

1. Revoke or rotate it immediately.
2. Remove it from the working tree.
3. If it was committed, remove it from Git history.
4. Check GitHub secret-scanning alerts.
5. Update the affected deployment with the replacement credential.

Deleting a secret from the latest commit does not make an old committed secret safe.

For a private security report, contact the repository owner through the GitHub profile associated with this project rather than opening a public issue containing exploit details or credentials.

GitHub security guidance: https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories