T09 · Insecure Skill Coding Practices
- Location
agents/engineering/backend-architect.md:211- Finding
Hardcoded Weak PostgreSQL Credentials in Reusable Deployment Template
- Content
View full analysis
Vulnerability Details
File Location:
agents/engineering/backend-architect.md, lines 211-237
Vulnerability Type: Hardcoded credentials and insecure secret management
Risk Level: MediumVulnerable Code
yaml auth-service: build: ./auth-service ports: - "3001:3001" environment: - DATABASE_URL=postgresql://user:pass@postgres:5432/auth - JWT_SECRET=${JWT_SECRET} - REDIS_URL=redis://redis:6379 product-service: build: ./product-service ports: - "3002:3002" environment: - DATABASE_URL=postgresql://user:pass@postgres:5432/products - ELASTICSEARCH_URL=http://elasticsearch:9200 order-service: build: ./order-service ports: - "3003:3003" environment: - DATABASE_URL=postgresql://user:pass@postgres:5432/orders - KAFKA_BROKERS=kafka:9092 postgres: image: postgres:15-alpine volumes: - postgres_data:/var/lib/postgresql/data environment: - POSTGRES_USER=user - POSTGRES_PASSWORD=passTechnical Analysis
The reusable Docker Compose example embeds the predictable database credentials
user:passin three connection strings and repeats the password in the PostgreSQL service configuration. These values are not placeholders enforced through external secret injection; the configuration is directly usable as written.Hardcoded credentials frequently propagate into generated projects, source-control repositories, CI logs, deployment manifests, and container inspection output. Because the Skill is designed to generate backend architectures and deployment guidance, users may treat this template as an acceptable implementation rather than a development-only demonstration.
The same database identity is also shared across multiple services, violating credential isolation and least-privilege principles. Compromise of one service could consequently expose every database accessible to that identity.
A
...[truncated 1189 chars]
- Remediation
View remediation
Remediation Suggestions
-
Replace literal credentials with mandatory secret references:
yaml environment: POSTGRES_USER: ${POSTGRES_USER:?POSTGRES_USER is required} POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required} -
Construct database connection strings from externally supplied secrets or use mounted secret files rather than embedding passwords in Compose manifests.
-
Create a separate database identity for each service and grant access only to the required database, schema, tables, and operations.
-
Generate high-entropy credentials through an approved secret manager.
-
Use Docker secrets, Kubernetes Secrets backed by an external secret manager, or the cloud platform's managed identity and secret facilities.
-
Prevent secrets from appearing in source control, logs, generated documentation, command histories, and container image layers.
-
Add secret scanning to CI and rotate any credential that has been deployed from this example.
-
Clearly label simplified examples as development-only and provide a secure production configuration alongside them.
-