T09 · Insecure Skill Coding Practices
- Location
agents/engineering/backend-architect.md:211- Finding
Hardcoded Trivial Database Credentials in Deployment Template
- Content
View full analysis
Vulnerability Details
File Location:
agents/engineering/backend-architect.md, lines 211-237
Vulnerability Type: Hardcoded credentials in deployable configuration
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 backend agent provides a directly reusable Docker Compose template containing the fixed database username
userand passwordpass. The same credentials are embedded in three service connection strings and in the PostgreSQL server configuration.Because this is presented as a technical deliverable rather than explicitly restricted pseudocode, users may copy the configuration into development, staging, or production deployments. A predictable credential offers no meaningful resistance if PostgreSQL becomes externally reachable, if another container on the network is compromised, or if the configuration is disclosed through logs, source control, deployment dashboards, or process environment inspection.
Environment variables do not protect a secret when the secret is hardcoded directly into the configuration. Reusing the same account across multiple databases also broadens the effect of creden ...[truncated 1283 chars]
- Remediation
View remediation
Remediation Suggestions
-
Remove all literal database passwords and connection strings containing credentials.
-
Require secrets through fail-closed variable expansion, for example:
yaml environment: POSTGRES_USER: ${POSTGRES_USER:?POSTGRES_USER is required} POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required} -
Construct application connection strings from secret-injected values rather than committing complete credential-bearing URLs.
-
Generate high-entropy, unique credentials for each environment and service.
-
Use Docker secrets, Kubernetes Secrets with an external secret manager, or a managed secret service instead of plaintext Compose variables in production.
-
Assign separate least-privilege database roles to the authentication, product, and order services.
-
Explicitly label local examples as non-production templates and prevent startup when required secrets are missing.
-
Add secret scanning and configuration linting to generated-project quality checks.
-