We release security updates for the following versions:

We take security vulnerabilities seriously. If you discover a security issue, please follow responsible disclosure:

DO NOT create a public GitHub issue for security vulnerabilities.

Instead, please report security issues via:

1. GitHub Security Advisories (Preferred)

   • Go to https://github.com/maksim/kroker/security/advisories
   • Click "Report a vulnerability"
   • Fill out the form with details

2. Email (Alternative)

   • Send to: security@maksim.dev (update with your actual email)
   • Use PGP if available (key: TBD)
   • Include "Kroker Security" in the subject line

Please provide:

• Description - Clear explanation of the vulnerability
• Impact - What an attacker could do with this vulnerability
• Reproduction - Step-by-step instructions to reproduce
• Version - Which version(s) are affected
• Patches - If you have a fix, include it (optional)

• 24 hours - Initial acknowledgment
• 72 hours - Preliminary assessment
• 7 days - Detailed response with remediation plan
• 30 days - Patch released (for critical issues)
• 90 days - Public disclosure (after patch)

1. Keep Kroker Updated

   go install github.com/maksim/kroker/cmd/kroker@latest

2. Review Agent Specs

   • Never run specs from untrusted sources
   • Review spec content before execution
   • Use scope restrictions to limit file access

3. Validate Run Bundles

   • Check bundle integrity before accepting
   • Review diffs carefully
   • Verify gate results

4. Protect Sensitive Data

   • Use .env files, not hardcoded secrets
   • Add sensitive files to .gitignore
   • Use scope.forbidden_paths for secret directories

5. Run Quality Gates

   • Always enable security gates
   • Include dependency scanning
   • Validate before accepting changes

1. Code Review

   • All changes require review
   • Security-sensitive changes need extra scrutiny
   • Use linters and static analysis tools

2. Dependencies

   • Keep dependencies updated
   • Review dependency changes
   • Run govulncheck regularly

3. Testing

   • Write security tests
   • Test edge cases and error paths
   • Validate input sanitization

4. Secrets

   • Never commit secrets
   • Use pre-commit hooks
   • Review .gitignore regularly

Risk: Malicious specs could execute arbitrary commands

Mitigations:

• Specs are YAML, not executable code
• Agent commands are executed via execve, not shell
• Scope restrictions limit file access
• Quality gates validate changes

Risk: Agent could access files outside worktree

Mitigations:

• Git worktrees provide filesystem isolation
• Scope validation checks all modified files
• Event log records all file changes
• Bundle verification detects tampering

Risk: Malicious gates could execute harmful commands

Mitigations:

• Gates defined in user-controlled specs
• Gates run with user's permissions
• Timeout limits prevent infinite execution
• Output is captured and logged

Risk: Run bundles could be modified after creation

Mitigations:

• SHA-256 hash of spec stored in bundle
• Event log is append-only JSONL
• Accept command validates bundle integrity
• Warnings shown if bundle appears modified

Risk: User input could inject shell commands

Mitigations:

• Commands executed via execve, not shell
• Arguments passed as array, not string
• Environment variables sanitized
• No eval or dynamic code execution

Every run includes:

• SHA-256 hash of spec content
• Signed event log entries
• Tamper-evident bundle structure
• Verifiable audit trail

Restrict agent file access:

scope:
  allowed_paths:
    - "internal/auth/**"
    - "internal/api/**"
  forbidden_paths:
    - "**/secrets/**"
    - "**/.env"

Enforce security checks:

gates:
  - name: security
    command: gosec ./...
    timeout: 2m
  - name: vuln-check
    command: govulncheck ./...
    timeout: 3m
  - name: dependency-audit
    command: go list -json -m all | nancy sleuth
    timeout: 2m

Complete audit trail:

• Every command execution
• All file modifications
• Gate results and outputs
• User acceptance decisions

None reported yet.

After a security issue is fixed:

1. Security advisory published
2. CVE assigned (if applicable)
3. Release notes include security fixes
4. Credit given to reporter (if desired)

We recognize security researchers who help improve Kroker:

• (None yet - you could be first!)

We use:

• govulncheck - Go vulnerability database
• gosec - Go security checker
• Dependabot - Dependency updates
• CodeQL - Static analysis (GitHub)

Regular security reviews:

• Code review process
• Quarterly security audits
• Penetration testing (planned)

Kroker:

• Stores data locally (no cloud)
• Does not transmit user data
• Does not collect telemetry
• Does not require authentication

We ensure:

• Dependencies from trusted sources
• Verified module checksums
• Minimal dependency tree
• Regular dependency updates

For security questions (non-vulnerabilities):

• GitHub Discussions: https://github.com/maksim/kroker/discussions
• Documentation: docs/security.md

For vulnerability reports, see Reporting a Vulnerability above.

Thank you for helping keep Kroker secure!