A couple times a week my freaking VP is announcing some new tool he vibecoded and talked to no one about.
I’m sure they’re all riddled with security issues, but am I gonna go be the one pointing it out? Heck no.
I’m sure they’re all riddled with security issues, but am I gonna go be the one pointing it out? Heck no.
decades of WordPress have taught us that insecure apps can 100% be securely deployed
it's a bit of an art, most recently edicated devops/sre ppl suck at it, but it's doable
...aeons a go in a former life we ran production apps that got hacked weekly, and nobody batted an eye at it, backups servers recreated from secure ro-images were span up with last-clean-app version, occassionally we had fun disassembling whatever reverse shells and other mallware that got beached on our systems (but couldn't "swim" bc everything we ran was "too exotic" for them to figure out the next steps of a proper attack), development and business continued as usual with zero interruptions etc
There can be multiple reasons system crumbles, do you want to be behind one of them... intentionally?
In other critical professions you don't want to screw up because when you lose license you're legally unemployable. Maybe it's time to require a license to be a programmer. We used to have a strong culture but those days are gone and stakes are higher. Putting people at risk because you think VC can vibe code an insecure app and then it's everybody else's responsibility to ship it securely?
sure, if the vibe-coded sloptopus does bank transfers and stuff, properly carving out these pieces out of it might require actual engineering work before containerizing it - but someone is willing to pay for it it can be done
some "toy" example: take a crappy app that stores llm keys in config files that the llm agents themselves can edit - after isolating it up, but an llm proxy in front of it and have those keys be short lived proxy-keys with aggressive rate limits and monitoring etc etc
isolation, injecting proper monitoring into code of apps, putting proxies between app and apis, and layers between app and infra it runs on or touches etc
and these things now can be mostly cookbook-ified / automated 90% of the way too
as long as you can shop things into little ppl and ensure short-lived and granular access to valuable data you can 100% run totally unsecure and buggy code reliably and get value from it
it's engineering and understanding security from first principles [and a culture arund it - that _is_ the HARD af bit though...] instead of just believing in "secure app best practices" from the "holy scriptures" - secure apps are hackable, and unsecure apps can be unhackable, heck even mil systems run on unpatched old software everywhere, they're just properly insulated, the components are insecure but the system as a whole can be perfectly secure
anything deployed is hackable ofc, question is just the profit/risk ratio a business tolerates/prefers, and what backup plans exist to "reboot" after fatal incidents
nothing's perfect in the real world but most things are survivable
reducing all risk is the same as reducing all opportunity for profit - and in a much truer sense than it seems ...as you also reduce adversary's risk to profit form you, so essentially pursuing too low risk you head towards negative sum (as security has costs) games that on average we all loose from playing