Hmm, is it normal practice to rotate secrets before fixing the vulnerability?

They first disabled rubocop to prevent further exploit, then rotated keys. If they awaited deploying the fix that would mean letting compromised keys remain valid for 9 more hours. According to their response all other tools were already sandboxed.

However their response doesn't remediate putting secrets into environment variables in the first place - that is apparently acceptable to them and sets off a red flag for me.

▲

KingOfCoders 5 days ago | parent | next [-]

"According to their response all other tools were already sandboxed."

Everything else was fine, just this one tool chosen by the security researcher out of a dozen of tools was not sandboxed.

	▲	darkwater 5 days ago \| parent [-]
		Yeah, I thought the same. They were really unlucky, the only analyzer that let you include and run code was the one outside of the sandbox. What were the chances?

▲

shlomo_z 5 days ago | parent | prev | next [-]

> putting secrets into environment variables in the first place - that is apparently acceptable to them and sets off a red flag for me

Isn't that standard? The other options I've seen are .env files (amazing dev experience but not as secure), and AWS Secrets Manager and similar competition like Infisical. Even in the latter, you need keys to authenticate with the secrets manager and I believe it's recommended to store those as env vars.

Edit: Formatting

	▲	vmatsiiako 5 days ago \| parent \| next [-]
		You can use native authentication methods with Infisical that don't require you to use keys to authenticate with your secrets manager: - https://infisical.com/docs/documentation/platform/identities... - https://infisical.com/docs/documentation/platform/identities...
	▲	Kriptonian 4 days ago \| parent \| prev [-]
		[dead]

▲

Jap2-0 5 days ago | parent | prev [-]

Duh. Thanks for pointing that out.