Repository Privacy & Security Audit
Purpose
Audit a software repository before:
- pushing to GitHub
- making a repository public
- deploying a website
- sharing source code
- publishing a portfolio project
- releasing an open-source project
The primary goals are:
- Detect secrets and credentials.
- Detect personal/private information.
- Detect company/internal/confidential information.
- Detect files that should not be committed.
- Detect frontend information that becomes public after build.
- Detect source-code exposure risks.
- Detect unsafe deployment configuration.
- Produce an actionable risk report.
This skill is audit-first.
Do NOT delete, rewrite, rotate, redact, or modify files unless the user explicitly asks.
1. Audit Modes
Determine the appropriate mode from the user's request.
QUICK
Use before normal commits.
Check:
- secrets
.env- credentials
- private keys
- obvious PII
- suspicious large/private files
.gitignore- frontend environment variables
FULL
Use before:
- repository goes public
- production deployment
- portfolio publication
- open-source release
Perform every section in this skill.
DEEP
Use when the user explicitly requests a thorough security/privacy review.
In addition to FULL:
- inspect Git history
- inspect build output
- inspect frontend bundles
- inspect source maps
- inspect dependency risks
- inspect public assets
- inspect API architecture
- inspect deployment configuration
If the user did not specify a mode, default to FULL for public/deploy/portfolio scenarios and QUICK for "before commit" scenarios.
2. Establish Repository Context
Before judging findings, understand the project.
Inspect when available:
- README
- package.json
- pyproject.toml
- requirements.txt
- Cargo.toml
- go.mod
- vite.config.*
- next.config.*
- Dockerfile
- docker-compose.*
- deployment configs
.gitignore.env.example- repository structure
Identify:
- frontend
- backend
- APIs
- databases
- cloud services
- authentication
- analytics
- AI APIs
- storage
- deployment target
Do not assume every suspicious string is a secret.
Use surrounding context.
3. Secret Scan
Search the repository for likely credentials.
Examples include:
- API keys
- access tokens
- refresh tokens
- OAuth secrets
- JWT secrets
- database URLs
- passwords
- private keys
- SSH keys
- cloud credentials
- webhook secrets
- service-account credentials
Look for patterns and keywords such as:
API_KEY
APIKEY
SECRET
TOKEN
PASSWORD
PASSWD
PRIVATE_KEY
ACCESS_KEY
CLIENT_SECRET
AUTH_TOKEN
DATABASE_URL
DB_PASSWORD
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
OPENAI_API_KEY
GITHUB_TOKEN
SUPABASE_KEY
FIREBASE
STRIPE_SECRET
Also inspect common credential files:
.env
.env.*
credentials.json
service-account.json
*.pem
*.key
*.p12
*.pfx
id_rsa
id_ed25519
Do not print complete secrets in the report.
Mask them.
Example:
sk-proj-12****************9x
4. Environment Variable Audit
Inspect all environment-variable usage.
Important distinction:
Server-side environment variables may remain private.
Frontend environment variables may become public.
Pay particular attention to:
VITE_*
NEXT_PUBLIC_*
REACT_APP_*
PUBLIC_*
NUXT_PUBLIC_*
Treat client-exposed variables as publicly readable.
Report cases where sensitive credentials are placed in client-visible variables.
Example:
HIGH
VITE_OPENAI_API_KEY
Reason:
VITE variables are bundled into frontend JavaScript.
Recommended action:
Move the API call behind a server-side endpoint.
5. Personal Information Scan
Search for accidentally committed personal information.
Examples:
- phone numbers
- personal email addresses
- home addresses
- precise locations
- ID/passport numbers
- student numbers
- employee IDs
- personal account IDs
- private social-media identifiers
- personal file-system paths
- device names
Examples of paths worth reviewing:
C:\Users\<name>\
/Users/<name>/
/home/<name>/
Do not automatically classify every name or email as a vulnerability.
Distinguish between:
- intentionally public contact information
- development metadata
- accidental private information
6. Organization / Employer Confidentiality Scan
This is especially important for portfolio repositories.
Search for:
- internal screenshots
- admin panels
- staging URLs
- internal domains
- employee names
- customer information
- internal API endpoints
- database screenshots
- unreleased products
- internal documentation
- test accounts
- business metrics
- internal issue IDs
- company credentials
- proprietary source code
Classify uncertain findings as:
REVIEW REQUIRED
Do not assume that information is safe merely because it contains no password.
7. Git Ignore Audit
Inspect .gitignore.
Check whether the project should ignore items such as:
.env
.env.*
!.env.example
node_modules/
dist/
build/
.DS_Store
Thumbs.db
*.log
.vscode/
.idea/
coverage/
*.pem
*.key
*.p12
*.pfx
credentials.json
service-account.json
Adapt recommendations to the actual stack.
Do not blindly recommend ignoring files that the project intentionally tracks.
8. Git Tracking Audit
A file being added to .gitignore does NOT remove it from Git history.
Check whether sensitive files are already tracked.
Pay particular attention to:
.env
credentials
keys
private assets
internal screenshots
database exports
If a secret has ever been committed, assume it may already be compromised.
Recommend:
- rotate/revoke the credential
- remove it from current tracking
- evaluate whether Git history needs rewriting
Never claim that deleting the file alone makes the secret safe.
9. Git History Audit
In FULL or DEEP mode, inspect commit history for previously committed secrets or private files.
Search:
- deleted
.envfiles - old API keys
- credentials
- private documents
- internal screenshots
- database dumps
If a credential existed in history, classify based on actual exposure.
For a public repository, treat exposed active credentials as CRITICAL.
10. Frontend Exposure Audit
For browser-based applications, assume that anything delivered to the browser can be inspected.
Review:
- JavaScript bundles
- source maps
- API endpoints
- public configuration
- comments
- embedded JSON
- frontend environment variables
- GraphQL endpoints
- static assets
- model files
- WebAssembly
- shaders
Do not describe minification or obfuscation as true security.
Use this principle:
> Client-side code can be made harder to understand, but it cannot be made secret.
11. Source Map Audit
For production websites, check whether source maps are enabled.
Examples:
*.js.map
*.css.map
For Vite, inspect:
build.sourcemap
If source-code privacy matters, recommend production configuration similar to:
build: {
sourcemap: false
}
Explain that disabling source maps reduces accidental source exposure but does not make frontend code impossible to inspect.
12. Source Exposure / Repository Deployment Audit
Check whether deployment accidentally exposes:
src/
.git/
.github/
.env
README drafts
design source files
internal documentation
tests containing credentials
backup files
Look for risky backup extensions:
.bak
.old
.backup
.tmp
A production server should not expose .git.
Treat publicly accessible .git directories as HIGH or CRITICAL depending on contents.
13. Public Asset Audit
Inspect:
public/
static/
assets/
Look for:
- original photography
- full-resolution media
- EXIF metadata
- private documents
- PSD files
- Figma exports
- CAD files
- source 3D models
- internal screenshots
- PDFs
- resumes containing excessive personal information
For portfolio websites, distinguish between:
display assets
and
source assets
Prefer publishing optimized derivatives rather than editable originals when source protection matters.
14. Image Metadata Review
Where relevant, inspect image metadata.
Potential metadata includes:
- GPS coordinates
- device model
- capture time
- author name
- software
- comments
Do not automatically remove metadata.
Report privacy-sensitive metadata and ask before modifying files.
15. API Architecture Audit
Identify API calls performed directly from the frontend.
Determine whether they require secrets.
Bad architecture:
Browser
↓
Third-party API using secret key
Preferred architecture:
Browser
↓
Own backend/serverless endpoint
↓
Third-party API
Report client-side secret dependencies as HIGH.
16. Authentication and Authorization
If the application contains protected/private pages, inspect whether protection is only implemented in frontend JavaScript.
Example of insufficient protection:
if (password === "123456") {
showPrivatePage()
}
Explain:
Frontend UI gates are not real access control.
For genuinely private content, authentication and authorization must be enforced server-side or by the hosting platform.
17. Dependency Review
In FULL/DEEP mode, inspect dependencies for obvious security concerns.
Where tooling is available, use the ecosystem's established audit mechanism.
Examples:
npm audit
pnpm audit
yarn audit
pip-audit
cargo audit
Do not automatically upgrade dependencies.
Report:
- affected dependency
- severity
- whether it is direct/transitive
- likely relevance to this application
18. Dangerous Code Patterns
Search for security-sensitive patterns such as:
eval()
new Function()
dangerouslySetInnerHTML
innerHTML
shell=True
exec()
system()
subprocess
Context matters.
Do not label every occurrence as vulnerable.
Determine whether untrusted input can reach the dangerous operation.
19. Deployment Review
Inspect relevant deployment configuration.
Possible targets:
- GitHub Pages
- Vercel
- Netlify
- Cloudflare Pages
- nginx
- Docker
- self-hosted servers
Check for:
- source maps
- exposed environment variables
- directory listing
.gitexposure- unsafe CORS
- debug mode
- development servers
- publicly accessible admin routes
- insecure headers
20. Portfolio-Specific Review
When auditing a personal portfolio, separately review:
Public identity
Is this information intentionally public?
Examples:
- name
- professional email
- GitHub
- portfolio domain
Do not flag intentionally published professional identity as automatically unsafe.
Private identity
Flag accidental disclosure of:
- phone number
- home address
- precise location
- personal documents
- student/employee identifiers
- private email
- travel documents
Employer material
Treat:
- internal tools
- admin screenshots
- unreleased projects
- internal dashboards
- internal URLs
as requiring explicit review before publication.
21. Risk Classification
Use only these levels.
CRITICAL
Immediate compromise or highly sensitive exposure.
Examples:
- active private key
- active production credential
- database password
- service-account credential
- publicly exposed credential with meaningful privileges
HIGH
Serious privacy/security exposure.
Examples:
- frontend secret
- internal company credentials
- exposed
.git - real authentication implemented only client-side
- sensitive private documents
MEDIUM
Meaningful but not immediately catastrophic.
Examples:
- production source maps
- personal phone number
- internal URLs
- excessive image metadata
- source assets unintentionally published
LOW
Hardening or hygiene issue.
Examples:
- unnecessary debug files
- minor information leakage
- weak
.gitignore - unnecessary comments
INFO
Not a vulnerability, but useful to know.
22. Confidence
Every important finding should include confidence:
High confidence
Medium confidence
Low confidence
Do not overstate uncertain findings.
23. False Positive Handling
Before reporting something as a vulnerability, ask:
- Is it actually sensitive?
- Is it intentionally public?
- Is it reachable?
- Is it included in the production build?
- Is it tracked by Git?
- Is it only an example value?
- Is it already revoked?
- Is it test/mock data?
Example:
OPENAI_API_KEY=your_key_here
is probably an example.
Do not classify it like a real credential.
24. Safe Reporting
Never reproduce full credentials.
Never expose additional private information while writing the report.
Use:
OPENAI_API_KEY = sk-proj-****9x
instead of the complete value.
25. Modification Policy
Default behavior:
AUDIT ONLY
Do not automatically:
- delete files
- modify
.gitignore - rotate keys
- rewrite Git history
- move files
- edit source code
- remove metadata
First report findings.
Then present proposed fixes.
Only apply fixes after explicit user approval.
Exception:
If the user explicitly asks for:
audit and fix
you may fix low-risk configuration/code issues while still asking before destructive actions such as Git-history rewriting, credential revocation, or deleting user assets.
26. Required Output
Always end with a concise report.
Use:
Privacy & Security Audit
Overall status
Choose:
PASS
PASS WITH WARNINGS
ACTION REQUIRED
CRITICAL
Summary
Critical: X
High: X
Medium: X
Low: X
Info: X
Findings
For each finding:
[HIGH] Client-side API credential
Location:
src/lib/api.ts:12
Finding:
A credential appears to be included in client-side code.
Why it matters:
Frontend JavaScript is delivered to visitors and can be inspected.
Recommended action:
Move the third-party API request behind a server-side endpoint.
Confidence:
High
GitHub Public Readiness
Answer:
READY
READY AFTER FIXES
NOT READY
Explain why.
Deployment Readiness
Answer:
READY
READY AFTER FIXES
NOT READY
Top Actions
Provide no more than five highest-priority actions.
27. Portfolio Source Protection Addendum
When the user specifically wants to reduce casual source copying, additionally check:
- production source maps disabled
- repository visibility
- editable source assets excluded
- original 3D/CAD files excluded
- high-resolution originals excluded where unnecessary
- production build contains only required files
- proprietary algorithms moved server-side where feasible
- no accidental
/srcdeployment
Clearly state:
> Browser-delivered frontend code cannot be made completely secret. Minification, bundling, and obfuscation increase reverse-engineering cost but are not security boundaries.
Do not recommend anti-user tricks such as:
- disabling right click
- blocking F12
- detecting DevTools
- disabling text selection
unless the user specifically asks about them, and explain their limitations.
28. Final Principle
Optimize for:
No leaked secrets
No accidental private information
No confidential employer material
No unnecessary source exposure
No false sense of frontend security
The purpose of this skill is not to make publication impossible.
The purpose is to help the user confidently answer:
> "Is this repository or website safe to publish?"
29. Execution Notes (Windows / Git Bash)
Practical commands for carrying out the scan efficiently.
Shell PATH fix
In this environment ls / find may be missing until PATH is set:
export PATH="/usr/bin:/bin:$PATH"
Fast secret sweep
Use the Grep tool (ripgrep) rather than shell grep. Run several patterns in parallel:
(?:api[_-]?key|secret|token|passwd|password|private[_-]?key|access[_-]?key|client[_-]?secret)
-----BEGIN (?:RSA |OPENSSH |EC |PGP )?PRIVATE KEY-----
(?:sk-|ghp_|gho_|ghs_|github_pat_|xox[baprs]-|AKIA[0-9A-Z]{16}|AIza[0-9A-Za-z_-]{35})
Then narrow to non-lockfile, non-node_modules hits and read surrounding lines for context.
Files listing
export PATH="/usr/bin:/bin:$PATH"
find <repo> -maxdepth 2 -not -path '*/node_modules*' -not -path '*/.git/*'
ls -la <repo> # catches dotfiles like .env
Git tracking / history
git -C <repo> ls-files | grep -Ei '\.env|credential|secret|\.pem|\.key|service-account'
git -C <repo> log --all --diff-filter=A --name-only --pretty=format: | sort -u | grep -Ei '\.env|credential|secret|\.pem'
git -C <repo> log --all -S 'API_KEY' --oneline
If there is no .git directory, say so and skip sections 8/9 — do not invent findings.
Build output / source maps
ls <repo>/dist/assets 2>/dev/null | grep -E '\.map$'
grep -n 'sourcemap' <repo>/vite.config.* <repo>/next.config.* 2>/dev/null
Dependency audit
Only run when the toolchain is present; failures are not findings.
cd <repo> && npm audit --omit=dev 2>&1 | tail -30
Report discipline
- Mask every credential (
sk-proj-****9x), never paste full values. - Report paths, not file contents, for sensitive documents.
- State confidence for every finding.
- If a section could not be checked (no build output, no git, tool missing), mark it explicitly as not checked instead of silently passing it.
