Hardcoded API Key and Anonymous Role in a Shared Pipeline
A team of 18 developers maintains six OutSystems modules for a customer portal. Deployments run through a shared CI/CD pipeline from Development to Test to Production. A code review found a server action that calls a payment provider with an API key pasted into an assignment; the same key is used in all three environments. The Production module also has the Anonymous role enabled on a diagnostic screen that returns environment name, module version, and database connection status. The screen was added for a load-balancer health check and never removed. Service accounts used by the pipeline have Environment Administrator rights because it was easier. A contractor with a Development account can open Service Center and see the Production deployment log. The next audit is in 30 days; the payment provider requires key rotation within 24 hours of suspected exposure.
1. What are the immediate containment actions for the exposed API key and diagnostic screen? Include order and rationale.
Read the worked answer
Rotate and revoke the payment API key first, because the 24-hour provider requirement is running and the key is in code, deployment artifacts, and all three environments. Update the secret in the correct secret store, deploy, and confirm the old key fails. Then review payment-provider logs for unusual calls and notify the provider if there is any sign of misuse. Close the diagnostic screen next: remove the Anonymous role, require authentication and a restricted role, or block it at the edge. Do not merely hide it in the UI. Check whether the screen leaked database connection details and rotate any credentials it exposed. Because the key was in source history, removing the line is not enough; the key must be considered compromised.
2. Redesign secret management and environment isolation for the pipeline and the six modules.
Read the worked answer
Move secrets to a secret manager or vault, with separate values per environment and no secrets in code, module settings, or pipeline logs. Inject them at runtime through the platform's secure configuration mechanism, or retrieve them from the vault with a workload identity. Give pipeline service accounts only the permissions needed for deployment in that environment, not Environment Administrator everywhere. Use separate service accounts or managed identities per environment and require approval for Production. Rotate secrets on a schedule and after any exposure. Add secret scanning to code review and build. Keep non-secret configuration in normal configuration management. Audit who can read secrets and who can deploy; the contractor should not have Production rights.
3. The contractor can see Production deployment logs. Why is that a security issue, and what access control change do you make?
Read the worked answer
Deployment logs are not harmless read-only data. They can contain secret values, connection strings, internal hostnames, user identifiers, and stack traces that help an attacker. A Development contractor has no business need for Production logs, so this violates least privilege and environment isolation. Remove the contractor from Production roles and from any group that inherits them; review team and IT role membership in LifeTime or the platform administration console. If logs must be shared, provide a redacted export with an approval and retention limit. Add monitoring for access to Production logs. Also check whether the contractor could see other Production artifacts, such as configurations, and remediate the broader role design, not just this one account.