Hacked serverless functions are a crypto-gold mine for miscreants

I think the issue being exploited here is the auto-scaling nature. Compromising a web-app through something like SQL-injection then allows you to execute your own code on the server instance. You don't need to gain access to the actual back-end of the cloud system, just get the code running on the server-space that's been provisioned and then, as the compute requirements increase, the cloud provider will automatically spin up new server instances to cope with the load.

It seems to be that it's not a case of compromising the entire system, just getting your code running somewhere (even within a VM or container sitting atop the AWS/Azure/whatever instance) and the programmatic elasticity will do the rest for you. You'd think that any company running something with auto-scaling will have configured alerts to let them know when the loads are spiking and by how much, in that same way that on-prem servers will have thresholds set up for things like CPU load, disk space, latency, etc.

Basic security discipline

This is really more of the same. In general, you need hard limits to prevent autoscaling from blowing your budget. For hosted services, this really is a form of basic security. That anyone would buy autoscaling without fine-grained controls blows my mind.

CloudFog: When renting Cloud time is a bit too much like an expensive overseas cellphone Data-Plan:

"It should also be possible to shut down cloud computing resources programmatically once expenses reach a specified point, but none of the major cloud providers appear to offer this out of the box – it appears they'd rather not make it too easy for customers to limit spending."

Armchair quarterbacking...

As others have pointed out, you still need good coding and deployment practices. Puresec and their backers have fired up a FUD campaign to gain attention and sell their wares to unsuspecting management types.

The idea that a serverless function can "self-replicate" or "clone themselves" is nonsense, at least with respect to AWS. Lambda functions in AWS do not autoscale per se but rather they are created based on event or workload requirements and the code deployed is immutable, so any exploit would need to be repeatable at runtime.

The examples provided are highly speculative and to create such an exploit in the wild require insider knowledge, poor coding/architectural practices and possibly compromising the control plane as well. None of which will really be solved by Puresec's "epoxy-potting" code injection.