Instruments Go toolchains to log runtime operations (reflect, unsafe). Modifies Go stdlib source during compilation to inject logging calls.

What This Tool Does:

• Modifies Go stdlib source during compilation
• Adds logging calls to instrumented functions (no behavior changes)
• Writes logs to files with runtime operation details
• Injects wrapper code for user/dependency code

What This Tool Does NOT Do:

• Modify program behavior or logic
• Bypass security checks or validations
• Introduce vulnerabilities or backdoors
• Network access or data exfiltration
• Modify user code (only stdlib and instrumentation wrappers)

Risk: Modified Go toolchain could be compromised or introduce vulnerabilities.

Mitigations: Only adds logging, all modifications are transparent (AST injection), no security checks bypassed, instrumentation is additive only.

Recommendations: Use verified Go source downloads, review instrumentation changes before deployment, test instrumented toolchain before production use.

Risk: Logs contain memory addresses, file paths, function names, and argument values.

Current Mitigations: Logs written to controlled file path (INSTRUMENTATION_LOG_PATH env var), file permissions 0600 (owner-only), no network transmission, deduplication prevents log spam.

Recommendations: Use secure directory, implement log rotation, consider sanitizing sensitive argument values, restrict log file access to authorized personnel.

Risk: File operations could expose sensitive paths.

Current Behavior: Reads Go source files (read-only), writes instrumentation logs (append-only), creates temporary directories during build.

Recommendations: Run instrumentation in isolated build environment, use dedicated build user with minimal permissions, audit file paths in logs before sharing.

Risk: Using unsafe package for FormatValue could cause issues.

Mitigations: Only reads internal fields (reflect.Value.ptr), never writes, no pointer arithmetic beyond struct field access, used only for logging.

Recommendations: Test across Go versions (layout could change), add bounds checking if struct layout changes.

Risk: Build-time instrumentation could be hijacked via malicious Go source, compromised build environment, or supply chain attacks.

Mitigations: Reads from verified Go source only, no code execution during instrumentation, AST transformations are deterministic.

Recommendations: Verify Go source integrity (checksums), use isolated build containers, audit instrumentation code regularly.

Current State: File permissions 0600 (owner-only), appends to existing file if present, no encryption or access controls.

What's Logged: Operation names, argument values (strings, numbers, memory addresses), caller information (function names, file paths, line numbers), receiver addresses.

Sensitive Data Concerns: String arguments could contain secrets, file paths reveal directory structure, memory addresses could aid attacks (ASLR bypass).

Recommendations: Consider truncating or hashing sensitive string arguments, strip user home directories from file paths, consider obfuscating memory addresses, restrict log file access to security team only.

For Internal Use:

1. File Permissions: chmod 600 /path/to/instrumentation.log
2. Directory Permissions: mkdir -p /var/log/go-instrumentation && chmod 700 /var/log/go-instrumentation
3. Environment Variables: export INSTRUMENTATION_LOG_PATH=/var/log/go-instrumentation/app.log
4. Build Environment: Use isolated build containers, verify Go source integrity, audit instrumentation changes
5. Log Handling: Implement log rotation, encrypt logs at rest (if required), monitor log file access

Security Checklist:

• Log file permissions set to 0600 (owner-only)
• Log directory has restricted access (700 or ACLs)
• Log files stored in secure location (not /tmp)
• Build process runs in isolated environment
• Go source verified before instrumentation
• Log rotation implemented
• Access to logs restricted to authorized personnel
• Sensitive data sanitization considered (if needed)
• Regular security audits of instrumentation code

Assumed Threat Level: Low (Internal Use)

Assumptions: Build environment is trusted, Go source is verified, logs remain internal, no external network access.

If Deploying Externally: Add encryption for logs at rest, implement access controls, sanitize sensitive data, add audit logging for log access.

This tool is safe for internal use with proper file permissions and access controls. Primary risks:

1. Information disclosure via log files (mitigated with proper permissions)
2. Build process security (mitigated with isolated builds)
3. Memory address exposure (low risk for internal use)

Key Security Controls:

• Observation-only (no behavior changes)
• No network access
• Transparent modifications
• Log file access control (requires configuration)
• File permissions (0600 default)

Recommendation: Deploy with 0600 file permissions and restricted directory access. For production use, consider adding log sanitization and encryption.