Hacker News Reader

Comment by SomeStupidPoint | Hacker News Reader

> Create a culture of writing and deploying secure code.

How?

That may sound glib, but this is really just asking everyone to try, right? I would guess that the vast majority of security mistakes stem from ignorance not apathy, and that most coders are trying. Relying on people trying clearly isn't working because there's simply too much to know and it requires too constant of attention.

I think we actually do need better tooling, in terms of things like using type systems to flag sensitive data and automatically suggesting a threat modeling report include that item.

The suggestion that people spend a lot of effort all the time is clearly not going to work -- why can't we ease that barrier by focusing on better tooling so security becomes a natural part of the process, enforced by actual mechanisms?

View on HN

You can't control humans unfortunately. Humans write code, and some of them will care more about the quality of work than others do. These people will at some point work above/below/with you, and their mistakes will cause you some sort of inconvenience.

My mother taught medical school, and she had a saying... "What do you call the least qualified idiot who passes my class?", the answer is "Doctor". There are good coders and bad coders, and unless we start somehow forbidding the bad(but still good enough to get hired) ones to work with/for us - this isn't going to change.

If one developer can introduce a bug, that is life. But if it can go undetected by the compiler, unit tests, code review, component tests, acceptance tests, mutation testing, static analysis, pen test, etc, then maybe the process can be improved.

It may not be cost effective, but then it's still not a lone developer problem. It's a management decision.

> It may not be cost effective, but then it's still not a lone developer problem. It's a management decision.

That's one way of looking at the issue. Another way is that this is a way for an individual developer to stand out above his or her peers.

We've created the beginnings of this type of culture at my employer. More and more, developers reach out to the security team to point out their security conscious thoughts on how to improve new features or the existing codebases.

But, this took over a decade. It certainly didn't happen overnight. The inception for this is in training, a security team that markets itself, and in constant communication with managers.

Key to this is that devs don't set the direction of their coding projects, which is where many security teams get it wrong. The C-level on down to team managers set the direction. They need to be sold on the security team and the strategic value of their output. Just like passing functional tests, passing security tests needs to be part of a minimum viable product in a way that doesn't stop shipment of products.

> The suggestion that people spend a lot of effort all the time is clearly not going to work -- why can't we ease that barrier by focusing on better tooling so security becomes a natural part of the process, enforced by actual mechanisms?

Because, in 2017 developers need to understand more about security than they did just 3 years ago. Universities really haven't kept up with this. The reason you can't push security off to tooling, other than the minimal low-hanging fruit, is that human ingenuity is required. Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose.

> Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose.

Which is detectable through static analysis of the type signatures -- at least to the point of ensuring that a threat assessment document includes a section on what they did there.

That's my point -- why doesn't my IDE auto-generate a template threat assessment report to share with security as part of my code review process? ...why does it rely on me understanding the possible threats, rather than clearly expressing what data I use and letting security set flags on what I should watch?

That sounds like a lack of tooling -- because there's not a technical reason.

>> Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose.

> Which is detectable through static analysis of the type signatures -- at least to the point of ensuring that a threat assessment document includes a section on what they did there.

I don't think you read prior to replying. Type signatures are orthogonal to the purpose of code. Just because a call is made to XTS don't convey that disk encryption is used. That is the issue that you glossed over.

An IDE only has enough information to threat model an application correctly if it had enough information to write the application in the first place.

I think it's less about the culture and it's more about the big language developers making their languages safe by default for 90% of the developers using them.

The "culture" aspect may come in when you're encouraging people to use languages such as Rust over C++, rather than something like "always follow this 50-point security checklist no matter what language you use".

Product design, protocols, cryptography, regulatory restrictions, and so many other aspects have nothing to do with the language. Not every vulnerability stems from missing range or bounds checks.

I mean this is the best way possible, but your answer shows that even people on HN don't understand what goes into securing a product.

Every big bug I have seen has been known by a developer and not ticketed and triaged. Apathy, sometimes, ignorance more often, lack of organization, almost always

Anecdata will vary, but my experience has been those bugs get filed, marked "not important", and PMs have no way to sift the security impactful dozen out of hundreds to thousands of small defects in a large product's backlog. (And sometimes that backlog gets deleted, disappearing knowledge of those bugs.)

I'm hoping we'll eventually be able to flag bugs with the types involved, and let systems automatically look for combinations that have a set of types that could be dangerous.

My point was that it's not enough to focus on good intentions -- or culture -- you have to talk about mechanisms and technologies if you want a reliable system. Because the parts, humans in this case, are highly unreliable in isolation.

Reply on news.ycombinator.com