Is your claim that e.g. Google or American Express would be equally likely as OpenAI to suffer this issue? If so I would definitely disagree. I would be extremely surprised to see this type of issue in e.g. gmail, and if it did occur I think it would be correctly perceived as a massive scandal. Yet Google is almost certainly using Redis for important use cases.
Part of having a security mindset is assuming that system components can fail (or be made to fail) in surprising ways and making sure that the overall system is resilient to those failures. This does not necessarily require, as you suggest, vetting every part of the system. After all, few organizations had vetted e.g. log4j, but that does not mean that all organizations were equally affected by the log4j vulnerability.
There are things that an organization could have done to prevent exposure to the problem with redis-py. Here are some examples:
Assert that the result coming back from Redis is for the correct/authenticated user, or otherwise fits in the appropriate context / is the expected response to the query.
Vet upgrades to libraries such as redis-py and don’t deploy new versions unless (a) they contain a security fix, (b) they have had some time to bake in or (c) you conducted a careful review of the differences.
Conduct pre-deployment testing under load to see that the overall application behaves as expected.
I’m not really trying to claim that this stuff is simple or easy, or that a security mindset is common among tech startups; just that these are the sort of steps that a security-oriented company would take, and the fact that OpenAI apparently did not take such steps is (limited) evidence that OpenAI management is not operating with a security mindset.
Is your claim that e.g. Google or American Express would be equally likely as OpenAI to suffer this issue? If so I would definitely disagree. I would be extremely surprised to see this type of issue in e.g. gmail, and if it did occur I think it would be correctly perceived as a massive scandal. Yet Google is almost certainly using Redis for important use cases.
Part of having a security mindset is assuming that system components can fail (or be made to fail) in surprising ways and making sure that the overall system is resilient to those failures. This does not necessarily require, as you suggest, vetting every part of the system. After all, few organizations had vetted e.g. log4j, but that does not mean that all organizations were equally affected by the log4j vulnerability.
There are things that an organization could have done to prevent exposure to the problem with redis-py. Here are some examples:
Assert that the result coming back from Redis is for the correct/authenticated user, or otherwise fits in the appropriate context / is the expected response to the query.
Vet upgrades to libraries such as redis-py and don’t deploy new versions unless (a) they contain a security fix, (b) they have had some time to bake in or (c) you conducted a careful review of the differences.
Conduct pre-deployment testing under load to see that the overall application behaves as expected.
I’m not really trying to claim that this stuff is simple or easy, or that a security mindset is common among tech startups; just that these are the sort of steps that a security-oriented company would take, and the fact that OpenAI apparently did not take such steps is (limited) evidence that OpenAI management is not operating with a security mindset.