
Open Web Application Security Project issues new secure coding bible - elfalfa
http://www.theregister.co.uk/2016/01/12/owasps_revamped_developer_guide_will_help_you_pass_pen_tests/
======
moron4hire
Seven years ago, I used the OWASP guidelines to start a greenfield project for
a brand new client at the consultoware company I was working for. The project
required compliance with several government regulations, including HIPAA and
Sarbanes-Oxley, with planned auditing.

I was new there, but not new to software development. I ignored the other
developers in the company "ordering" me to use their existing codebase. I had
not been very impressed with their home-rolled auth system, including plain-
text passwords. I got around it by hacking together a mockup that looked like
it was using their site template, so they just assumed the rest of the project
was built on it.

I kept myself a scorecard on how I was doing against OWASP's Top Ten. Six
months later, we got a surprise early audit, everyone freaked out, but I
chilled because I knew we were good. We passed with flying colors. The
software also just so happened to be the best-performing project in the
company (which isn't really saying much) and everyone was scrambling to scrap
their codebases and build on mine (which itself is another problem). It became
the only project in the company to have more than two developers working on it
at any one time (I had three people under me! Wow!). The documentation I wrote
for it--which was mostly just explaining OWASP and what it meant in regards to
our technology stack--became the gold standard in the company.

Now, this is not at all to say this was a great feat. But if you're working in
the sort of consultoware shop that can't seem to keep anyone with more than 5
years of experience under their belt (which is a lot of people), you can do
far, far worse than following OWASP religiously.

I eventually left when it became clear I was the "mule that works", i.e. "you
don't beat the mule that doesn't work." It was rationalized that, because we
were doing so well, instead of putting more resources into my team to double-
down on our track record, it would be better to scatter the team around to the
poorer projects, apparently under some plan that success is catching or
something. Also, management still expected me to maintain the project on my
own at the same productivity level as four people.

------
tptacek
Be careful.

The OWASP Top 10 is a somewhat useful benchmark and an easy way of
communicating the general concept of web application security to people; it's
especially useful when an assessment might involve both web security and other
stuff, and you want to be clear that you're just poking at the web stuff.

Apart from that: OWASP is not a very reliable resource. The project has given
some genuinely bad advice over the years. In particular: don't rely on any
advice they give about cryptography.

~~~
moron4hire
Whose fault is that, then? If you know so much about crypto, and you know
OWASP's info on crypto is bad, then why haven't you contributed?

This is the problem with crypto experts. You're all "find a crypto expert".
But you just sit there on your thumbs and don't contribute in any way other
than building libraries with such bad UX that lead to more "find a crypto
expert" advice.

~~~
tptacek
That's a self-evidently dumb comment, but in fact I've had experience trying
to talk to OWASP about crypto, and found it an enervating waste of time.

Things may have gotten better in the last 2 years since I stopped paying
attention (though: I doubt it), but my experience of it is that it's governed
mostly by the kinds of consultants who parachute into projects to configure
Fortify. Despite not having much software development experience, those kinds
of consultants have very strong opinions about things like crypto.

The problem is very much not limited to crypto.

I think OWASP is mostly unsalvageable, and that the most productive thing to
be done is to warn developers to take their advice with a grain of salt.
There's useful stuff in there, but there's bad stuff too. That's fine if all
you're purporting to build is a wiki, but it's less fine when your goal is to
be the bible of appsec. They are simply not that.

~~~
sarciszewski
Let me offer a concrete example of the attitude Thomas is referring to:
[https://github.com/OWASP/phpsec/issues/108](https://github.com/OWASP/phpsec/issues/108)

Highlight:

    
    
        Kerckhoff's principle applies to cryptography, not
        application security. 
        
              - AbiusX, OWASP project leader for PHP Security
    

[https://github.com/OWASP/phpsec/issues/108#issuecomment-1596...](https://github.com/OWASP/phpsec/issues/108#issuecomment-159689730)

------
blakesterz
The actual PDF is here:
[https://www.owasp.org/images/6/67/OWASPApplicationSecurityVe...](https://www.owasp.org/images/6/67/OWASPApplicationSecurityVerificationStandard3.0.pdf)

It actually came out last fall. Only 70 pages, not a bad read really.

------
peterwwillis
Does anyone here work on a project that _isn 't_ a security product and
actually codes it to be secure from the start?

~~~
sarciszewski
Yes, I'm building a CMS, but it's not released yet. :(

------
pm24601
I found the recommendations a nice checklist to work through. They may not be
complete or the best. But they are a start.

