Secrets Management for Singapore DevOps Teams: Stop Hardcoding Credentials in Your CI/CD Pipeline

In 2023, a Singapore fintech startup discovered that their AWS account had been compromised and S$180,000 in cryptocurrency had been mined on their infrastructure over three weeks. The attacker had found an API key hardcoded in a JavaScript file on a public GitHub repository — committed six months earlier by a developer who had since left the company. The repository was a demonstration project, not a production codebase, and had been archived. No one had reviewed it since the commit. The API key gave the attacker access to AWS IAM credentials embedded in the same environment. The attacker's infrastructure costs appeared in the startup's monthly bill before anyone thought to check the GitHub repository that no one was supposed to be using anymore.

This is not an unusual incident. TruffleHog, a secrets scanner, has found over 10 million exposed secrets in public GitHub repositories in a single year of scanning. For Singapore's growing technology sector — from fintech startups in the Central Business District to government digital services modernisation projects — the risk of exposed secrets is not theoretical. It is a daily operational reality. The hardcoded database password in a Python script. The AWS access key committed to a private repository by a developer who thought it would be fine because the repo was private. The CI/CD pipeline that uses a shared service account credential because rotating it would require updating 40 build jobs. These are the vulnerabilities that external attackers scan for automatically, systematically, and profitably.

Why Secrets Management Fails in Practice in Singapore DevOps Environments

The principle of secrets management is well understood: credentials should not be hardcoded in source code, should not be stored in version control, and should be rotated regularly. The challenge is that implementing this in a fast-moving development environment requires tooling, discipline, and infrastructure that many Singapore teams do not prioritse — until after a breach.

Several patterns make secrets management fail in practice. The first is treating secrets management as a security team responsibility rather than a development workflow responsibility. When security teams identify hardcoded credentials in a codebase and send the development team a remediation request, the response is often that fixing it requires a pipeline redesign, which will take weeks, which will delay the sprint, which the product owner will not approve. Secrets management that is not integrated into the development workflow — baked into the CI/CD pipeline, enforced by automated scanning, and designed so that using it is easier than not using it — will consistently fail.

The second failure pattern is the proliferation of secrets without a central registry. Singapore organisations we assess frequently have credentials scattered across multiple systems: environment variables in production, credentials stored in a shared spreadsheet (yes, this happens), secrets baked into container images, and API keys stored in configuration files on developer workstations. The result is that when a credential needs to be rotated — because an employee left, a service was decommissioned, or a breach is suspected — there is no reliable inventory of all the places that credential is used.

The third failure pattern is treating secrets rotation as a one-time exercise rather than an operational discipline. Rotating a database password or an API key that is used across 15 microservices, 3 CI/CD pipelines, and 2 monitoring systems is genuinely hard work. Teams that have not invested in a secrets management infrastructure do this manually. The friction of manual rotation means that in practice, credentials are rotated only when there is a forced requirement — after a breach, after an employee leaves, or when a vendor forces an API key rotation. By then, it may already be too late.

The Secrets That Singapore DevOps Teams Actually Need to Manage

Before implementing a secrets management programme, it helps to have a clear taxonomy of the secrets that actually need managing in a typical Singapore software environment.

Cloud Provider Credentials

AWS access keys, Azure service principal credentials, and GCP service account keys are the highest-risk secrets in most Singapore cloud environments. These credentials can provide broad access to cloud infrastructure — storage buckets containing customer data, compute resources for cryptocurrency mining, and database instances. Long-lived static access keys should be replaced with short-lived credentials obtained through identity providers: AWS IAM Roles, Azure Managed Identities, and GCP Workload Identity Federation. For CI/CD pipelines that require cloud access, the pipeline should assume a role rather than use a static access key stored as a secret.

Database and API Credentials

Database passwords, API keys for third-party services (payment gateways, SMS providers, email platforms), and authentication tokens for SaaS platforms are frequently hardcoded in configuration files or stored in environment variables that are themselves insecurely managed. These credentials should be stored in a secrets manager — AWS Secrets Manager, HashiCorp Vault, Doppler, or Azure Key Vault — and injected into the runtime environment at deployment time rather than stored in source code or baked into container images.

SSH Keys and Private Certificates

Private keys for SSH access to servers, TLS certificates for internal services, and GPG keys used for code signing should be treated as secrets — which means they should not be stored in version control, should not be stored on developer workstations without encryption, and should be rotated according to a defined schedule. SSH keys for production server access should use a certificate authority model rather than distributing individual keys to each developer.

CI/CD Pipeline Secrets

Build systems — GitHub Actions, GitLab CI, Jenkins, Azure DevOps — frequently require credentials to deploy to environments, pull from container registries, and access cloud resources. These secrets are often stored as pipeline variables, which is an improvement over hardcoding, but many pipelines then log the environment variables during execution, inadvertently exposing secrets in build logs that may be accessible to unauthorised users.

A Practical Secrets Management Implementation for Singapore Teams

Implementing secrets management does not have to mean a complete infrastructure overhaul. The following approach is proportionate for Singapore SMEs and startup teams who need practical results without a six-month migration project.

1. Start with a secrets audit. Before implementing any new tooling, understand what secrets you have and where they are. Use TruffleHog or GitGuardian's open-source scanner to scan your repositories — both public and private — for hardcoded credentials. Scan your CI/CD pipeline configurations. Interview your developers about where they store credentials for development and testing. The output of this audit is your secrets inventory, and it tells you where the highest-risk exposures are.
2. Deploy a secrets manager for new credentials. Start by moving new credentials — new API keys, new database passwords, new cloud service accounts — into a centralised secrets manager. AWS Secrets Manager, HashiCorp Vault, and Azure Key Vault all offer programmatic access with SDKs for major languages. The goal is to make using the secrets manager the path of least resistance for developers: if fetching a secret from the vault is easier than hardcoding it, they will do it.
3. Integrate pre-commit and CI/CD scanning. The highest-value automated control is preventing secrets from entering version control in the first place. Configure pre-commit hooks using tools like Gitleaks or detect-secrets to scan commits before they are pushed. Integrate secret scanning into your CI/CD pipeline as a build failure condition. This is not optional in a mature development workflow — it is the enforcement mechanism that makes the other controls reliable.
4. Enforce least-privilege access to secrets. Not every developer needs access to every secret. Production database credentials should be accessible to the deployment system and to a small number of operations personnel, not to every engineer with repository access. Implement role-based access control in your secrets manager, and integrate it with your identity provider so that access to secrets is tied to your existing authentication system and automatically revoked when an employee leaves.
5. Implement automated rotation for high-risk secrets. Identify the secrets with the highest risk if exposed — cloud provider root account credentials, production database passwords, payment gateway API keys — and implement automated rotation for these first. AWS Secrets Manager supports automatic rotation for RDS databases. For other credential types, HashiCorp Vault's dynamic secrets engine can generate short-lived credentials that are automatically rotated. Where full automation is not yet feasible, implement quarterly manual rotation with an accountable owner for each credential type.

The Discipline That Makes It Work

The hardest part of secrets management is not the tooling. It is the discipline. The developers who have been storing credentials in environment files for years will need to change their workflow. The CI/CD pipelines that have been using static credentials for convenience will need to be updated. The secrets that are currently scattered across 10 different systems will need to be inventoried, migrated, and retired from their original locations. This takes time, requires cross-functional coordination between development and security teams, and will encounter resistance at every step where it is not automated.

The teams that successfully implement secrets management are the ones that start with the highest-risk exposures — the cloud credentials that give production access, the database passwords that were committed to repositories — and work systematically down the list. They integrate scanning into the CI/CD pipeline so that new secrets cannot be committed without the build failing. They make the secrets manager easy to use so that developers do not have a workflow incentive to bypass it. And they accept that getting to a fully mature secrets management programme is a journey, not a project — and they start the journey before they have a breach to motivate them.