Comment by nobody9999 | Hacker News Reader

Comment by nobody9999 | Hacker News Reader

Parent Full thread

>So I agree I guess, but don't at the same time.

I suppose I do too.

While a lack of designed-in security is often the (sometimes disastrous) result, I posit that it's more about a lack of knowledge/education around good software security design/implementation than spec changes or scope creep.

If good security design practices were stressed when teaching software development (and/or included in resources for autodidacts) and given the same value as other development concepts, developers would incorporate those concepts from the start, rather than having to bolt them on (or not) later on.

As such, it's more about lack of knowledge/focus/value placed on security in software design/development.

Given the value of data that being secured with software, good security practices should be, if not just as integral, to software development as performance or UX design, it should at least be a consideration before prototyping.

> I posit that it's more about a lack of knowledge/education around good software security design/implementation than spec changes or scope creep.

It probably depends on what your team is good at. I tend to work in fairly security conscious teams. They check the length of buffers, don't rely on anything from the user, etc. So most of our issues tend to be from our architecture being drastically changed to integrate our solution into something else, or vice versa. Stuff is dropped on us, opaque libraries and internal code, and entirely new goals created around the big stuff, data persistence, key management, and so on.

But when I had an actual stable product that could not get spec changes (it was custom hardware) we knew from the beginning how the project would go and how all of the pieces would fit and it went together cleanly. But, it turns out many embedded engineers don't (didn't maybe, it was a while ago) program as defensively because they're used to owning the entire scope. If they put a value somewhere they expect it to be there, unmolested, when they want it. That project was full of buffer overflows and bad crypto.

> If good security design practices were stressed when teaching software development (and/or included in resources for autodidacts)

Yeah. I'm not sure how but it does tend to be lacking. Everyone probably needs a different hook. For me it was quality. How could I say my software does X if you have a way to break it?

Reply on news.ycombinator.com