A Smart Approach to Managing Sensitive Credentials in Rails with Sekrets

The client’s Ruby on Rails application contained hardcoded credentials (API keys, tokens) inside the source code. Storing secrets in plain text within the repository increases the chance of accidental leakage and complicates audits and compliance.

• Repository scanning to identify all hardcoded secrets across .rb and .yml files.
• Code refactoring to remove inline secrets and read values from an encrypted file managed by the Sekrets gem.
• Secure storage of credentials in config/sekrets.yml.enc, with the decryption key stored safely outside the repository (e.g., a secrets vault/password manager).
• Secure runtime access using SEKRETS[...] without invasive changes to the app structure.

Example: referencing secrets in YAML via ERB

some_service:
  api_key: <%= SEKRETS[:some_service_api_key] || 'fallback-if-missing' %>

Example: referencing secrets in Ruby

token = SEKRETS[:slack][:token]

• Ruby on Rails
• Sekrets (encrypted YAML secrets)
• Docker Compose (dev bootstrap)
• Password manager (for .sekrets.key)
• Secret-scanning tools (repo hygiene)

• Removed all hardcoded credentials from the codebase.
• Significantly reduced risk of accidental credential exposure and improved auditability.
• No meaningful cost impact; minimal developer disruption.

• Implementation time: 4 days
• Hardcoded secrets removed: 100%
• Additional cost: $0
• Repository exposure of secrets: 0

• Always separate code and secrets; never commit plaintext credentials.
• Keep the encryption key (.sekrets.key) out of the repository and rotate it per policy.
• Use automated scanners to continuously prevent regressions.