Service Dependency Graph
Understand your blast radius before attackers do.
When a single service is compromised, how far can an attacker go? codelake maps every service dependency, trust boundary, and shared secret to calculate your exact blast radius.
Modern applications are not monoliths. They're webs of interconnected services, databases, message queues, and external APIs. A vulnerability in one service can cascade through shared credentials, internal APIs, and trust relationships. codelake makes these invisible connections visible.
Service Dependency Map
User Service
3 vulnerabilities
Payment Service
Secure
Notification Svc
1 warning
PostgreSQL
PII data
Redis Cache
Session data
Sendgrid
External API
warning Shared DB credential: user-service + notification-service
What It Maps
Every connection in your infrastructure.
codelake analyzes your code, configuration, and infrastructure definitions to discover every service relationship — even the ones your team forgot about.
Internal Services
All microservices, internal APIs, and background workers in your codebase. Communication patterns (REST, gRPC, message queues) are identified and mapped.
External APIs
Third-party services your application depends on: payment processors, email providers, analytics, storage. Each external call is a trust boundary crossing.
Databases
All database connections: which services have access, what credentials they use, whether connections are encrypted. Includes SQL, NoSQL, and document stores.
Message Queues
RabbitMQ, Redis pub/sub, SQS, Kafka. Asynchronous communication creates invisible dependencies. codelake maps producers to consumers and tracks data payloads.
Caches
Redis, Memcached, in-memory caches. Cached data often includes sensitive information. codelake identifies what's cached, for how long, and who can access it.
Object Storage
S3 buckets, Azure Blob, GCS. File uploads, exports, backups. codelake checks access policies, encryption settings, and whether public access is enabled.
Trust Boundaries
Where trust zones begin and end.
A trust boundary is the line between what you control and what you don't. Between your services and the public internet. Between your application and a third-party API. Between production and staging environments.
codelake identifies four types of trust boundaries and validates that each crossing has appropriate security controls: authentication, encryption, input validation, and access logging.
Public ↔ Internal
The internet-facing boundary. API gateways, load balancers, CDNs. All public-facing endpoints must have authentication, rate limiting, and input validation.
Service ↔ Service
Internal service boundaries. Often assumed safe but frequently lack authentication. codelake checks for mutual TLS, service tokens, and request signing.
Internal ↔ External
Connections to third-party services. Data leaving your control boundary. codelake verifies encryption in transit, data minimization, and credential management.
Environment ↔ Environment
Production vs. staging vs. development. Shared credentials or services across environments create cross-environment attack paths. codelake identifies these overlaps.
Secret-to-Service Mapping
Know exactly which secrets power which services.
A leaked credential is only as dangerous as the services it can access. codelake maps every secret to the services that use it, the data those services can reach, and the environments where the secret is deployed.
| Secret | Type | Used By | Environments | Last Rotated | Risk |
|---|---|---|---|---|---|
| AWS_ACCESS_KEY_ID | AWS IAM | user-service, notification-service, backup-worker | prod + staging | 241 days ago | CRITICAL |
| DATABASE_URL | PostgreSQL | user-service, payment-service | prod only | 14 days ago | HIGH |
| STRIPE_SECRET_KEY | Stripe API | payment-service | prod only | 30 days ago | MEDIUM |
| SENDGRID_API_KEY | Sendgrid | notification-service | prod + staging + dev | 180 days ago | HIGH |
| JWT_SECRET | JWT Signing | api-gateway, user-service | prod only | 90 days ago | HIGH |
codelake automatically discovers secrets from code, configuration, and IaC definitions
Blast Radius Calculation
If service X is compromised, what else is affected?
Blast radius is the total impact of a single point of compromise. codelake calculates this automatically by traversing the dependency graph, shared credentials, and trust relationships from any starting point.
Scenario
User Service Compromised
Direct access: PostgreSQL database (users, orders, sessions tables)
Shared credential: AWS key also used by notification-service and backup-worker
Lateral movement: Internal API calls to payment-service (no mutual auth)
Data at risk: 12,400 user records with PII, session tokens, payment history
Blast Radius: 4 services · 2 databases · 12,400 user records · 3 environments
Scenario
AWS Key Leaked
Key permissions: S3 read/write, SES send, CloudWatch full access
Services using key: user-service, notification-service, backup-worker
Environments affected: Production and staging (same key)
S3 exposure: User uploads bucket, database backups bucket (contains full DB dump)
Blast Radius: 3 services · 2 S3 buckets · email sending capability · 2 environments
What codelake recommends
Reduce Blast Radius
- ✓ Separate AWS keys per service (unique IAM roles)
- ✓ Separate credentials per environment
- ✓ Add mutual TLS between internal services
- ✓ Implement least-privilege IAM policies
- ✓ Rotate secrets within 90-day maximum
After remediation
Reduced Blast Radius
- ✓ User service compromise now isolated to 1 service, 1 database
- ✓ AWS key leak limited to single service's permissions
- ✓ No cross-environment credential sharing
- ✓ Internal service calls authenticated and logged
- ✓ Blast radius reduced by 75%
Map your blast radius before it matters.
Start a free scan and let codelake map your service dependencies, trust boundaries, and shared secrets. Know your exact blast radius for every service in your application.