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.

we love to say things like these, but... most security issues are in fact BYPASSABLE - virtualization, firewalls, autorollbacks, ro-filesystems and so on are many of the tools we have on our belsts

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

▲

gamerslexus 2 days ago | parent [-]

If you go against every principle (defense in depth, security through obscurity), maybe you should ask yourself "am I willing to be on the record saying this when my company gets hacked?"

There can be multiple reasons system crumbles, do you want to be behind one of them... intentionally?

▲

dragochat a day ago | parent [-]

100%. I'm willing to prioritize what matters at the right time. if "inner-system security" is not the right priority, and security can be attained at the "outer-system level" better, we should have the balz to say it. fuckitol

▲

gamerslexus a day ago | parent [-]

Imagine if your doctor said "we don't really need to do this if some other guy or nurse does a right job, so fuck it".

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?

	▲	dragochat 11 hours ago \| parent [-]
		you got everything I said wrong: I'm familiar with security and infrastructure best practice and I'm confident I/we can securely deploy almost any vibe-coded crap someone can throw at us - we understand security, we understand defense-in-depth, we understand the subtle trade offs of why security by obscurity is usually a bad idea (and when it does help) etc. 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