Security issues broadly can be boiled down into 2 categories
- Seriously mindblowing 0 days no one even considered that shock and amaze you with the hackers thinking
- Developers that took shortcuts to meet some kind of deadline
Btw that second category isn't the fault of developers but more the external pressure on devs from project stakeholders that place shipping functionality over considering security impacts
Just a dev vowing to shift left does nothing when project managers want to see features on app, you need a fundamental shift in your development culture that enables and rewards developers taking longer to ship something out, but that is built with security in mind
@insiderphd That’s was the core of my BSides London talk a few years back. Effective Shifting Left is about working more closely with Testers and Product Managers (or whatever you org chooses to call them) not lumping ‘and security’ onto the already full plate of a full stack dev.

@insiderphd Found it!

How we did successful shifting left at scale, by ignoring all the standard advice and methodologies

Featuring ....

- Me presenting somebody else's slides after only seeing the talk once, the day before, on the train.

- Me waking everyone up my punching the mic with my flappy hands at an unexpected point.

- Far too many Top Gear references (see "Not My Slides")

https://www.youtube.com/watch?v=8ERGlHijaKc

Pushing Left - How We're All Doing It Wrong by Glenn Pegden & Stephan Steglich

YouTube
Good points, @insiderphd. Thank you for bringing this up. If there is no incentive—or liability—very few businesses would create such a culture out of morality or sense of responsibility, unfortunately. How can we help businesses do it? Other than governments imposing regulations or insurance agencies refusing coverage for not having at least some sort of basic security development lifecycle program in place?
@khalid This is a great question that I think not enough people are asking, we know what bad security is, but how do we empower good security, let me know if you solve it ;)

@insiderphd @khalid

I have a 100% effective security measure, but I can't share it because it would no longer be 100% effective.

@Pjcoyle @insiderphd Patrick, hmmm.. that's not going to be sustainable. Not knowing the details, I don't want to comment much, but in general security-by-obscurity (which your measure may not be) is not a good strategy.
@khalid @insiderphd Okay, I'll describe my security. The Computer is disconnected from everything, including keyboard and screen. All of the ports are sealed with resin. It is stored in a welded faraday cage and encased in concrete. Finally, it is buried at a secret location. Even I can't access the information. (SIGH)

@Pjcoyle @insiderphd
😂​ Good one Patrick! Was a little skeptical but was secretly hoping you did have some sort of an innovative solution.

Seriously though, it does not have to be this extreme--nor this perfect of a security. Products with security designed in will make big enough of a difference in the longer term. Deliberate detail to security during design and development is the way. However, we are back to my original question: What would make product manufacturers and software suppliers to take this on?

@khalid @insiderphd the full application of product liability laws, starting by disallowing of EULA.
@insiderphd IMO it goes back to the “if it ain’t broke, don’t fix it” culture where the business owns the backlog and sign off on what goes in. It’s about the false equivalency between the hour of work where the business wants the dev team to only work on high value items (“new features”) and completely ignore low value items (“patch upgrades to runtimes”).

@insiderphd

As a developer...

That second category is our fault in many cases.

Communication is one thing, and informing project stakeholders of the severity of their decisions is something we might not be able to perform... (And yes, that's not all our fault. To say it is, is to take a victim blaming attitude.)

But...

Well, there's Therac-25.

I've heard people say that software can't harm hardware.

Nah, software can kill. And if given the opportunity, it can kill easily and quickly. (As well as slowly and painfully, as in the case of acute radiation poisoning.)

We need to be held to a higher standard (and empowered to enforce that standard.).

@adorkable @insiderphd The critical part of this is in your last bracketed clause. It’s no use holding your programmers to a higher standard if you don’t give them the power to meet that standard.
@insiderphd too often security is seen as an optional extra, secondary to getting things done. When it really should be a 1st class citizen
@insiderphd It is the fault of developers-that-take-short-cuts-because-they-don't-know-how-to-do-it-properly-but-are-too-proud/lazy-to-learn. But more usually it's not the fault of developers that are browbeaten into meeting pointless feature deadlines by project managers whose toolbox only contains "do management very assertively, keep pestering until they say yes to make you go away, then throw them under the bus"
@dvavasour I would question is it because they are too lazy/proud to learn, is it really laziness or that what they are measured on is fundamentally lines of code written/features implemented/deadlines met and security is rarely easily measured in the same ways, shouldn't management also take some of the blame for not prioritising developer education / making security a KPI for developers so it's not something they can do later/easily forget?
@insiderphd Mmm, one of my interview techniques is to (where I can) probe candidates to the point where they don't know the answer. I want to see how they behave at that point. A disappointing number try to make out I was asking a different question rather than show how they act when out of their depth. The best candidates discuss the nearest equivalent space they know and approaches to get to what I'm asking about.
@insiderphd it's settled, deadlines are a security risk
@chrisisgr8 @insiderphd: Without deadlines, though, you have feature creep. Lose-lose situation.
@insiderphd the second category represent 99% of the total though.
@insiderphd
Can I offer a third. Developers doing dumb things to get around 2005 ideas that it's all about perimeter security.
@Reikagal I would kinda say that's a subset of 2, I think devs want to write good, secure code, but they _have_ to get x feature done in y sprint or they'll get bollocked, so they're like "oh if I just turn off CSRF protection I don't get that pesky CSRF error anymore and I can move on to the next bug"
@insiderphd Where does “I just wanted to watch torrented anime while on business trip “ fall in this? Or that’s other category?

@insiderphd

"Research has shown the ratio of shortcut to mindblowing is 487:1."

@insiderphd what about OSS issues? Won’t fall into those two categories but still the largest chunk of your software on the infra.