[the following is a guest diary contributed by Russ McRee]

Given the extraordinary burst in headlines over the last six months relating to "hacktivist "exploitation of web application vulnerabilities,  Critical Control 7: Application Software Security deserves some extra attention.

The control describes WAF (Web Application Firewall) use, input validation, testing, backend data system hardening, and other well-defined practices. Not until the 6th suggested step does the control state: “Organizations should verify that security considerations are taken into account throughout the requirements, design, implementation, testing, and other phases of the software development life cycle of all applications.”
For your consideration: it can be argued that, as a canonical principle, strong SDL/SDLC practices woven into the entire development and deployment process leads to reduction of attack vectors. Reduce said vectors and mitigations provided by enhanced controls become less of a primary dependency. Long story short, moving SDL/SDLC practices to the front of the line, while not a “quick win,” can be a big win. That’s not to say that SDL/SDLC replace or supplants controls, but a reduction in risk throughout the development process puts the onus on secure code where controls become an additional layer of defense rather than the only layer of defense.
One of the advantages to a strong SDL/SDLC practice is the prescription of threat modeling where classification schemes such as STRIDE or DREAD help identify issues early as part of the development lifecycle rather than reactively or as part of controls-based activity.

OWASP offers excellent resources to help with SDL/SDLC efforts.

• https://www.owasp.org/index.php/Security_Code_Review_in_the_SDLC
• https://www.owasp.org/index.php/Threat_Risk_Modeling

As you take a look at testing “in-house-developed and third-party-procured web applications for common security weaknesses using automated remote web application scanners” don’t fall victim to vendor hype. Test a number of tools before settling on one as some tools manage scale and application depth and breadth very differently. If you’re considering monthly or ongoing scans of applications that may serve thousands of unique “pages” but with very uniform code, you’ll want a scanning platform that can be configured to remove duplicate items (same URL and parameters) as well as items with media responses or certain extensions.
There is a wide array of offerings, commercial and free/open source, so test well and consider that you may want to consider more than one particularly if you’re considering inexpensive or free. Static code analysis tools are more often commercial but there are some free/open source offerings there as well. Plenty of search results will get you pointed in the right direction but again, test more than one. The diversity of results you’ll receive from different tools for both dynamic and static testing will surprise you.
Always glad to share experience with some of the tools in these categories should you have questions via russ at holisticinfosec dot org.

Takeaways:

• A strong SDL/SDLC program reduces dependencies on controls.
• Test a variety of dynamic and static web application testing tools.