5 ms·
That's why there are guardrails like credentials scanning tooling, security trainings, SAST, code reviews etc. Additionally, most providers now provide out of
by ath3nd 3y ago
That's why there are guardrails like credentials scanning tooling, security trainings, SAST, code reviews etc.
Additionally, most providers now provide out of the box tooling, see: https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning https://docs.github.com/en/code-security/secret-scanning/abo... that can, within minutes, sniff out whether your commits or PR has some creds, and notify you on it.
I think most of those leaks happen when credentials were given to somebody developer-adjacent (data scientist, BI, tech-y PO/PM). You know, somebody that wants to put some scripts together and call it a day. To me, that's more of an oversight on the credentials sharing process rather than a question of developer security awareness. In more enterprisey scenarios, there even is the concept of separation of responsibilities, where devs wouldn't even dream of having creds to any production system, as those are managed by a separate team. Theoretically, once you start getting into SOC2/ISO preparedness, the chance of a developer hardcoding a password/secret in code should be close to 0. Right?