There is a general lack of understanding. OWASP is a shambolic volunteer project and its outputs are uneven at best. I would be particularly wary of OWASP when it comes to specialist topics, and cryptography is a great example of that.
At least for software security, this is probably the best single reference you'll find to get from level 1 to 2 (assuming zero is your origin), regardless of ptacek's largely unfalsifiable objections. Absent from these comments are any other software-security-specific recommendations -- though if you're looking for something more holistic rather than just being siloed to software security specifically, you may consider following NIST CSF to start and then exploring mitigating common patterns exposed in the ATT&CK framework.
If you're looking more for guidance on what other companies are doing for securing development pipelines, probably BSIMM. Bear in mind it's the product of a consulting firm, and all it does is tell you the things others do, not necessarily what's actually effective (descriptive v. prescriptive). The result is that it may be tuned to steer consulting traffic their way. Full disclosure: I've consumed that consulting service at two firms thus far.
It is frustrating working in an environment where the ASVS is held up as infallible...
I appreciate that the documents are helpful as appeals to authority to win dumb arguments and am not saying you shouldn't do that! But it is weird for me to hear that people outside my field take ASVS especially seriously.
I understand and largely agree with your technical gripes though I regret to say I'm not really convinced by your position. That said, I agree with an unstated corollary to your point: 2.4.5's listing as a L2 control is not appropriate (L3 would be better where this requirement even makes sense), and this specific recommendation should be traded for an alternate prescription in favor of credential-specific hard-i.e.-long salts, because most environments outside the ones NIST cares about actually have the capability to follow the state of the art rather than hack together a solution to fit processing constraints.
---
To your point about mature security programs: you're entirely right. Without those resource constraints, I'd build a program modeled off of real world threats and attack surface as well as actual usage and abuse. No need for a general prescription when I can diagnose my specific shortcomings. You and I are in agreement there. (Talks like "using vulnerability trend analysis to guide holistic security uplift" by salesforce come to mind)
---
Responding from mobile. Please pardon any typing defects. And if you're at Security@ today, I'm up to chat more over foods.
Security vulnerabilities in Web applications have been a major cause of big losses at a large number of these companies.
Despite that, the most authoritative, best funded, Web application security group is OWASP. A group with a full-time staff of < 10, and an annual budget of well under $10M.
It's interesting to me anyway, that the wider IT industry doesn't see value in trying to establish security practices and tooling which could be used to reduce some of these losses. Even if they don't like OWASP itself for any reason, that they don't look to establish something else to achieve the same goal.
Have you considered contributing recently?