The different types
of code security scanners.

SAST — Static Application Security Testing

What it is: Analyses source code, bytecode, or binaries without executing the application. Looks for patterns that indicate vulnerabilities.

What it finds: Injection flaws (SQL, command, XPath), weak cryptography, hardcoded credentials, insecure deserialization, missing input validation, dangerous function calls.

What it misses: Runtime-only vulnerabilities (race conditions, business logic flaws), configuration issues, third-party component vulnerabilities, anything that requires execution.

Best for: Developer feedback in IDE and CI. The widest-coverage, lowest-cost scanner. Add first.

Examples: Semgrep, CodeQL, Bandit, ESLint Security, SonarQube, AquilaX SAST.

DAST — Dynamic Application Security Testing

What it is: Attacks a running application from the outside, like an attacker would. Sends crafted HTTP requests and analyses responses for vulnerability indicators.

What it finds: XSS (including DOM-based), authentication bypass, session management flaws, SSRF, injection (from the black-box perspective), security misconfiguration visible at the HTTP level, insecure redirect handling.

What it misses: Vulnerabilities that don't produce visible HTTP responses, code-level issues, dependency CVEs, infrastructure misconfigurations.

Best for: Staging environment testing. Catches what SAST misses by testing the actual running behaviour.

Examples: OWASP ZAP, Burp Suite, Nuclei, AquilaX DAST.

IAST — Interactive Application Security Testing

What it is: Instruments the running application with a security agent that monitors execution in real time — like DAST from inside the application.

What it finds: Taint flows that reach dangerous sinks during actual execution, meaning no false positives from unreachable code paths. High-confidence findings.

What it misses: Vulnerabilities in code paths not exercised by tests. Coverage depends entirely on test coverage.

Best for: High-accuracy runtime testing in QA environments where test coverage is good. Not suitable for early-stage CI feedback.

Examples: Contrast Security, Seeker, HCL AppScan.

SCA — Software Composition Analysis

What it is: Analyses your application's third-party dependencies (open source libraries) for known vulnerabilities (CVEs), licence compliance issues, and supply chain risks.

What it finds: CVEs in direct and transitive dependencies, GPL/AGPL licence violations, outdated packages, typosquatting packages.

What it misses: Vulnerabilities in your own code, vendored code not tracked in manifests, runtime behaviour.

Best for: Dependency management and compliance. Add immediately after SAST — covers a completely different attack surface.

Examples: Grype, Trivy, Snyk, npm audit, pip-audit, AquilaX SCA.

Secrets scanning

What it is: Detects credentials, API keys, tokens, private keys, and other sensitive values in source code, git history, and configuration files.

What it finds: AWS keys, GitHub tokens, database passwords, private SSH/TLS keys, JWT signing secrets, service account credentials — matched against 500+ known formats.

What it misses: Custom internal secret formats it has no pattern for, secrets stored in environment variables at runtime (not in code).

Best for: Run in IDE, pre-commit, AND CI. Non-negotiable — a leaked secret is an immediate incident.

Examples: Gitleaks, TruffleHog, detect-secrets, GitHub Secret Scanning, AquilaX Secrets.

IaC scanning

What it is: Static analysis for infrastructure definition files (Terraform, CloudFormation, Kubernetes manifests, Dockerfiles, Helm charts) to detect security misconfigurations before they are applied.

What it finds: Overly permissive IAM policies, unencrypted storage, publicly accessible resources, containers running as root, missing security controls.

What it misses: Runtime cloud misconfigurations made via console (not in code), dynamic Terraform values resolved at apply time.

Best for: Any team using infrastructure as code. Add to CI alongside SAST.

Examples: Checkov, tfsec, Trivy, KICS, AquilaX IaC.

Container image scanning

What it is: Scans Docker/OCI container images for OS package vulnerabilities, misconfigurations, and malware embedded in image layers.

What it finds: CVEs in OS packages (apt, rpm), application dependency CVEs baked into the image, Dockerfile misconfigurations, malicious packages.

What it misses: Runtime container behaviour, network policies, admission controller configuration.

Best for: Any team shipping containerised applications. Scan images before they are pushed to a registry.

Examples: Trivy, Grype, Docker Scout, Clair, AquilaX container scanner.

Malware scanning

What it is: Analyses code and binaries for malicious patterns, supply chain compromises, and obfuscated payloads. More specialised than general SAST.

What it finds: Known malware signatures, obfuscated code patterns (base64-encoded eval chains), supply chain backdoors in dependencies, typosquatted packages with malicious payloads.

Best for: High-risk supply chain scenarios, scanning third-party packages before onboarding.

Examples: YARA, ClamAV, Trivy (malware), AquilaX malware scanner.

Which scanners to add and in what order

Phase 1 — Developer feedback (week 1)
  ├── SAST in IDE (real-time feedback)
  ├── Secrets scanning in IDE + pre-commit hook
  └── SAST in CI pipeline

Phase 2 — Supply chain (week 2–3)
  ├── SCA in CI (dependency CVEs)
  └── Container image scanning in CI

Phase 3 — Infrastructure (week 3–4)
  └── IaC scanning in CI (Terraform/K8s/Dockerfiles)

Phase 4 — Runtime (month 2+)
  ├── DAST against staging environment
  └── IAST in QA environment (optional, high effort)