Code Security: Protecting Secrets in Your DevSecOps Journey

Welcome back to our DevSecOps journey, where we’re unraveling the secrets to securing your code and maintaining a resilient software development lifecycle. Today, we explore the significance of secret scanning and why it’s a fundamental practice. Which ventures us into the realm of cloud-native application security, focusing on the critical issue of insecure secrets storage, designated as CNAS-5 in the OWASP Cloud-Native Application Security Top 10. OWASP Cloud-Native Application Security Top 10 | OWASP Foundation

Why Secure Secrets Matter: Secrets — those crucial bits of information like passwords and API keys — are the lifeblood of many applications. When secrets are stored improperly, vulnerabilities emerge, exposing applications to potential security breaches, data leaks, and compliance violations. Our journey begins with a profound understanding of why securing these secrets is essential.

The OWASP Cloud-Native Application Security Top 10, available here, highlights the most pressing security concerns for cloud-native applications. CNAS-5, or Insecure Secrets Storage, stands at the forefront. This category encompasses all the practices that lead to secrets being stored in a risky manner within the application’s codebase. Our goal is to address this concern head-on.

Let’s embark on the journey to mitigate insecure secrets storage within our code. We’ll follow these steps to ensure your secrets remain confidential:

• Start by examining your source code; a peek at your buildspec.yml file reveals potential security gaps. Inadequate protection of secrets can open doors to malicious actors.

• Our trusty companion on this journey is Trufflehog, an open-source secret scanning tool available at this link. Download and install it, but please note that the installation method may vary based on your operating system. Our journey showcases it running on Docker and Ubuntu.

trufflesecurity/trufflehog: Find and verify credentials (github.com)

• Deploy Trufflehog by running the following command (with adjustments for your specific repository URL):

sudo docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/trufflesecurity/test_keys

• This command helps you identify sensitive information lurking within your code.
• Once you run Trufflehog, it’ll uncover secrets, such as your tokens. You can cross-verify these secrets with the contents of your buildspec.yml file. If they match, you’ve identified a security concern.

• How to remedy the exposed secrets? The answer is an AWS service known as Secrets Manager, an ideal solution for our cloud-native environment. To utilize it, you’ll store your secret (token) securely within your buildspec.yml.
• Visit your AWS Console, find Secrets Manager, and store a new secret. Define your key and value for your secret, naming it “Token-for-sonar.”

• With your secret now securely stored, head back to your source code in Visual Studio Code. Observe the changes in the buildspec.yml file:

• env: This section defines environment variables and project settings.
• secrets-manager: Here, you manage secret keys and sensitive data.
• TOKEN: sonar-cloud:token-for-sonar: We've now defined a secret environment variable called "TOKEN," securely associated with the value stored in Secrets Manager.
• Delete the login = Token you currently have (which you stored in AWS Secrets Manager) and replace it with, $TOKEN

• Save these changes, navigate to your terminal, and commit your updates to your repository:

1) git add . 
2) git status
3) git commit -m "Added SonarCloud to AWS Secrets Manager" 
4) git push

• To ensure that your AWS Identity and Access Management (IAM) roles have the necessary permissions for Secrets Manager, navigate to your AWS Console and access IAM. Update your CodeBuild service role to have “Secrets Manager Read/Write” permissions.

• With permissions in place, proceed to CodeBuild and select the project you’ve been working on, e.g., “Hello-World.” Initiate the build process by clicking “Start Build.”

Congratulations! You’ve successfully embarked on a journey to mitigate risk and enhance security within your DevSecOps environment. In our next series, we’ll delve into building a CI/CD pipeline, taking your DevSecOps journey to new heights. I’d like to express my gratitude to the CYBERPRO Solutions Community for their unwavering support and guidance in our quest to become a DevSecOps Engineers.