If you discover a security vulnerability within SolGuard itself, please do not open a public issue.

Instead, email the repository maintainer directly via the contact listed on the GitHub profile linked in the README. We aim to acknowledge reports within 48 hours and provide a remediation timeline within 7 days.

SolGuard is designed to securely audit and deploy untrusted smart contract code. We treat every Pull Request as potentially malicious and architect accordingly.

Threat: A malicious foundry.toml, build script, or Solidity dependency could attempt arbitrary code execution, file exfiltration, or network egress during PR analysis.

Mitigation:

• All static analysis (slither) and compilation (forge build) execute inside an ephemeral Docker container (solguard-sandbox).
• The container has read-only access to the cloned repository and no access to host secrets, the Go server's memory, or the master wallet.
• Network access from the sandbox is restricted to package mirrors required for compilation.
• The container is destroyed after each run.
• The Go host process never executes untrusted code natively.

Threat: Leakage of the deployer's private key via logs, CI/CD environment variables, compromised host memory, or persisted disk state. A leaked deploy key on a live project = full treasury drain.

Mitigation: Ephemeral Key Architecture.

• A fresh ECDSA wallet is generated in-memory per deployment.
• The private key is immediately encrypted with AES-256-GCM using a master key loaded from the environment.
• The wallet is funded Just-In-Time with exactly the required gas (default: 0.01 ETH).
• Immediately after deployment, all remaining funds are swept back to the master cold wallet.
• The ephemeral key is zeroed from memory.
• The key never touches disk, never reaches GitHub Secrets, and lives for ~30 seconds end-to-end.

Residual risk: If the master wallet's private key is compromised (it must be available to the running Go process), an attacker could fund their own deploys. Mitigation: HSM/KMS integration is on the v2 roadmap.

Threat: Access tokens, GitHub PATs, AI API keys, and wallet private keys leaking into telemetry pipelines, log aggregators, or stack traces.

Mitigation:

• The Go backend implements a strict .Redacted() method on the configuration struct.
• All secrets are masked (ghp_...nt2M, gsk_...4F3a) before the log/slog JSON logger processes them.
• Configuration objects can be safely serialized into structured logs.
• Stack traces are filtered to drop frames containing secret material.

Threat: Proprietary or pre-release smart contract source code being transmitted to third-party LLM providers (Gemini, Groq) creates an IP-leak vector unacceptable for many enterprise / DAO treasury contexts.

Mitigation:

• The multi-model AI router supports Ollama as a drop-in provider.
• Local LLMs (deepseek-coder, codellama, etc.) can replace one or all cloud providers.
• In full air-gapped mode, no source code leaves the customer VPC.
• Consensus thresholds adapt automatically to the number of available providers.

Threat: Repudiation of past deployments; tampering with deployment history; inability to forensically reconstruct an incident.

Mitigation:

• Every deployment is persisted to a local SQLite database (solguard.db) with:
  • Commit SHA
  • Ephemeral wallet address
  • Deployed contract address
  • Funding transaction hash
  • Deployment transaction hash
  • Sweep transaction hash
  • Timestamp
• The on-chain transactions themselves serve as immutable secondary evidence, anchoring the local audit trail to the Ethereum blockchain.
• The SQLite database is intentionally not committed to source control to avoid leaking deployment metadata for closed-source projects.

Threat: A spoofed webhook payload could trick SolGuard into auditing or deploying attacker-controlled code.

Mitigation:

• All incoming webhooks are verified using HMAC-SHA256 against the WEBHOOK_SECRET environment variable.
• Requests with missing or invalid X-Hub-Signature-256 headers are rejected before any processing occurs.
• Replay attacks are mitigated by GitHub's delivery-ID tracking.

The following are not within SolGuard's threat model:

• A compromised master wallet key (operator responsibility — use an HSM or hardware wallet)
• Compromise of the host operating system running the Go binary
• Vulnerabilities in upstream dependencies (Foundry, Slither, Go stdlib) — these are tracked via dependabot
• Social engineering of repository maintainers

If you self-host SolGuard:

1. Run on a dedicated VM with no other workloads.
2. Rotate the master wallet quarterly, and especially after any operator turnover.
3. Use a separate testnet master wallet during development.
4. Set conservative funding amounts in DEPLOYMENT_FUNDING_AMOUNT — only what's needed for one contract deploy.
5. Monitor the audit trail weekly. Unexpected deployments = immediate incident response.
6. Keep the sandbox image updated with the latest Foundry and Slither versions.
7. Review audit-policy.yaml before each significant release — your gate is only as strict as your policy.