Judged in context
A wildcard role matters more when the service behind it takes untrusted input. Configuration is weighed against the application's deployment context, entry points, and trust boundaries, not scored in isolation.
IaC
AvailableCatch the misconfiguration before it ships.
The same agents that trace your application code review Terraform, CloudFormation, Kubernetes, Helm, Docker, and CI workflow files, and weigh every setting against what the application actually exposes.
- acme
- /billing-api
- /Vulnerabilities
Config 4Terraform 2Kubernetes 1Workflows 1Docker 0
| Severity | Finding |
|---|---|
| C9.3 | PR title interpolated into a workflow shell stepPipeline injection.github/workflows/preview.yml:24 |
| H8.2 | Role grants s3:* on every bucketIAMterraform/iam.tf:88 |
| H7.8 | Worker pod runs privileged with host PIDKubernetesk8s/worker.yaml:31 |
| M5.9 | Exports bucket allows public readStorageterraform/s3.tf:12 |
.github/workflows/preview.yml
| 20 | steps: | |
| 21 | - uses: actions/checkout@v4 | |
| 22 | - name: Label preview | |
| 23 | run: | | |
| 24 | ! echo "Preview: ${{ github.event.pull_request.title }}" |
Sourcepull_request_target
github.event.pull_request.title
Sinkpreview.yml:24
run: echo … (bash, with repo write token)
What it does
Capabilities.
- Terraform, OpenTofu, and HCL
- AWS CloudFormation, AWS CDK, Pulumi, and Azure Bicep and ARM templates
- Kubernetes manifests, Helm charts, and Kustomize overlays
- Dockerfiles, Containerfiles, and Compose files
- Ansible playbooks
- GitHub Actions, GitLab CI, and other pipeline definitions, including pipeline injection
- Over-permissive IAM, public storage, and missing encryption
- Privileged containers, insecure service accounts, and network policy gaps
- Plaintext secrets in configuration
- Repository-specific configuration paths added during scan setup
- Configuration changes reviewed in pull requests
How it works
From inventory to a verified upgrade.
- Step 1
Inventory
Find Terraform, CloudFormation, Kubernetes, Helm, Docker, and pipeline files anywhere in the repository.
- Step 2
Review
Check identity, storage, network, container, and pipeline settings.
- Step 3
Relate
Weigh each issue against the services and data it exposes.
- Step 4
Fix
Patch the configuration in a pull request and confirm on the next scan.
Why it matters
Built for decisions, not queues.
One finding format
Configuration findings carry the same file and line, CVSS vector, trace, and remediation guidance as code findings, in the same workspace and the same pull requests.
No rule pack to maintain
Review is done by the agents rather than a fixed rule set, so unusual layouts and new resource types do not wait on a rule update.
Pipelines are infrastructure
Workflow files get the same scrutiny as application code, starting with untrusted event data that reaches a shell step.
Continue the evaluation
Start with one repository
Bring us your hardest codebase.
We'll bring the proof.
Scope a first audit with our security engineers. You get findings with traces, reproduction evidence, and patches ready for review.
