Developers are in a constant race against time to deliver new features and capabilities in software. Things are hastened with philosophies like “release early, release often”. This constant rush means that developers are bound to inadvertently make mistakes along the way. Developers are human after all. Hence, the focus needs to be on having the right checks and balances in place to ensure that these mistakes are rectified well in time (prior to the release ideally).
One of the more common mistakes is storing sensitive data directly in the source code. Sensitive data like – API keys, tokens, encryption keys, passwords….you get the idea here.
Researchers at North Carolina State University (NCSU) found that –
“not only is secret leakage pervasive – affecting our 100,000 repositories – but that thousands of new, unique secrets are leaked every day”
Here is a link to NCSU research paper [How bad can it git – Characterizing secret leakage in public GitHub repositories] and a news article on the same topic.
Consider that a developer inadvertently stores the cloud API key in source code and checks in code. If this code resided in a public git repository (assuming that this is an open source contribution from the organization where the developer is employed), then everyone now has access to the organizations’ public cloud using the API key in the source code. This is exactly what happened recently at Starbucks – Starbucks developers leave API key in public GitHub repo.
Developers at times store the SSH keys in the same directory where the code resides and inadvertently checkin the SSH keys along with the source code as part of the commit. Thus, the SSH key is out in the public now. It is interesting to note that attackers have already begun scanning for SSH key in public servers and repositories for some years now, as indicated in this article – Attackers start scans for SSH keys after report on lack of SSH security controls [2017].
Another scenario is the use of default passwords which are hard-coded in the source code, either as a backdoor, or default account password or something else. Either ways this could result in a serious security breach.
The right check and balance here would be to ensure that every code checkin passes a verification gate which looks for any secrets in the code being committed. This can be easily done via a pre-commit step. ThreatWatch introduces support to detect secrets in code as part of the DevSecOps offering. The idea is to allow developers better control on the process to guarantee no secrets manage to creep in to source code.
ThreatWatch can detect variety of secrets in your source code based on regular expressions (to identify API keys and tokens), entropy (to detect any encryption keys embedded in source code) and common passwords. This coupled with the ability to have your source code inspected for vulnerabilities in any third-party dependencies and license compliance for open source softwares used makes a solid offering for DevOps. DevOps engineers can look at all these details in a single pane of glass in ThreatWatch web console to reduce overall risk and improve security.
In the road ahead, ThreatWatch plans to further extend this to identify any PII or sensitive information in other Corporate Assets as well.
To know more about ThreatWatch Secrets, click here or simply write to us at info@threatwatch.io.