go-webgpu is currently in initial release (v0.x.x). We provide security updates for the following versions:

Future stable releases (v1.0+) will follow semantic versioning with LTS support.

We take security seriously. If you discover a security vulnerability in go-webgpu, please report it responsibly.

DO NOT open a public GitHub issue for security vulnerabilities.

Instead, please report security issues by:

1. Private Security Advisory (preferred): https://github.com/go-webgpu/webgpu/security/advisories/new

2. Email to maintainers: Create a private GitHub issue or contact via discussions

Please include the following information in your report:

• Description of the vulnerability
• Steps to reproduce the issue
• Affected versions (which versions are impacted)
• Potential impact (memory corruption, crashes, GPU resource leaks, etc.)
• Suggested fix (if you have one)
• Your contact information (for follow-up questions)

• Initial Response: Within 48-72 hours
• Triage & Assessment: Within 1 week
• Fix & Disclosure: Coordinated with reporter

We aim to:

1. Acknowledge receipt within 72 hours
2. Provide an initial assessment within 1 week
3. Work with you on a coordinated disclosure timeline
4. Credit you in the security advisory (unless you prefer to remain anonymous)

go-webgpu provides Go bindings to wgpu-native, which interfaces with GPU hardware. This introduces security considerations that users should be aware of.

Risk: go-webgpu uses FFI (Foreign Function Interface) to call native wgpu library functions.

Attack Vectors:

• Incorrect pointer handling in FFI calls
• Memory corruption from mismatched struct layouts
• Use-after-free from incorrect resource lifetime management

Mitigation:

• Careful struct layout matching with C headers
• Explicit resource cleanup with Release/Drop methods
• Extensive testing on all platforms
• golangci-lint with FFI-aware configuration

User Recommendations:

// Always release GPU resources when donedevice:=adapter.CreateDevice(nil)
deferdevice.Release()
buffer:=device.CreateBuffer(&wgpu.BufferDescriptor{...})
deferbuffer.Release()

Risk: Improper resource management can exhaust GPU memory or cause driver crashes.

Attack Vectors:

• Creating buffers/textures without releasing them
• Infinite loops in compute shaders
• Excessive command buffer submissions

Mitigation:

• Explicit resource lifetime management
• wgpu-native's built-in validation layer
• Device lost callbacks for error recovery

User Best Practices:

// Enable validation in developmentinstance:=wgpu.CreateInstance(nil)
// Use device lost callbackdevice:=adapter.CreateDevice(&wgpu.DeviceDescriptor{
DeviceLostCallback: func(reason wgpu.DeviceLostReason, messagestring) {
log.Printf("Device lost: %v - %s", reason, message)
},
})
// Always release resourcesdefertexture.Release()
deferbuffer.Release()
deferpipeline.Release()

Risk: WGSL shaders execute on GPU and could potentially cause issues.

Attack Vectors:

• Malformed WGSL causing driver crashes
• Infinite loops in shaders (GPU hang)
• Out-of-bounds buffer access in shaders

Mitigation:

• wgpu-native validates all WGSL shaders
• WebGPU spec mandates bounds checking
• No access to system resources from shaders
• Shader compilation errors are returned to application

User Recommendations:

// Always check shader compilation errorsshaderModule, err:=device.CreateShaderModule(&wgpu.ShaderModuleDescriptor{
WGSLDescriptor: &wgpu.ShaderModuleWGSLDescriptor{
Code: wgslSource,
},
})
iferr!=nil {
log.Printf("Shader compilation failed: %v", err)
returnerr
}

Risk: Mapped buffers provide direct memory access.

Attack Vectors:

• Reading unmapped buffer memory
• Writing beyond buffer bounds
• Using mapped pointer after unmap

Mitigation:

• WebGPU spec enforces mapping state machine
• Bounds checking in GetMappedRange
• wgpu-native validation

User Best Practices:

// Wait for map to complete before accessingbuffer.MapAsync(wgpu.MapModeRead, 0, size, func(status wgpu.BufferMapAsyncStatus) {
ifstatus!=wgpu.BufferMapAsyncStatusSuccess {
return
}
// Only access after successful mapdata:=buffer.GetMappedRange(0, size)
// ... use data ...buffer.Unmap()
// Don't use 'data' after Unmap!
})

Risk: Surface creation requires platform-specific window handles.

Attack Vectors:

• Invalid window handle causing crashes
• Surface use after window destruction
• Cross-platform handle confusion

Mitigation:

• Platform-specific surface creation functions
• Validation of window handles where possible
• Clear documentation of lifetime requirements

User Recommendations:

// Ensure window is valid before creating surfacesurface, err:=instance.CreateSurface(&wgpu.SurfaceDescriptor{
WindowsHWND: &wgpu.SurfaceDescriptorFromWindowsHWND{
Hwnd: hwnd, // Must be valid HWND
},
})
iferr!=nil {
returnerr
}
// Release surface before destroying windowsurface.Release()
// Then destroy window

Risk: go-webgpu loads wgpu-native as a dynamic library.

Attack Vectors:

• DLL hijacking (malicious library in search path)
• Library version mismatch
• Missing library dependencies

Mitigation:

• Explicit library paths recommended
• Version checking at load time
• Clear error messages for missing libraries

User Best Practices:

// Set explicit library path if neededos.Setenv("WGPU_NATIVE_PATH", "/path/to/wgpu_native.dll")
// Or place library in application directory

Always release GPU resources:

device:=adapter.CreateDevice(nil)
deferdevice.Release()
// Create resourcesbuffer:= device.CreateBuffer(...)
texture:= device.CreateTexture(...)
pipeline:= device.CreateRenderPipeline(...)
// Release in reverse orderdeferpipeline.Release()
defertexture.Release()
deferbuffer.Release()

Always check errors:

// Check adapter requestadapter, err:= instance.RequestAdapter(...)
iferr!=nil {
returnfmt.Errorf("failed to get adapter: %w", err)
}
// Check device creationdevice, err:= adapter.CreateDevice(...)
iferr!=nil {
returnfmt.Errorf("failed to create device: %w", err)
}
// Check shader compilationmodule, err:= device.CreateShaderModule(...)
iferr!=nil {
returnfmt.Errorf("shader error: %w", err)
}

Use error scopes for detailed GPU error information:

device.PushErrorScope(wgpu.ErrorFilterValidation)
// ... GPU operations ...device.PopErrorScope(func(err wgpu.Error) {
iferr!=nil {
log.Printf("GPU validation error: %v", err)
}
})

Status: Dependency on upstream security.

Risk Level: Low

Description: go-webgpu's security depends on wgpu-native. We track wgpu-native releases and update accordingly.

Status: Careful implementation with testing.

Risk Level: Medium

Description: FFI calls require careful pointer and memory management. We maintain extensive tests and linter checks.

Status: Platform-specific code paths tested.

Risk Level: Low

Description: Different platforms (Windows, Linux, macOS) have different loader and surface implementations.

go-webgpu dependencies:

Monitoring:

• Dependabot enabled for Go dependencies
• Track wgpu-native releases for security updates

• Unit tests for all public APIs
• Platform-specific tests (Windows, Linux, macOS)
• Memory leak detection in examples
• golangci-lint with security linters

• Fuzz testing for FFI boundaries
• Integration tests with various GPU drivers
• Security-focused code review

Initial release - No security issues reported yet.

• GitHub Security Advisory: https://github.com/go-webgpu/webgpu/security/advisories/new
• Public Issues (for non-sensitive bugs): https://github.com/go-webgpu/webgpu/issues
• Discussions: https://github.com/go-webgpu/webgpu/discussions

go-webgpu does not currently have a bug bounty program. We rely on responsible disclosure from the security community.

If you report a valid security vulnerability:

• Public credit in security advisory (if desired)
• Acknowledgment in CHANGELOG
• Our gratitude and recognition in README

Thank you for helping keep go-webgpu secure!

Security is a journey, not a destination. We continuously improve our security posture with each release.