Last week, SolarWinds’ CEO testified in front of Congress on the hack that is largely considered the most damaging in US history. Representatives chastised the company over how the now infamous password “solarwinds123” was used for a file server. Even more damaging, that password was found in publicly available repos on GitHub.
From CNN: “Confronted by Rep. Rashida Tlaib, former SolarWinds CEO Kevin Thompson said the password issue was “a mistake that an intern made.”
“They violated our password policies and they posted that password on an internal, on their own private Github account,” Thompson said.
While it’s unclear what, if any, the role the password played in this disaster, it obviously shows how critical code security has become. Code can be an open door to your enterprise.
Here is what we all can learn from this incident:
Git doesn’t know or care if it’s an intern or not.
GitHub and other code management platforms are overly permissive. They were developed for open source, after all. Most companies give far too much access to too many developers. And it’s not just interns. Contractors or internal employees can pose just as much of a security risk and few companies have the visibility and control they need.
Access control in Git is frankly broken. And if you can’t detect anomalies like an intern hardcoding a secret and then cloning it, you are exposed.
Don’t rely on policies to keep you safe.
The CEO can try to blame the intern for both the password and the sharing of the code in his own repo, but everyone in security knows you can’t write a policy and hope it will be followed. You need active monitoring, prevention and detection.
Don’t think that just because your GitHub corporate accounts are private, passwords or other secrets can’t be leaked. In this case the intern cloned the code and then uploaded it to his own GitHub account. This is very common practice and most companies have no visibility or monitoring that extends outside their own repos. It’s a false sense of security.
Equip developers with secrets management tools.
The best time to keep secrets like this password out of code is before it’s committed to a Git repository. Equip your developer with a pre-commit CLI tool that will find secrets on their own machine. BluBracket has a free Community Edition that does precisely that. Also make sure they are using a secrets management tool like Vault.
Companies should invest in a comprehensive code security solution that accounts for key three areas:
- Access control, access audits and developer monitoring for Git.
- Secrets detection and prevention for both developers and security teams.
- Active monitoring for key company credentials or IP in the extended Git universe, not just your own corporate accounts.
Hackers have shown that GitHub and other Git systems are fertile hunting ground for credentials and secrets. Companies must invest to understand and act on comprehensive code security.