Getting Started with ClaudeSec
This guide follows the same scanner onboarding anchors as README.md.
Scanner Anchors
Scanner Quick Start
Copy-paste minimal example
./scripts/run-scan.sh
Expected output: security scan starts and creates scan-report.json in the project root.
Prerequisites
- Git
- Claude Code CLI
- A project repository to secure
Clone and run
git clone https://github.com/Twodragon0/claudesec.git
cd claudesec
./scripts/run-scan.sh
./scanner/claudesec scan -d .
./scanner/claudesec scan --category cloud
./scanner/claudesec scan --severity high,critical
Scanner CI Templates
Copy-paste minimal example
./scripts/setup.sh /path/to/project
Expected output: workflow templates and reusable actions are copied into the target repository.
Bootstrap a target repository
./scripts/setup.sh /path/to/project
Core templates
templates/prowler.ymltemplates/security-scan-suite.ymltemplates/codeql.ymltemplates/dependency-review.yml
Reusable workflow components
.github/actions/token-expiry-gate.github/actions/datadog-ci-collect
CI policy variables
CLAUDESEC_STRICT_SSOCLAUDESEC_TOKEN_EXPIRY_GATE_MODECLAUDESEC_TOKEN_EXPIRY_PROVIDERSCLAUDESEC_TOKEN_EXPIRY_STRICT_PROVIDERS
Scanner OAuth & Token Policy
Copy-paste minimal example
export OKTA_OAUTH_TOKEN="<okta-oauth-access-token>"
./scanner/claudesec scan -c saas
Expected output: SaaS checks run with OAuth-first paths; strict mode (if enabled) fails on missing required scopes.
Okta automation should prefer scoped OAuth tokens over SSWS tokens.
- Preferred:
OKTA_OAUTH_TOKEN - Fallback:
OKTA_API_TOKEN - Strict scope mode:
CLAUDESEC_STRICT_OKTA_SCOPES=1 - Scope customization:
CLAUDESEC_OKTA_REQUIRED_SCOPES
export OKTA_ORG_URL="https://dev-123456.okta.com"
export OKTA_OAUTH_TOKEN="<okta-oauth-access-token>"
export CLAUDESEC_OKTA_REQUIRED_SCOPES="okta.users.read,okta.policies.read,okta.logs.read"
export CLAUDESEC_STRICT_OKTA_SCOPES=1
./scanner/claudesec scan -c saas
See Okta OAuth guidance.
Dashboard Workflow
Copy-paste minimal example
./scripts/run-dashboard-safe.sh --quick
Expected output: a quick dashboard build is generated and served locally at http://127.0.0.1:11777 or the next available fallback port.
Recommended day-to-day flow
./scripts/run-dashboard-safe.sh --quick
./scripts/run-dashboard-safe.sh --no-serve
./scripts/run-dashboard-safe.sh --kill-port
--quick: fast smoke check for the dashboard layout and the highest-signal scanner categories.--no-serve: generateclaudesec-dashboard.htmlas a reviewable artifact without starting a local server.--kill-port: reclaim port11777when a stale local server is blocking the default endpoint.
Advanced direct CLI serve
./scanner/claudesec dashboard --serve --host 127.0.0.1 --port 11665
Use the direct CLI form when you need an explicit host/port or want to bypass the safe runner’s fallback behavior.
Scanner SaaS Live Scan
./scanner/claudesec scan -c saas
export GH_TOKEN_EXPIRES_AT="2026-04-30T08:30:00Z"
export OKTA_OAUTH_TOKEN_EXPIRES_AT="2026-04-30T09:00:00Z"
export CLAUDESEC_TOKEN_EXPIRY_WARNING_24H="24h"
export CLAUDESEC_TOKEN_EXPIRY_WARNING_7D="7d"
./scanner/claudesec dashboard --serve --host 127.0.0.1 --port 11665
Optional Datadog local fetch
DD_API_KEY=<your-dd-api-key> DD_APP_KEY=<your-dd-app-key> DD_SITE=datadoghq.com ./scanner/claudesec dashboard
Kubernetes and Prowler: kubeconfig and OIDC
- Kubeconfig: If you do not set
KUBECONFIGorkubeconfigin.claudesec.yml, the scanner auto-discovers from conventional paths:configs/dev/kubeconfig,configs/staging/kubeconfig,./kubeconfig(relative to the project). Prefer a relative path in.claudesec.yml(e.g.kubeconfig: configs/dev/kubeconfig) so the repo stays portable. - OIDC / Okta: If your kubeconfig uses
kubectl oidc-login(exec auth), runkubectl get nodesonce to complete browser sign-in, then runclaudesec scan -c prowlerorclaudesec dashboard -c prowler. The scanner will wait up to 45s for OIDC login when it detects an oidc-login context.
What’s Next?
- Workflow Components
- DevSecOps Pipeline Guide
- Branch Protection
- SaaS Best Practices Scans
- Shell Lint Policy