3 ms·

My complaint isn't about the quantity or quality of security research. By definition security professionals should be up to date on the state of their art. As a

• cratermoon 5y ago
  Well, I work in security. Identity and access management specifically. So ponder this, if you wish. It's hard to have a discussion about security recommendations with decision makers without getting pushback over costs, time, complexity, and so forth. So of course it's always good to be able to say what problems the recommendations prevent, and give them some idea about the tradeoffs for not doing it. But decision makers rarely involve security people up front. In most shops, security is an afterthought. You see, organizations build a website, or an app, make it work, and then go, "oh, hey, now we need a login for our users". At that point, there's almost always a slate of things that have been done that ought to be corrected before further work, otherwise you get what I call "sprinkling security sugar on top of a pile of manure". Yeah, you might get to a point where it's palatable, barely, but it's still a steaming pile. Some of the things that make the work a steaming pile can be addressed by positive recommendations, but a great many are things that just need to go away. At that point, you're right, the conversion is going to largely be "don't do X, Y, and Z". The question then, is, why not make the OWASP tool or other linter part of the development process from the beginning, rather than wait until it's all done and then ask a security professional to evaluate for you? Imagine writing a letter or spec by just typing and adding stuff without checking your spelling and grammar along the way. Now hand it off to an editor. Would you expect the editor to provide a bunch of advice about how to do things after the fact? No, the time for that past. The editor is going to point on the flaws, the misspellings, the grammar errors, and worse. Does that sound like saying "don't do that"? Would you be mad if the editor just ran ispell and a grammar checker and said, "fix these things"? My constructive advice, then, is that you engage with your security professional before starting work, ask them for their input, and follow it. Not without asking questions about relative risk vs cost, of course, but giving them their due for being the expert in the art and having knowledge and context which takes years to acquire and put to work.
  • User23 5y ago
    > My constructive advice, then, is that you engage with your security professional before starting work, ask them for their input, and follow it. You sound exactly like the kind of security professional I’d like to work with and I agree with everything you said. To give you an idea of my lived experience, I’ve actually had security team members refuse to disclose the tools they are using. This baffled me, because as you say why wouldn’t they want developers to run linters as part of their process? The only possible explanation I can think of is that being a human frontend for automated tooling is an easy high paying job.