Hard-Coding Secrets : Be Aware of the scariest breach for your organization

Let me tell you a real story. A developer pushed some ‘rails’ code to his Github Repo at around 9 pm at night and went to sleep. Next morning he woke up with a shocking mail regarding AWS account Expense bill. Reportedly, it was $4900 which was way too excessive than his average spend of $2 per day.

The Zeroth Step you should take

Upon looking into the RCA he found out that Somebody had spun up 20 c3.8xlarge EC2 instances in each region which summed up to $2600 of computation in just one night. These all were used for cryptocurrency mining. So how did that ‘Somebody’ access and spin up resouces ?

More interestingly, it was observed that no secrets were revealed in the code that were pushed to repo but the developer had mistakenly commited secret key to his code few days back and bots were able to crawl this access key. Can you imagine the nightmare ?

Smaller mistakes, Greater impact !

According to a report by GitGuardian “10 million new secrets occurrences were exposed on GitHub in 2022. That’s a 67% increase compared to 2021” .

You might think that who does hard-code secrets ( Encryption keys, API tokens & login credentials ) ? it might be inexperience developer ? Frequent code review can reduce this culture. But imagine today’s fast-paced Agile SDLC with VCS, CI/CD, Cloud where code is freqeuntly and consistently being cloned, forked, branched, copied, shared and shipped to multiple local to enterprise systems and a single mistake can lead to unprecedented consequences. The same report shockingly discovers that “1 GitHub code author out of 10 exposed a secret in 2022.”

Secrets are much frightening because it is not a Runtime Vulnerability. Eventually that means your application need not to be in running state to get vulnerable. At the time of just residing in your code repo your application is exposed and ready to be exploited. The CWE-798 “Use of Hard-coded Credentials” is among top 15 Most Dangerous Software Weaknesses list. Even most common application vulnerabilities like XML External Entity (XXE) , Server-Side Request Forgery (SSRF) , Cross-Site Request Forgery (CSRF) need your application in running state to get vulnerable.

In what phases of SDLC, secrets can be exposed ?

Secrets can be invoked by individuals as a form of embedding it to the source code or as configuration files. In every stage of CI/CD pipeline, the secrets can get exposed, be it through the code building phase or through deploying to test environment or through an automation script.

Secrets and Snippers All through the SDLC

How to Avoid Hard Coding Secrets ?

Prevention is always better than cure. Preventing the secrets to be exposed at the Zeroth step would be the most sought necessity. It can be implemented with mindsets, practices and tools.

First we have to analyse and identify the phases where the secrets can get invoked and it varies from organization to organization, project to project. But from the begining we can shift the securtiy as much left as possible. After identifying, we need to introduce proper control mechanisms to prevent leaking secrets through codebase.

• Right through the IDE plugins we can detect secrets at the time of code residing in developers’ workstation.
• We can use git hooks to detect secrets at pre-commit, post-commit, pre-push, pre-receive and post-receive phases.
• The secrets can be detected through the static tests using SAST tools
• Post build Software composition analysis and binary scan also include the secret detection.
• Interactive application security testing (IAST) also must check for any secrets.
• Docker image scanning and K8S YAML files should be part of the checks.

If the developers accidentially hard code the secrets and immediately gets notified/prevented it can be fixed in less than a minute. But if he goes on to accidentally commit the code then again it will take at least 5 minutes to ammend the commit and cleansing the git secrets. By any chance, if it reaches to central repo it will be considered as compromised. Immediately the damage control actions items should be taken and that would be time taking and cost inefficient. Rotating and revoking keys will afftect multiple teams and create chaos resulting in slow and unsecure SDLC. So you can imagine how remediation time grows exponentially with the various phases of secret expose.

So, Now (if not yesterday!) is the best time to vouch for “Absolutely No hard Coded Secrets” towards a security hardended Organization.