I still think that's a silly reason not to hire their programmers, unless they played a role in creating weak security.

Security is often a whole company exercise that needs to be prioritized by management, putting blame on some individual programmers seems to show a lack of understanding of how infosec works.

>needs to be prioritized by management

If the attitude of these engineers is "we don't emphasize security unless management tells us to" maybe they don't deserve to be hired elsewhere?

Management are not omniscient; they depend on their staff.

Yeah, that's not how infosec works. You've almost certainly written code that has exposed user information (unless you've written no user-facing code).

Are you, as an engineer, going to organize a pentest for the software? Even if you encourage management to do so, it's still up to management to actually book the deal.

At minimum, I'm going to design a user-facing system as correctly as I am able and to the maximal extent of my abilities, because holding data in trust for a user is a profoundly serious responsibility and it wouldn't be right to do otherwise. And, when user-identifying information is involved, every place I've ever worked has had an understanding that that kind of sensitive work will be done when it's done and they can fire my ass if they don't like it. Whether they've been happy about it or not, nobody has ever tried to fight me over it, let alone take me up on the "fire me" bit.

And when it is done, I will endeavor to hit it as absolutely hard as I can to break it. I will advocate for regular penetration tests and audits, and I will throw an absolute goddamned fit when they don't happen. (My current company retains very little personal information and we still put ourselves through a pretty rigorous security audit at least once a year. A measure of "do thou likewise" is fair.)

The fun part is I don't even call myself an "engineer", because I'm not and I can't be with the tools and practices I have at my disposal. I'm a software developer, just like about 99.9% of this industry. I just happen to care a little, and I just happen to try to do better.

The only part that matters is the penetration test bit. And it's out of your control as a rank-and-file engineer.

Those who don't accept this are like doctors who don't accept that washing their hands is the important part, not the care and emotional sensitivity that goes into treating a patient.

That's not true. Testing is reinforcement of that competence and that good design, it does not replace it. Relying on penetration tests to secure your systems has an implicit dependency on the completeness of those tests--and putting armor over the bullet holes isn't how you keep a plane in the air.

A pentest reports findings, and then regardless of how incompetent the programmers are, they are required to fix them. Then a retest happens, which verifies that the findings were fixed.

I've seen a trading application go from "typing ' will result inn SQL injection" to "basically bulletproof" due to this process.

Devs can become remarkably competent when their smugness is wiped away by finding some crucial vulnerabilities they overlooked.

I know it's tempting to believe that the design part matters, but it's also tempting to believe that a doctor's emotional support matters just as much as washing your hands.

Do a stint in the pentest industry. It's eye-opening. (Look into my eyes. I've seen things. Terrible... things...)

The AFF back to back breaches were interesting because there were faults to found at every level.

* The breach included PII from a property they had already sold, but held onto for some reason.

* SHA1. A good choice if you want to slightly inconvenience somebody with a GPU, while also increasing the odds of your hashes getting uploaded in full to one of many distributed cracking projects.

* No effective user input validation. The exploit was one step in sophistication beyond those ancient IIS ../../hue.txt attacks.

* No attempt at anything resembling principles of least privilege, exec whatever wherever.

So, everyone failed - executives to DBAs. Screw pentests, start by implementing best practices that have been around for 40 years.

>Are you, as an engineer, going to organize a pentest for the software?

Are you, as an engineer, going to sit back and watch the project you built (containing very personal information in this case) get compromised? Even if you know management isn't paying proper attention?

See, that's the problem with every developer in Silicon Valley calling themselves an "engineer"; they want the title without the obligations that a professional engineer has. "Not my problem" would cost you your designation.

> See, that's the problem with every developer in Silicon Valley calling themselves an "engineer"; they want the title without the obligations that a professional engineer has. "Not my problem" would cost you your designation.

All engineers make mistakes and misjudgements, even the ones working in long-established fields, as we can see from the 737MAX saga. It's management's job to design a organizational structure that puts enough safeguards in place that mistakes get captured before the product rolls out. That's what management literally means.

> Are you, [...] going to sit back and watch the project you built get compromised?

How does this work? Do you rip off your glasses, strike a manly pose and run for the data center, stopping only to force the infra team to give you the credentials?

More seriously...

Organize your own IR tiger team outside of management channels? Congrats, you're unemployed tomorrow, together with anyone silly enough to buy in.

Start making rogue code changes you think are appropriate? That would run in to "want[ing] the title without the obligations". Oh, and also probably end up with you unemployed.

So, really, what are you proposing?

> Organize your own IR tiger team outside of management channels?

This gave me a good laugh, thank you

> Are you, as an engineer, going to sit back and watch the project you built (containing very personal information in this case) get compromised? Even if you know management isn't paying proper attention?

I'm glad I'm not the only one who feels like this.

I nearly got fired by digging my heels in on a privacy/infosec flawed design... until CTO/CIO layer gleaned what I was freaking out about and the energy (angry, "wtf", etc) suddenly pivoted to the original architect and engineers who cooked up some half-baked stuff.

You don't want your name attached to bad stuff in life. You only have one reputation. Don't mis-spend your social (political) capital by letting dummies bully you into ignoring tangible security issues.

Having previously been in the adult biz it is now considered a black mark on your resume. It was all mostly black hat work at one point or another.

That is a load a bs. If anything, it has been enabling for me. Any business that wouldn't want to hire me based on the incredible scalability experience I gained from working on a super high traffic/revenue project, isn't a company I would want to work for anyway. Nothing I did was black hat.

I was in the business pre-tube. I learned a lot too.

It’s probably very different now but affiliate shaving, spamming, cpc fraud were all ubiquitous in the late 90s/early 2000s.

May 2006 - April 2010

Yes, we had to deal with all of that as well. Also built a lot of automated tools to deal with those sorts of things. My favorite one, I named 'the cockblocker'. ;-) This sort of experience you just can't get elsewhere and has been extremely valuable for me.

That sounds crazy to me. I'd be much more interested in a conversation with a devops engineer from pornhub than one from YouTube.

I was in web hosting, we hosted over 120k sites at our peak. Rent a /21 for a week? No problem. Interesting times for sure.