Claude Code से व्यावहारिक सुरक्षा ऑडिट कैसे करें

सुरक्षा को बिना सीमा तय किए AI पर न छोड़ें

Claude Code सुरक्षा ऑडिट को तेज कर सकता है। यह routes पढ़ सकता है, pull request diff समझ सकता है, dependency risk का सार दे सकता है, खतरनाक logs खोज सकता है, environment variables की सूची बना सकता है और repeated review steps को checklist में बदल सकता है। असली जोखिम अक्सर एक ही फाइल में नहीं होता। वह authentication middleware, authorization rules, billing jobs, webhooks, CI और logs में फैला होता है।

लेकिन सिर्फ “security check कर दो” कहना सुरक्षित तरीका नहीं है। ऐसा prompt अक्सर सामान्य सलाह देता है, जिसे release decision का प्रमाण नहीं माना जा सकता। सुरक्षा ऑडिट का मतलब है scope, assets, threats, controls, evidence और remaining risk को साफ लिखना। Claude Code investigator और organizer की तरह मदद करता है, पर business risk और release approval मनुष्य को ही तय करना होता है।

इस लेख में beginner-friendly workflow है जिससे Claude Code के साथ practical security audit किया जा सकता है, बिना unsafe exploit details प्रकाशित किए। हम scope, asset inventory, threat model, dependency review, auth/session review, secrets review, input validation, logging/PII, CI gates, evidence receipt और चार use cases देखेंगे। बाहरी reference के लिए OWASP Top 10, OWASP ASVS, NIST SSDF और GitHub secret scanning उपयोगी हैं।

सबसे पहले scope लिखें

पहला deliverable code fix नहीं, audit brief है। Scope Claude Code को बताता है कि क्या inspect करना है, क्या नहीं बदलना है, कौन से commands चल सकते हैं और काम पूरा कब माना जाएगा। Scope न होने पर AI visible files पर टिप्पणी कर सकता है, लेकिन admin routes, billing flow, background jobs, deploy scripts या CI secrets छूट सकते हैं।

इस template को session में paste करके भरें।

# Security Audit Brief

## Goal
- Find serious issues in authentication, authorization, secrets, input validation, logging, and dependencies before release
- Produce evidence and remaining-risk notes, not just suggested fixes

## Scope
- Repository:
- Branch or PR:
- Feature or workflow:
- Directories Claude Code may inspect:
- Directories Claude Code must not change:
- Commands Claude Code may run:

## Priority areas
- Authentication and session handling
- Authorization and roles
- Input validation and output encoding
- Secrets and environment variables
- Dependencies and licenses
- Logs, PII, and audit events
- CI gates that should block release

## Completion criteria
- Record findings in the risk register
- Include only minimal reproduction context
- Do not include live secrets, customer data, or dangerous exploit instructions
- Record commands, results, skipped areas, and human-review items in the evidence receipt

Brief देने के बाद तुरंत code modify न कराएं। पहले map बनवाएं: “routes, auth middleware, external APIs, environment variables, logging points, CI jobs और high-risk files list करें। अभी code change न करें।” इससे human reviewer देख सकता है कि कोई important area छूटा तो नहीं।

Asset inventory और threat model बनाएं

Security तभी समझ आती है जब पता हो कि क्या protect करना है। Assets में user data, billing status, API keys, admin panel, audit logs, uploaded files, support messages और analytics data आ सकते हैं। Threat model एक छोटा नक्शा है: कौन किस entry point से आएगा, क्या प्रभावित करना चाहेगा और कौन सा control उसे रोकेगा।

| Asset | Stored in | Entry point | Likely threat | Required control | Owner |
| --- | --- | --- | --- | --- | --- |
| User email address | users table | signup, admin | unauthorized access, log leakage | authorization, PII masking, audit log | backend |
| Billing status | billing table, Stripe | webhook, admin | tampering, duplicate processing | signature verification, idempotency, role checks | backend |
| API keys | env, secret manager | CI, runtime | repository leak, log exposure | secret scanning, rotation, least privilege | platform |
| Admin console | /admin | browser | privilege escalation | MFA, admin role, operation logs | product |

इस table को Claude Code को देकर trust boundaries और tests जोड़ने को कहें। Trust boundary का मतलब है भरोसेमंद system और untrusted input के बीच की सीमा। Browser input, webhook, uploaded CSV, Markdown, file name और third-party API response को validation से पहले trust नहीं करना चाहिए।

Claude Code को साफ review lanes दें

Dependency review में package.json, lockfile, Docker image, GitHub Actions, runtime version और transitive dependencies देखनी चाहिए। npm audit पूरा audit नहीं है। Claude Code से कहें कि production में reachable risk, dev-only noise, breaking change risk और update के बाद चलने वाले tests अलग-अलग लिखे।

Auth और session review में login, logout, password reset, MFA, OAuth, cookie flags, session expiry, CSRF और server-side authorization देखें। “User login है” और “User यह action कर सकता है” अलग बातें हैं। Admin APIs, billing actions, file downloads, route parameter में user id और replayable webhooks में authorization gap अक्सर मिलता है।

Secrets review में .env, CI secrets, sample config, README, logs, screenshots और test fixtures शामिल करें। Claude Code को live secret value chat में print नहीं करनी चाहिए। अगर suspected secret मिले, report में file path, secret type, rotation need और owner लिखें, value redact करें। GitHub पर secret scanning और push protection भी verify करें।

Input validation review में देखें कि data कहाँ enter करता है, कहाँ store होता है, कहाँ render होता है और कहाँ forward होता है। Dangerous payloads मांगने के बजाय boundary validation, normalization, escaping, type checks और tests मांगें। Beginners के लिए data flow follow करना vulnerability names याद करने से अधिक practical है।

Logging और PII review में emails, names, addresses, tokens, cookies, auth headers, payment IDs और free-text support content खोजें। Development वाला console.log production log में रह जाए तो retention और leakage risk बनता है। Logs में केवल debugging और audit के लिए जरूरी minimum fields रखें।

चार practical use cases

पहला use case pre-release SaaS audit है। Billing, invites, organization settings या admin feature release करने से पहले Claude Code से PR diff, migrations, routes, webhook handlers, tests और CI पढ़वाएं। उद्देश्य “सब safe है” कहलवाना नहीं, बल्कि release meeting के लिए risk register बनाना है।

दूसरा use case GitHub repo handoff audit है। जब नया repo मिलता है, risk अक्सर README में नहीं बल्कि deploy scripts, CI secrets, environment names, manual runbooks और owner-less directories में होता है। Claude Code से first-week checklist बनवाएं: क्या rotate करना है, क्या document करना है, कौन से CI gates missing हैं और कहाँ human owner review चाहिए।

तीसरा use case incident follow-up audit है। Outage या suspected leak के बाद केवल culprit line fix करना काफी नहीं है। Claude Code से similar patterns खोजने, logs में PII देखने, regression tests सुझाने, CI gates update करने और runbook सुधारने को कहें। Public report में impact और remediation लिखें, लेकिन reusable exploit steps न फैलाएं।

चौथा use case AI-generated PR security review है। AI-generated code साफ दिख सकता है, पर authorization, audit logs, error handling या tests missing हो सकते हैं। Claude Code को narrow prompt दें: “इस diff का security impact देखें: attack surface, permissions, secrets, personal data, dependency change और CI coverage.”

Risk register और evidence receipt रखें

Finding को evidence चाहिए। सिर्फ severity काफी नहीं है। Impact, evidence, recommended action, priority, status और owner लिखना जरूरी है।

| ID | Risk | Impact | Evidence | Recommended action | Priority | Status | Owner |
| --- | --- | --- | --- | --- | --- | --- | --- |
| SEC-001 | Missing authorization on admin API | Another user's data may be changed | routes/admin.ts has no role check | Add middleware and regression tests | High | Open | backend |
| SEC-002 | Webhook logs include email | Unnecessary PII retention | logs/webhook-sample.txt | Mask email and reduce retention | Medium | Open | platform |

Evidence receipt audit को scattered chat log बनने से रोकता है। छोटा हो सकता है, पर यह बताना चाहिए कि क्या check हुआ और क्या नहीं।

# Security Audit Evidence Receipt

- Target:
- Date:
- Reviewer:
- Scope provided to Claude Code:
- Commands executed:
- Files or directories inspected:
- High-risk findings:
- Fixed items:
- Skipped or out-of-scope areas:
- Decisions requiring human review:
- Release recommendation:

PR review checklist

Pull request में वही छोटा checklist हर बार paste करें। AI-generated change में यह खास उपयोगी है, क्योंकि discussion style से हटकर risk और evidence पर आती है।

## Security PR Review

- [ ] Scope is clear and no unrelated files are changed
- [ ] Authenticated users cannot access another user's data
- [ ] Admin or billing actions require explicit authorization
- [ ] Inputs are validated at the boundary
- [ ] Outputs are escaped or rendered safely
- [ ] No secrets, tokens, cookies, or PII are printed to logs
- [ ] Dependency changes have a reason and test evidence
- [ ] Errors do not reveal internals
- [ ] CI includes lint, tests, typecheck, and security-relevant checks
- [ ] Risk register and evidence receipt are updated

Command checklist

Commands stack पर निर्भर करते हैं, लेकिन Node या TypeScript project में शुरुआत यहां से हो सकती है। Claude Code से कहें कि हर command का उद्देश्य पहले बताए और failure पर रुककर risk summary दे।

git status --short
npm ci
npm audit --audit-level=moderate
npm run lint
npm run typecheck
npm test
rg -n "TODO|FIXME|console\\.log|process\\.env|localStorage|innerHTML|dangerouslySetInnerHTML" src
git diff --check

rg results सिर्फ clues हैं, verdict नहीं। process.env सही use हो सकता है, और innerHTML sanitize होने पर acceptable हो सकता है। Claude Code से evidence, assumption और confirmation step अलग-अलग लिखवाएं।

आम गलतियां और traps

सबसे बड़ी गलती vague prompt है। “Security देखो” से shallow answer मिलता है। बेहतर prompt scope, assets, release deadline, allowed commands, high-risk flows और output format बताता है। बिना evidence वाले confident conclusion से “यह हिस्सा review नहीं हुआ” लिखी report बेहतर है।

दूसरी गलती evidence न रखना है। अगर किसी को नहीं पता कौन से commands चले, कौन सी files देखी गईं और क्या out of scope था, audit release decision में मदद नहीं करेगा। Claude Code की बातों को CI output, tests, diffs, logs और config से verify करें।

खतरनाक गलती public place में बहुत detail publish करना है। Public issue या blog में live URLs, tokens, customer data या step-by-step exploit instructions न डालें। Public text impact और remediation पर रहे। Sensitive reproduction restricted tracker में रखें।

Secrets और logs को हल्का न लें। Application code ठीक हो सकता है, फिर भी CI logs, debug screenshots, sample .env या verbose errors से data leak हो सकता है। Auth, payments, personal data और admin tools में high-risk changes पर human review mandatory रखें।

CI और team habit में शामिल करें

एक बार का audit जल्दी पुराना हो जाता है। CI में lint, typecheck, tests, dependency audit, secret scanning, dangerous API search और log policy checks जोड़ें। हर warning build block न करे। Practical rule: High block करे, Medium dated ticket बने, Low periodic maintenance में जाए।

Claude Code की permissions भी review करें। Claude Code permissions guide, secrets management, security failure cases और code review workflow साथ पढ़ें। अगर team को वास्तविक repository में audit brief, CI gates और review policy बनानी है, तो Claude Code training and consultation से शुरुआत करें।

निष्कर्ष

Claude Code security audit में तभी मजबूत है जब human पहले system बनाता है: scope, assets, threat model, review lanes, risk register, evidence receipt, CI gates और high-risk decisions के लिए human approval। इनके बिना report अच्छी दिख सकती है, पर real risk समझा नहीं पाती।

Masa ने ClaudeCodeLab के pre-release review में यह workflow लागू किया तो सबसे बड़ा लाभ risk register और evidence receipt से मिला। Claude Code ने पहले routes, logs, environment variables और CI inventory बनाया, फिर human review ज्यादा sharp हुई। परिणाम perfect security guarantee नहीं था, बल्कि release decision के लिए साफ evidence और visible open questions थे।