[RFC] Go-native Migration: Replace Python Wrappers with Native Go Tools

[Delqhi]

Background

Currently, our security tools use a hybrid architecture:

• Go-native tools: SAST (Phase 7), Secrets Scanner (Phase 8), Security Bundle Orchestrator (Phase 6)
• Python wrappers: SCA (Phase 1), Container (Phase 2), IaC (Phase 3), License (Phase 4), DAST (Phase 5), SBOM (Phase 9)

Problem

Python wrappers introduce:

• Runtime overhead: Python startup + Go binary execution
• Dependency complexity: Python + Go environments required
• Distribution overhead: Larger Docker images, slower CI pipelines
• Maintenance overhead: Two language stacks to maintain

Proposal

Migrate Python wrapper tools to native Go implementations while keeping Python tools as optional backends for specific integrations.

Migration Plan

Phase 1: SCA (Phase 1) - High Priority

• Port dependency parsing from Python to Go
• Implement grype API client in Go (using existing grype JSON output)
• Parse package-lock.json, requirements.txt, go.mod, pom.xml natively in Go
• Port SCA test suite (10 tests) to Go
• Remove Python SCA wrapper

Phase 2: Container (Phase 2) - High Priority

• Port trivy JSON parsing to Go (trivy is already Go, we just need a client)
• Implement trivy filesystem scan client in Go
• Port container test suite (12 tests) to Go
• Remove Python Container wrapper

Phase 3: SBOM Generator (Phase 9) - Medium Priority

• Port SPDX 2.3 JSON generator to Go
• Port CycloneDX 1.5 JSON generator to Go
• Port dataclasses to Go structs
• Port SBOM test suite (28 tests) to Go
• Remove Python SBOM generator

Phase 4: IaC (Phase 3) - Low Priority (Keep Python)

• Keep Python wrapper for Checkov (Checkov is Python-native)
• Build Go client that calls Checkov via subprocess
• IaC rules are complex to replicate in Go

Phase 5: License (Phase 4) - Low Priority (Keep Python)

• Keep Python wrapper for Scancode (Scancode is Python-native)
• Build Go client that calls Scancode via subprocess
• License parsing is complex to replicate in Go

Phase 6: DAST (Phase 5) - Low Priority (Keep Python)

• Keep Python wrapper for ZAP (ZAP is Java/Python)
• Build Go client that calls ZAP API via HTTP
• DAST is inherently network-based, language agnostic

Benefits

• Single binary distribution: One Go binary for all security tools
• Faster startup: No Python interpreter overhead
• Smaller Docker images: No Python runtime needed
• Simpler CI/CD: Go binary only, no pip install
• Better cross-compilation: Go builds for any platform
• Unified codebase: One language, one toolchain, one mental model

Acceptance Criteria

• All Phase 1, 2, 9 tools migrated to Go-native
• 100% test coverage maintained or improved
• CLI commands remain unchanged for backward compatibility
• Performance benchmarks show improvement (faster scan startup)
• Docker image size reduced by at least 50%
• CI pipeline simplified (no Python setup needed)

References

• Current Go tools: SAST, Secrets Scanner, Security Bundle Orchestrator
• Current Python tools: SCA, Container, IaC, License, DAST, SBOM
• Go CLI framework: Cobra (already in use)
• Go testing: Go test + testify (already in use)

/cc @dev-team

[Delqhi]

v3.0.0–v3.2.0 release train (2026-06-12) makes significant progress:

• Module path migrated to github.com/OpenSIN-Code/SIN-Code (v3.0.0)
• Core agent loop, sessions, verify-gate, permission, mcpclient packages shipped in v3.1.0
• Hook engine + custom slash commands in v3.2.0

Still open: chat_cmd.go / session_cmd.go CLI binding — see new follow-up issue. Targeted for v3.3.0.

[Delqhi]

Status (2026-06-12, post-v3.5.0)

Priority: STRATEGIC — multi-quarter effort, not a single PR.

Current state — what v3.x already migrated

• v3.0.0: Go binary sin-code is now the primary distribution channel
• v3.1.0: agentloop, session, verify, permission, mcpclient are Go-native
• v3.2.0: hooks + commands (Go-native)
• v3.4.0: loopbuilder (DRY), provider_adapter (Go), lessons, autonomy, skillmgr
• v3.5.0: daemon, goal, swarm (in v3.6.0), bootstrap (in v3.6.0)
• 26 Go packages, race-clean, ≥70% coverage on core paths

Still Python-wrapped (left to migrate)

• src/sin_code_bundle/agent_engine/agent_loop.py: still has the legacy
  Python loop (deprecated; superseded by Go agentloop)
• The Python CLI sin (not sin-code) is the wrapper around Go binary
  and may stay as a thin shim
• WebUI-v2 (Next.js) is intentionally Python/JS — out of scope

Definition of done

• sin Python CLI removed entirely (Go binary is sin-code)
• src/sin_code_bundle/ deprecated, marked as legacy
• All new agent code lands in Go
• Tests/lint/docs updated

Cross-refs

• Sister-issue: nothing (this is a multi-quarter strategic push)
• AGENTS.md §6 (cmd/sin-code Go binary is primary)
• README.md feature list (Go-first)