Typical scanner output
- Separate findings per file with no proven connection
- "You have OIDC" and "you have a secret mount" listed independently
- Hard to prioritize which paths an attacker can actually walk
Trust chain detection · live sample · no sign-in
Proven trust chains from CI to runtime
Most scanners list findings in isolation. misconfigs builds a resource graph across your repo and proves multi-hop paths — GitHub OIDC to IAM, Secrets Manager to Kubernetes pods — with graph-linked evidence, not guesswork.
Free tier · Google sign-in · demo scans don't use your quota
4+ hops
CI → IAM → secrets → pod
Proven
Graph-linked, not correlated
AWS & GCP
OIDC, SAML, IRSA, WIF
Why trust chains matter for cloud security
A compromised GitHub Actions workflow is bad. A compromised workflow that federates to a production IAM role, reads Secrets Manager, and mounts those credentials into a running pod — that's a breach playbook. Trust chain detection maps those links across Terraform, CI/CD YAML, IAM policies, and Kubernetes manifests.
misconfigs trust chains
- Multi-hop paths with proven links between configs in different files
- Swimlane attack paths sorted first with a Trust chain badge
- Minimum fix set shows which remediation collapses the most chains
Example trust chains we find in real repos
These are common patterns — not an exhaustive playbook. Upload a project zip to the full stack scanner and misconfigs builds a trust graph from your configs to surface proven chains like:
GitHub Actions OIDC → AWS
Workflow requests id-token: write, assumes an IAM role via OIDC trust, reads Secrets Manager, and a deployment mounts the secret.
CI/CD→
IAM OIDC→
Secrets→
Pod
GitLab CI OIDC → AWS
GitLab id_tokens federate to an IAM role, grant secret read access, and the same secret appears in a production Deployment.
GitLab CI→
IAM→
Secrets→
Pod
Okta SAML → AWS
SAML federation into an IAM role, Secrets Manager access, and a Kubernetes workload consuming the synced secret.
Okta→
IAM SAML→
Secrets→
Pod
EKS IRSA → Secrets
ServiceAccount annotated for IRSA, IAM role with secret read, and a pod mounting the credential store path.
IRSA SA→
IAM role→
Secrets→
Pod
GitHub OIDC → GCP WIF
Workload identity federation from GitHub to a GCP service account, Secret Manager read, and GKE secret mount.
GitHub→
GCP SA→
Secret Mgr→
Pod
CI OIDC → IAM admin escalation
Pipeline OIDC trust scoped too broadly — a single workflow compromise can reach admin-level IAM permissions.
CI/CD→
OIDC trust→
Admin IAM
Live sample
Interactive trust chain results
Pre-built output from trust-chain-demo.zip — four proven AWS trust chains.
Click any step in the swimlane to see linked configs. No account required.
How trust chain detection works
Upload one project zip
Drop Terraform, GitHub Actions, GitLab CI, Okta exports, and Kubernetes manifests into the full stack scanner.
Build a cross-layer trust graph
misconfigs links OIDC providers, IAM roles, secret stores, and pod mounts by identifier — across files and layers.
Surface proven attack paths
Trust chains appear first in Attack paths with a green badge, swimlane diagrams, and a minimum fix set for remediation.
Find trust chains in your codebase
Run a full stack scan on your repo — free tier includes 2 runs per month. Or download the demo zip and upload it at /stack.