Infrastructure and server config security

Why this area matters

Security misconfiguration is OWASP Top 10 A05 and one of the most common root causes in breach reports: SSH open to root with passwords, debug mode left on, admin consoles exposed, TLS verification disabled. When infrastructure is code, every one of those decisions is visible in a diff.

IaC scanners like Trivy and Checkov are thorough but literal — they flag a debug flag in a local-dev compose file the same as in production, and they don't know which values your team overrides at deploy time. The infrastructure review agent reads the context: which environment the file is for, whether a value is a placeholder, and what the safe default should be.

What goes wrong in real applications

• Remote access misconfiguration

  Root login or password authentication over SSH, or admin interfaces bound to public addresses, turns a single leaked or guessed password into full host control.

• Debug and development settings in production

  Debug modes, verbose error pages and test endpoints leak internals and sometimes allow code evaluation. They are often enabled for a quick fix and never turned off.

• Disabled transport security

  TLS verification switched off or cleartext listeners left enabled let anyone on the path read or modify traffic between services.

• Insecure defaults left unchanged

  Default credentials, permissive CORS and wide-open file permissions in templates are copied into every environment built from them.

Sample: the risky pattern and the fix

- name: Configure sshd
  ansible.builtin.lineinfile:
    path: /etc/ssh/sshd_config
    regexp: "{{ item.re }}"
    line: "{{ item.line }}"
  loop:
    - { re: "^PermitRootLogin", line: "PermitRootLogin yes" }
    - { re: "^PasswordAuthentication", line: "PasswordAuthentication yes" }

- name: Configure sshd
  ansible.builtin.lineinfile:
    path: /etc/ssh/sshd_config
    regexp: "{{ item.re }}"
    line: "{{ item.line }}"
    validate: /usr/sbin/sshd -t -f %s
  loop:
    - { re: "^PermitRootLogin", line: "PermitRootLogin no" }
    - { re: "^PasswordAuthentication", line: "PasswordAuthentication no" }
    - { re: "^MaxAuthTries", line: "MaxAuthTries 3" }

The role lets anyone log in as root with a password, so one weak or reused password gives full control of every host it runs on. The fix requires key-based login as a named user, limits retries and validates the config before applying it, so a typo can't lock you out.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• Terraform, Ansible, Helm, CloudFormation and docker-compose files (Trivy config / Checkov, then agent review)
• Server config committed to the repo: sshd_config, nginx and Apache configs, systemd units
• Debug flags, verbose errors, permissive CORS and disabled TLS verification
• Default or placeholder credentials in templates and environment files
• Whether a file targets local development, CI or production (the main false-positive signal)

Scope and limits

• It reviews the definitions in your repository, not running hosts — it doesn't log in to servers, run benchmarks or scan ports.
• Settings applied by hand or by tooling outside the repository won't be seen, and drift between code and reality isn't detected.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Infrastructure & IaC — Reviews Terraform, Helm, Ansible and server config for insecure defaults and exposure.
• Privilege & file permissions — Checks file permissions, temp files, symlinks and unnecessary root.
• Network & transport security — Checks that data in transit is encrypted and certificates are actually verified.