I discovered thousands of open databases on AWS

Well, managers aren't scientists looking for truth. They are people running businesses that need to stay afloat and get stuff done. There's a lot of wiggle room there, mostly due to time pressure (from a charitable perspective, less charitable: also because of company politics).

With so many 10x full-stack developers who're just looking to get sh done and clock out, it can't be otherwise. If managing a server becomes just another bullet point in a developer job, this is exactly what we get.

Sure I can deploy stuff, but you shouldn't trust me. Unfortunately many are not so honest or even aware of the complexity (unknown unknowns).

On the other hand, I would argue that there are way too many footguns hidden everywhere, like the default binding of docker mentioned here. So yes, a highly skilled IT security professional knows them all, but they are rare. And I think it should be possible to set things up securely in a straight forward way, for people with their speciality in other areas, of which there are plenty.

I didnt need to get beyond there to see when you went wrong, and the bar for competence is not high across the board. Sadly I havent found a way to make money out of it, but you have to be aware of it to navigate the world safely.

There are two things at play here:

The reality of what happens is that devs with limited experience are asked to do things far outside their comfort zone because they aren't staffed enough. This isn't on the dev, it's on the company and a reality when it comes to growth. People make mistakes.

The second thing is that the databases themselves should be secure by default but are not. That's on the developers of that software. DBs should require setting strong passwords on creation.

Aws should also warn users about exposing these services directly to the outside world instead of just within the vpc.

Where are you going to store the password?

I'm not saying it's rocket science but it does take consideration. Do you store it in a plain text file on the server? How do you deal with CI/CD? Do you run a separate service for one credential?

I accidentally opened up a Redis test-instance to the world like this.

I even follow this standard rule for pet projects

That isn't just a docker thing, though a few notable accidents with docker have shone a light on the issue in recent times, and is one of the reasons I much prefer to keep my firewall away from where things are running, between them and the unwashed masses on the public network.

Even at home I have a separate small firewall box between the server that hosts things (and the rest of my network) instead of trusting that host to manage its own security in that way. If I run a service via docker or anything else on there, the outside world doesn't see it unless I open a way in elsewhere. For extra paranoia, the network leg that others can connect to (wireless AP & wired network ports in the guest room) is also separate and only sees parts of the server(s) I explicitly want it to (you can do this with vlans and such depending on your kit, I've actually just got an extra NIC on the router).

Never assume a process/service/container/etc is at all locked down, unless you have checked it out yourself or have it sufficiently wrapped in things you have locked off.

For example if a developer needs to access a resource within a VPC then this sky rockets complexity. You can't just connect to something running in a VPC from the outside world. You'd have to install and configure a VPN and it becomes a whole ceremony for both the person setting all of this up and the person connecting.

Using a VPC/VPN and keeping your important things internal (like a database or staging environment, etc.) is a really good idea but unless you have someone who has a really solid understanding of this it's a whole lot easier to make something public, restrict a security group by IP and keep a whitelist of IPs up to date for developer access.

Whenever I read stories like these, it seems clear to me that someone moved to the cloud in order to not have to care about security. The 'cloud does everything for you!'. Just like you imply in your answer that PaaS, the next level of abstraction, will solve all your security problems. This move, however, will inevitably lead to a situation where people work with new and complex systems that they don't understand (remember: not having to understand them is the sole reason they use them). Unfortunately, working with complex systems you don't understand is the number one reason for vulnerabilities in the first place.

I am not convinced that a service exists that abstracts security away from you.

If it's a test instance then this is a nice obvious place to go get it from. If it's not then the service isn't open by default, and in both cases we're not asking people to enable remote access themselves by some scheme which may allow them to do it without setting a password.

Same thing with TLS IMO: let certs be specified, or default to generating some - any option is better then default no encryption.

That exploit was single-handedly responsible for hundreds of thousands of bots (and more likely millions in later years) which wreaked havoc on the internet as a whole -- these were the days when a handful of bots on good connections could take down the Amazons of the world for lengthy periods (days, not hours). That they let it go on for so long was comical at the time, but in hindsight seems criminally negligent.

Don't repaste your own comments just because there's been a dupe.

One additional consideration is that the secure defaults should be usable, otherwise the tendency will be to just disable them entirely (think SELinux and how commonly that's turned off as the first action on server setup)