Skip to content

SAST (Application Security)

Overview

SAST in Sttor Code Analyzes Source Code to Detect:

  • insecure patterns (e.g., injection, weak crypto usage, unsafe deserialization)
  • risky data flows (e.g., user input → sensitive sink)
  • security misuses of common libraries and frameworks.

Each SAST finding is tied to a rule ID (example: CODE-0001, CODE-0023, etc.), and typically includes

  • Rule name + category,
  • Severity,
  • File path + line/region,
  • Short explanation + remediation guidance,
  • (when available) AI AutoFix patch suggestion.

Rule IDs in documentation (how it should appear)

In the docs, rules should be referenced in two places

  1. Inline inside language pages (as examples):

“This is detected by CODE-00XX…”

  1. Dedicated Rule Catalog pages (canonical): Sttor Code → Rule Catalog → SAST Rules → language

Each rule page should contain: description, risk, code examples, fix, false-positive guidance, tags, and mappings (future: compliance control mapping).

Java

Java SAST focuses on secure usage patterns common in enterprise backends: What it commonly detects:

  • Injection risks (SQL/LDAP/command), unsafe string concatenation into queries/exec
  • Insecure deserialization
  • SSRF patterns in URL fetch/HTTP clients
  • Weak crypto primitives / insecure modes
  • Insecure file handling and path traversal patterns

Recommended doc additions:

  • “Supported build layouts” (Maven/Gradle typical structures)
  • “How to interpret traces” (source → sink)
  • “Common false positives” and suppression guidance

Python

Python SAST is tuned for web services, data processing jobs, and scripts: What it commonly detects:

  • Command injection (subprocess, shell usage)
  • SSRF in requests/URL fetch
  • Insecure pickle/deserialization usage
  • Weak crypto/hard-coded secrets patterns (when they present as code issues)
  • Unsafe YAML loading and insecure parsing defaults

Recommended doc additions:

  • Security tips for Django/Flask/FastAPI usage patterns
  • Guidance for handling findings in test code vs production code

Go

Go SAST focuses on secure standard library usage and common server patterns: What it commonly detects:

  • SSRF patterns in HTTP clients
  • Command execution risks (os/exec)
  • Insecure TLS settings / skipping verification
  • Path traversal / unsafe file operations
  • Randomness misuse where cryptographic randomness is required

Recommended doc additions:

  • “Go modules and repo layout considerations”
  • “Concurrency-related security footguns” (where relevant)

Rust

Rust SAST targets unsafe patterns that can bypass Rust’s usual safety guarantees: What it commonly detects:

  • Dangerous unsafe usage patterns
  • Deserialization/parser misuse leading to security issues
  • Command execution and file system risks
  • Misconfigurations of TLS and crypto crates

Recommended doc additions:

  • “How we treat unsafe blocks” (risk-based explanation)
  • “When a finding is security vs reliability” (triage guidance)

JavaScript / TypeScript

JS/TS SAST covers frontend + Node.js backends: What it commonly detects:

  • XSS patterns (DOM sinks, unsafe rendering)
  • Injection and command execution on Node
  • SSRF patterns in server-side fetchers
  • Insecure JWT usage / weak validation patterns (where applicable)
  • Dangerous eval-like constructs and prototype pollution sinks

Recommended doc additions:

  • Separate guidance for “Browser” vs “Node.js”
  • Framework hints (Express/Nest/Next, etc.)

Other languages Sttor Code supports 30+ programming languages where rules live in the Rule Catalog,