Scanner group

Infrastructure configuration

Every scanner in this group reads a configuration file as plain text and runs regular expressions over it. A Dockerfile, a Kubernetes manifest, a Terraform file and a shell script are four different languages, but the scanner treats each as one string: pick the file by name or marker, match the rule, skip the placeholders, report a severity.

4 scanners4 SASTLow to Critical

How this group works

Four files, one shape. Each step adds a column: how the file is picked, what is searched for, what is skipped and what comes out.

Input file Picked by Rule over the text Finding DockerfileDocker scanner name in the Dockerfile listfile index, by name no line matches ^\s*USERwhole file, absence ruleguard: skipped if the path has "dev"whole file, absence rule Medium · conf 0.85Dockerfile runs as root deploy/app.yamlKubernetes scanner .yaml/.yml with apiVersion:plus 7 folder names on disk privileged\s*:\s*truesearched in the full file textguard: placeholders ${..} <..> CHANGE_MEsearched in the full file text Critical · conf 0.95Container runs privileged infra/main.tfIaC scanner extension .tf or .tfvarsno folder or name rule 0.0.0.0/0 + from_port 5432searched inside each ingress { }guard: ports 80 and 443 are allowedsearched inside each ingress { } High · conf 0.90SG open on port 5432 deploy.shShell script scanner extension .sh or .bashno shebang check curl ... | shsearched in the full file textguard: values with $ / your- are skippedsearched in the full file text High · conf 0.90curl piped to a shell Text goes in on the left and a finding comes out on the right. The next four steps fill in what happens between them. No YAML, HCL, Dockerfile or shell parser sits in between. A finding is a file path, a severity and a confidence.

1Four kinds of configuration file, four scanners, one habit. Each scanner takes the text of a file from the repository snapshot and nothing else: no running app, no credentials, no network.

2Discovery is by name. A Dockerfile by its file name, a Terraform file by its extension, a script by .sh or .bash. Kubernetes manifests have no fixed name, so the marker apiVersion: and seven folder names stand in.

3The rule is a regular expression over the text. Some look for a bad line, some for a bad line inside a block, and some for a good line that is missing. None of them builds a tree of the file first.

4Each rule has a guard. Placeholders, allowed ports, development paths and variable references are skipped so that a template or a public web port does not turn into a finding.

5A match becomes a finding with a fixed severity and a fixed confidence from the scanner's configuration. The finding names the file; the scanners in this group do not record a line number.

6That is the whole shape. It is cheap, it runs on every scan, quick or deep, and it cannot tell a development default from a production one. The per-scanner pages show where each guard sits and what each one misses.

Scanners in this group

FROM node:latestENV DB_PASSWORD=hunter2EXPOSE 5432

Docker

Six Dockerfile rules and three compose rules over one string: root, unpinned tags, database ports, ENV secrets, remote ADD, privileged mode.

SASTLowCriticaldocker-scanner.md
securityContext:privileged: truerunAsUser: 0

Kubernetes

Manifests found by apiVersion and folder name, seven regular expressions for dangerous settings, and a separate check for Helm values files.

SASTLowCriticalk8s-scanner.md
ingress {cidr = ["0.0.0.0/0"]from_port = 5432

IaC (Terraform)

Every .tf and .tfvars file: open security groups, wildcard IAM, secret defaults, public buckets, and the ports and thresholds that are allowed.

SASTLowCriticaliac-scanner.md
curl -fsSL $URL | shchmod 777 /appeval "$CMD"

Shell scripts

Eight text rules for .sh and .bash: hardcoded secrets, curl piped to a shell, eval, chmod 777, missing set -e, echoed secrets, curl -k.

SASTLowHighshell-script-scanner.md

At a glance

ScannerWhat it looks atWhat it reportsSeverityNeeds
Docker scannerDockerfiles (4 names) and compose files (6 names)Root, unpinned base, sensitive ports, ENV secrets, remote ADD, no HEALTHCHECK; weak password, privileged, published database portLow to CriticalRepository
Kubernetes scannerYAML with apiVersion:, plus 7 manifest folders; Helm values.yamlPrivileged, root, host namespaces, ALL capabilities, env secrets, image tag, LoadBalancer; Helm plaintext secretsLow to CriticalRepository (folder scan needs the checkout on disk)
IaC scanner.tf and .tfvarsOpen ingress, wildcard IAM, secret defaults, public S3, Secrets Manager recovery, ALB HTTP, ECS public IP, log retentionLow to CriticalRepository
Shell script scanner.sh and .bashHardcoded secrets and AWS account IDs, curl to shell, chmod, eval, missing set -e, echoed secrets, curl -kLow to HighRepository

Why this class matters

Why it matters

Configuration files decide what an attacker gets after the first foothold. A container that runs as root, a pod that is privileged, an IAM policy that grants everything and a script that runs fetched code each turn a small bug into a large one. They are also the cheapest class to find: the evidence is already in the repository, so no running system is needed.

Real-world breaches

Tesla (2018). An unsecured Kubernetes dashboard led to AWS credentials and cryptocurrency miners. Twitch (2021). An AWS misconfiguration contributed to the leak of its entire source code. Accenture (2017). Four public S3 buckets exposed API data, credentials and decryption keys. SolarWinds (2020). Build scripts that run unverified content are high-risk targets.