31–40 of 123 posts
Earlier quoted context omitted.
Try here: https://github.com/settings/security-log
I used here: /settings/audit-log" rel="nofollow">https://github.com/organizations/ /settings/audit-l... ... but the real question is what would malicious activity look like, exactly?
Earlier quoted context omitted.
I used here: /settings/audit-log" rel="nofollow">https://github.com/organizations/ /settings/audit-l... ... but the real question is what would malicious activity look like, exactly?
I see a heap of "downloaded a zip of repository" but I suspect that's Heroku CI or other CI tool running.
I've reached out to Heroku support to ask.
This is a chance to reiterate best practices: Credentials and other secrets, like API keys, should never be hard-coded in the source code repo. Use some sort of secrets management or configuration for that kind of stuff.
If Heroku could confirm environment variables were safe I’d have a much better sleep tonight.
This is a chance to reiterate best practices: Credentials and other secrets, like API keys, should never be hard-coded in the source code repo. Use some sort of secrets management or configuration for that kind of stuff.
In this case, can we confirm that Heroku environment variables were not accessed? Because if they were, even not storing secrets in the source code wouldn’t have prevented a breach. If Heroku could confirm environment variables were safe I’d have a much better sleep tonight.
This is a chance to reiterate best practices: Credentials and other secrets, like API keys, should never be hard-coded in the source code repo. Use some sort of secrets management or configuration for that kind of stuff.
In this case, can we confirm that Heroku environment variables were not accessed? Because if they were, even not storing secrets in the source code wouldn’t have prevented a breach. If Heroku could confirm environment variables were safe I’d have a much better sleep tonight.
Based on the above information, my assumption is that the attacker gained access to code repos hosted on GitHub, but not access to live dynos or the Heroku dashboard (that happily shows ENV vars). We'll see if this information updates as the investigation progresses, though.
However, given 1) write access to a github repo, and 2) auto-deployments from github to production dynos (if enabled), an attacker could exfiltrate env vars (among many other nasty things). However, this would trigger events in your app's activity log (new commits + deploys) and should be quick to verify that it didn't happen.
I'd like to discuss mitigations around this and similar incidents with other HN:ers:
- Knowledge sharing: resources, how-tos, tips - Discussing prevention, mitigation, etc - Moral support and venting
If there's already such a forum (I assume there is), please send me an invite :)
I've been eyeing it recently and I'm thinking about launching my next project with it. Does anyone have any takeaways from using Render vs Heroku?
I wonder if the hackers were kids who got bored around Easter holiday - meaning Heroku's security is shit - or if Heroku deliberately waited to announce this during Easter holiday to minimize the attention it gets - meaning they are as deceitful as all proper megacorps.
I haven't been able to trust their status page to accurately reflect what works and what doesn't for a long time. The only reliable signal is when their status page goes offline ;)