Why Infrastructure Security Scanning Matters

Infrastructure configuration is where most preventable security incidents begin. Misconfigured S3 buckets, open database ports, missing security headers, privileged Kubernetes containers, hardcoded credentials in Terraform — these are not exotic attack vectors. They are the default settings developers leave in place because no one caught them before deployment. Infrastructure security scanners catch these misconfigurations before they reach production, at the point where they are cheapest to fix.

The scanners on this page work differently from SaaS security platforms: they run entirely in your browser, require no signup, and send nothing to external servers. You paste your config file or enter a URL, and get an A–F grade with specific, actionable findings. Each finding links to the configuration fix, not just the problem description.

Types of Infrastructure Security Issues These Scanners Catch

Terraform and IaC Misconfigurations

Terraform is the dominant IaC tool across AWS, GCP, and Azure deployments. Common misconfigurations in .tf files include: unrestricted ingress rules (SSH/RDP/database ports open to 0.0.0.0/0), S3 buckets without block public access settings, RDS instances without encryption at rest or deletion protection, IAM roles with * permissions, and hardcoded credentials that end up in version control. The Terraform Security Scanner checks for all of these and returns remediation snippets.

Kubernetes YAML Misconfigurations

Kubernetes security is a layered problem. The most common misconfigurations found in Kubernetes manifests are: containers running as root (runAsRoot: true or missing securityContext), containers with privileged: true, missing resource limits (which allow container breakout through resource exhaustion), images pinned to :latest (no reproducibility, no integrity verification), and missing network policies that leave pod-to-pod communication unrestricted. The Kubernetes YAML Security Linter catches these in your raw manifest files.

Docker Compose Security

Docker Compose files introduce security risks that differ from Kubernetes. The most common: privileged containers that can escape to the host, volumes mounted from sensitive host paths (/etc/passwd, Docker socket), missing user directives that leave containers running as root, exposed ports bound to 0.0.0.0 instead of 127.0.0.1, and missing resource constraints that allow denial-of-service through runaway containers. The Docker Compose Security Checker audits all of these from a pasted docker-compose.yml.

GitHub Actions Supply Chain Risks

CI/CD pipelines have become a primary attack surface. SolarWinds, Codecov, and ua-parser-js were all supply chain attacks that started in build pipelines or third-party package publishers. In GitHub Actions, the specific risks are: using unpinned action versions (uses: actions/checkout@v3 instead of a commit SHA), using third-party actions with broad repository permissions, and storing secrets in environment variables that child processes can read. The GitHub Actions Security Checker audits your workflow YAML for these patterns.

HTTP Security Headers

Missing security headers are one of the most pervasive and easily-fixed web vulnerabilities. A missing Content-Security-Policy header enables XSS attacks. A missing Strict-Transport-Security header means browsers may connect over HTTP. Missing X-Frame-Options enables clickjacking. Missing Referrer-Policy leaks sensitive URL parameters to third parties. The HTTP Security Headers Analyzer checks your URL for 12 security headers and returns the exact Nginx/Apache configuration snippets needed to fix each gap.

How to Use These Scanners in Your Workflow

1. Pre-deployment audit. Before any infrastructure change reaches production, paste the relevant config file into the appropriate scanner. Treat scanner findings as blocking issues unless there is a documented exception.
2. CI/CD integration. For Terraform and Kubernetes workflows, incorporate scanning tools like tfsec or Checkov (which use similar rule sets) into your pipeline. These scanners are the browser-friendly equivalent for one-off checks.
3. New repository onboarding. When a new service or repository is created, run its configuration files through all relevant scanners immediately to establish a clean baseline.
4. Dependency scanner alongside security scanner. Infrastructure security and dependency health are complementary. An up-to-date codebase on a misconfigured host is still vulnerable. Use both the dependency health checkers and these security scanners as a combined audit pass.
5. Fix-then-verify cycle. After addressing scanner findings, re-scan to confirm the fix worked as expected. Some Nginx header configurations have syntax-specific requirements that only manifest when tested against a live endpoint.

Infrastructure Security Glossary

Privilege escalation: When a process or container gains higher permissions than it should have, often by running as root or with the privileged flag in Kubernetes/Docker.

Supply chain attack: An attack that compromises a software artifact (package, CI action, container image) that is then distributed to downstream users who trust the artifact.

Least privilege: The security principle that every process, user, or service should have exactly the permissions it needs — no more. IAM roles with * permissions violate this principle.

Secret sprawl: Credentials and API keys that appear in multiple places (version control, environment variables, config files) beyond the single secret manager they should live in.

Misconfiguration drift: The gradual accumulation of configuration deviations from a known-good state, often introduced during incident response or urgent deployments without proper review.

Frequently Asked Questions

Do these scanners send my config files anywhere?
No. All analysis runs client-side in your browser using JavaScript. Your .tf files, YAML manifests, and docker-compose.yml files are parsed locally and never transmitted to any external server.

Are these scanners a replacement for Snyk, Checkov, or tfsec?
No — they are a complement. Production security pipelines should use automated tools integrated into CI/CD. These scanners are designed for quick one-off audits, onboarding checks, and teams who need a fast sanity check without setting up a full toolchain.

How do the scanners determine the severity of findings?
Each finding is categorised as Critical, High, Medium, or Low based on the potential impact if exploited. The overall A–F grade reflects the weighted combination of all findings: a single Critical finding limits the maximum grade to C; a High finding limits it to B.

Can I scan private infrastructure configs safely?
Yes. Since all processing is client-side, you can safely paste production Terraform, Kubernetes, and Docker Compose files without exposing them to third-party services. No data leaves your browser.

How current are the security rules?
The rule sets are maintained against current CIS Benchmarks, NIST SP 800-190 (container security), and community-maintained rulesets from the tfsec and Checkov projects. Rules are updated periodically to reflect new attack patterns and configuration risks.