How about no?
"[...] posting production functions straight from a hackathon, because... why not?!"
I have a reason why not. Let me get your opinion. Perhaps a reason not to do this is that no good code gets written at hackathons. Sure, they're fun. You get to play around and come up with good ideas. You get to work with people you like, and depending on who runs it, you may impress somebody and get a job out of it. But eventually, after you've gone home, fallen asleep immediately, and gotten up at 3:30 AM because that's just how things work when you just stayed up far too late, then caught up on the things you need to do, you sit down to look at the code you wrote. And most of it now has to be fixed. Features need to be made into ones that work, rather than ones that work under certain conditions and crash under others. You need to actually make good systems you had placeholders for. If you take code that you wrote at a hackathon, which is by definition first-draft, under stress from the time limit, and proof of concept, and you immediately put it into production, then you are showing me that you don't understand how the process of writing secure software works.
"Last, and potentially worst, most functions contain open-source application dependencies. These libraries are statically embedded inside the function, and so they grow stale even as new versions of the library are released to the public. Over time, vulnerabilities are discovered in these older versions, including some that are very severe, and yet nothing in the serverless flow informs you they exist."
You know? That's terrible. I think that's such a big problem that we probably want to modify the serverless system to make that not a problem anymore. Let me run this past you--how about we keep some dependencies on site so that we can update them. We could just slot in the new libraries when we have to. And we'd have to be careful to ensure that all the dependency trees work well. Actually, if only we could have a repository of code that could be updated independently of the software. Those who can't keep up with new releases could include them statically, but if you could just load them when the program starts, that'd be great. Why don't we have a command on the system that just updates the database and then downloads the new approved versions of the libraries. I have a suggestion for what we should call it. I'm thinking "pacman -Syu". Pacman stands for the Performant Agile Computing Management of Advancing Nodes, and the -Syu command stands for "see you, uberrisks". Can this suggestion be covered in the next DevOps article, please?
Sarcasm note: Obviously, I'm arguing for using a standard operating system that manages libraries automatically and can be patched easily. In case some are not familiar with the command, "pacman -Syu" is the command used to automatically update all packages on arch linux.