What you're trying to point out is that sometimes the real threat model (i.e. the security concerns list of the stakeholders) is not the same as the explicit modeling they do of threats. And that's actually very common: HTTPS, for example, is based on a model of eavesdropping threats which only applies to a small case of real-world security problems (public WiFi), models a lot of threats which haven't been so important (ISP malfeasance, DNS hijacking) and the resulting certificate system may be worse for some bigger matters of network security (protecting from government eavesdropping, for example) when compared to something like SSH.
But HTTPS is a good security standard for what it does, and we don't claim that HTTPS sucks just because a lot of people have malware on their PCs which can trivially transmit their traffic to untrusted third parties. Rather, it's your responsibility to revise your explicit threat models to accord with your own implicit expectations. Your clients' students are suddenly upset that your client was storing Social Security Numbers on your servers, which could be read by the public via your API? You have hereby discovered that your "explicit" threat model, which left the front door unlocked, was failing to live up to an "implicit" threat model which you had. You now need to either punt the problem off to the client ("we're not storing your sensitive info, our service is not appropriate for that!") or update your explicit model ("we're re-securing our systems and assuming that everything is potentially sensitive, so new permissions systems will guard access").
Running and continuing to run -CURRENT when you know that occasionally the front door's locks can fall off for any or no reason, means that you've accepted this reality.
What you're trying to point out is that sometimes the real threat model (i.e. the security concerns list of the stakeholders) is not the same as the explicit modeling they do of threats. And that's actually very common: HTTPS, for example, is based on a model of eavesdropping threats which only applies to a small case of real-world security problems (public WiFi), models a lot of threats which haven't been so important (ISP malfeasance, DNS hijacking) and the resulting certificate system may be worse for some bigger matters of network security (protecting from government eavesdropping, for example) when compared to something like SSH.
But HTTPS is a good security standard for what it does, and we don't claim that HTTPS sucks just because a lot of people have malware on their PCs which can trivially transmit their traffic to untrusted third parties. Rather, it's your responsibility to revise your explicit threat models to accord with your own implicit expectations. Your clients' students are suddenly upset that your client was storing Social Security Numbers on your servers, which could be read by the public via your API? You have hereby discovered that your "explicit" threat model, which left the front door unlocked, was failing to live up to an "implicit" threat model which you had. You now need to either punt the problem off to the client ("we're not storing your sensitive info, our service is not appropriate for that!") or update your explicit model ("we're re-securing our systems and assuming that everything is potentially sensitive, so new permissions systems will guard access").
Running and continuing to run -CURRENT when you know that occasionally the front door's locks can fall off for any or no reason, means that you've accepted this reality.