DepWarden's free Go SAST scanner checks Go source code against 39 security rules. Every rule maps to a CWE and the findings span 6 OWASP Top 10 categories, and every finding comes with an explanation, a fix and a before-and-after example. Paste a file, upload a zip or connect a repository: no account, and the results stay in a private, session-isolated workspace.
Go is a common choice for APIs, cloud services and command-line tools. It is memory-safe, but injection through os/exec, SQL built with string formatting, weak randomness and disabled TLS verification are still easy to write.
39 rules cover 25 distinct weakness types (8 critical, 18 high, 8 medium and 5 low severity).
| What it checks | Rules | Examples |
|---|---|---|
| Weak cryptography | 17 | MD5 used for password hashing; Null or no-op cipher used; TLS certificate validation disabled — trust all certs |
| Insecure configuration | 4 | CORS: Access-Control-Allow-Credentials with wildcard origin; GraphQL introspection enabled in production; Rate limiter trusts X-Forwarded-For from untrusted source |
| Hardcoded secrets | 3 | Hardcoded symmetric encryption key; JWT signed with weak or hardcoded secret; API key or token in URL query string |
| Injection (SQL, command, code) | 3 | OS command injection; Server-side template injection; SQL injection via concatenation |
| Authentication and sessions | 2 | JWT none algorithm accepted; Token or secret compared with non-constant-time equality |
| Privacy and data leaks | 2 | Sensitive data written to application log; fmt.Println / fmt.Printf used in production service code |
| Reliability and error handling | 2 | panic() in request handler or library function; Error return value ignored |
| Server-side request forgery | 2 | SSRF — HTTP request to user-controlled URL; Server-side request forgery (SSRF) |
| Access control | 1 | Open redirect via http.Redirect |
| Denial of service | 1 | Potential goroutine leak (unbuffered channel) |
| Open redirect | 1 | Open redirect to user-controlled URL |
| Path traversal | 1 | Path traversal in file operations |
exec.Command builds a command from untrusted input.
Vulnerable:
exec.Command("sh", "-c", "convert "+filename)Fixed:
exec.Command("convert", filename, "out.png")Pass arguments as separate parameters, validate against an allowlist, and never invoke a shell with interpolated input.
A file path is constructed from untrusted request input, enabling traversal outside the intended directory.
Vulnerable:
data, _ := os.ReadFile(filepath.Join(baseDir, r.URL.Query().Get("file")))Fixed:
clean := filepath.Clean(filepath.Join(baseDir, r.URL.Query().Get("file")))
if !strings.HasPrefix(clean, baseDir) { http.Error(w, "forbidden", 403); return }
data, _ := os.ReadFile(clean)Use filepath.Clean() + assert the result starts within an allowed base with strings.HasPrefix(clean, base). Reject paths containing '..'.
An HTTP request targets a URL derived from untrusted input.
Vulnerable:
resp, _ := http.Get(r.URL.Query().Get("url"))Fixed:
u, _ := url.Parse(r.URL.Query().Get("url"))
if !isAllowedHost(u.Hostname()) { http.Error(w, "forbidden", 403); return }
resp, _ := http.Get(u.String())Allowlist destination hosts/schemes and block internal IP ranges.
- uses: Rushabh5000/depwarden-action@v1
with:
sast-dir: src
sast-fail-on: high
env:
APP_API_KEY: ${{ secrets.APP_API_KEY }}DepWarden's SAST engine uses pattern rules and taint-aware rules that require untrusted input to reach a dangerous call. It is not a full cross-file dataflow engine, so a bug that only appears when data crosses several files can be missed, and every static analyser reports some false positives. Treat findings as leads: review them, fix the real ones and suppress the rest with a written reason. SAST covers the code you write; for the packages you import, run software composition analysis too.
Yes. DepWarden's Go scanner is free in the browser with no account: paste code, upload a zip or connect a repository. Running SAST from CI through an API key needs a plan that includes SAST.
.go. Configuration and secret-bearing files such as .env and key files are also checked for hardcoded credentials, whatever language the project uses.
Each finding names the weakness (CWE), explains why the code is risky, shows a vulnerable and a fixed version of the pattern, and gives the remediation. Fix the code, then scan again to confirm the finding is gone.
Other languages: Python, Java, JavaScript and TypeScript, PHP, C#, Ruby, Kotlin, Swift, and secret scanning. Compare the options in free SAST tools compared, or start with what is SAST and SAST vs SCA.