rules-vlang

RISK: C.malloc bypasses V's memory safety and requires manual free — leaks and double-frees are easy. FIX: use V's built-in allocators (arrays, maps) or the `unsafe { }` block with a documented safety invariant.

RISK: Calling C.free() manually on V-allocated memory causes double-free or use-after-free undefined behaviour (CWE-415/CWE-416). FIX: let V's garbage collector manage V-allocated objects; only call C.free() on memory explicitly returned by a C function that allocates it.

RISK: Hardcoded credentials in V source are committed to version control and exposed in compiled binaries (CWE-798). FIX: read secrets from environment variables (os.getenv('SECRET_NAME')), a config file outside the repo, or a secrets manager.

RISK: Interpolating variables directly into os.execute()/os.system()/os.exec() is OS command injection (CWE-78) — any user-controlled value can escape the intended command. FIX: build argument lists with os.Process{ args: [...] } so each argument is a separate element and the shell cannot interpret metacharacters.

RISK: voidptr/charptr casts and raw pointer derefs in V bypass the type system and can cause memory corruption or information disclosure. FIX: use V's typed references and let the compiler track ownership; wrap C API calls behind a safe V function that validates the pointer.

RISK: V's `unsafe { }` block disables bounds-checking and nil-pointer protection — it is the primary source of memory corruption bugs in V programs (CWE-119/CWE-476). FIX: restrict unsafe blocks to narrow FFI wrappers, document the invariants that make them safe, and keep them out of application logic.

RISK: Disabling TLS certificate verification in V HTTP/net clients allows man-in-the-middle attacks — the server's identity is not authenticated (CWE-295). FIX: use the default TLS verification path; if you need a custom CA, pass the certificate file to the client configuration instead of skipping verification.