Note that Ruby has rcov for code coverage and supports many build options with rake.

Of course, this is the way forward. However, scripted languages are very hard to automatically examine them, mainly because they are nothing like compiled languages. Most of the IDEs that I’ve seen which have these types of facilities work only for .NET or Java and nothing else is supported. Although it may seams that most corporate applications use something like that, the truth is that there are a plethora of things that cannot be easily ignored.

Scripting languages have one great aspect: they are focused on Test-Driven Development (TDD) to “get all the bugs out”. This is fast, works extremely well, and “drives” development to the end goal.

Unfortunately, tested code is not the end goal. Also - even more extremely unfortunately - DFT (Design for Test) gets skipped. How could Agile developers skip the most important part? Well, I guess they don’t call them script kiddies for nothing! Also see: http://www.jwz.org/doc/cadt.html

Although I would argue that “testing is fun”, especially when you find security-related bugs or flaws.

Microsoft uses the SDL, which is largely a waterfall model. The end goal of the SDL is security. Microsoft actually has a better model, where the end goal is everything everybody really wants. It’s called Design for Operations (DFO) http://www.codeplex.com/dfo/

Unfortunately, tools like VSMMD for DFO only leak out from Microsoft once every two to ten years, and usually in crippled form. Their internal tools such as PreSharp (source checker for C#), FxCop (static file checker for CLR), Magellan (code coverage), and FuzzGuru (path/code coverage with fuzz testing) - as well as their internal coding standards (esp/espx) are not well-known. Sure, they do have some public tools (that still require VS 2k5/2k8) for coding standards, SAL annotations, and model checking (AppVerif). But let’s take a look at what Java offers all as open-source.

Java, with Eclipse plugins, supports CheckStyle, FormatOnSave, and many other options for enforcing a particular coding standard. Source checkers (PMD, Jlint, Hammurapi), and static-file checkers (FindBugs, SofCheck) are available both in the IDE and in the build tools (e.g. Ant, Maven2, etc). Model checkers such as Java PathFinder, have some amazing capabilities - and even the Java-specialized tools for CI and build automation (e.g. Luntbuild) are quite complete for this type of work.

Scripters can do the same (Groovy especially), but Ruby, Python, and probably even PHP can have a more planned/focused development model and use the right tools. It’s not just Java and .NET.

IMHO, things are a bit more complicated. You say:

Before coding anything, they should have an enforceable coding standard built into their IDE. They should use source and static-file code checkers in their IDE. They should use source checkers (again), static-file checkers (again), and path/code coverage tools (e.g. concolic unit testing) that run fuzz testing across all inputs at build time, including on dependencies. They should combine model checkers and continuous integration tools (especially build schedulers), ensuring a clean release.

Of course, this is the way forward. However, scripted languages are very hard to automatically examine them, mainly because they are nothing like compiled languages. Most of the IDEs that I’ve seen which have these types of facilities work only for .NET or Java and nothing else is supported. Although it may seams that most corporate applications use something like that, the truth is that there are a plethora of things that cannot be easily ignored.

But yes, you are right. We should do it.

1) Firefox for the Internet - will not connect to RFC1918
2) Firefox for your Intranet - will only connect to RFC1918

Jeremiah Grossman suggested a way to make this more transparent, but I suggest this stricter method.

Vulnerability hunters should disclose responsibly to security, cert, noc, hostmaster, postmaster, and webmaster email addresses at top-level domains, preferably to someone who has a GPG public key available in a key server (or use something similar like Hushmail or IBE). They should also check for any incident response policies and vulnerability reporting processes the organization or website owner may already have in place. There is no reason to go to another source or through an intermediary. If all email bounces or there is no response in two weeks, vulnerability hunters should try calling a person by acquiring a phone number of an appropriately titled employee on jigsaw.com, spoke.com, or linkedin.com or from whois as a last resort. If you can find an XSS, you should know how to social engineer or footprint an email address and phone number.

Administrators should respond to and fix problems within 2 weeks (XSS moves faster than buffer overflows) or full-disclosure is fully appropriate. Like I’ve said before - if administrators can respond to an SSL certificate expiring within 2 weeks - then they can also respond to an XSS finding in the same amount of time. The vulnerability researcher can then co-ordinate a fix/disclosure schedule with the vendor and should provide remediation support if necessary. If you can find an XSS with a scanning tool, you should learn how to fix them for others.

IT administrators for users should setup the ability to whitelist URL’s (e.g. http://whitetrash.sf.net ) if they think their environment can support it. They should also ensure OS, browser, and browser plugin automatic updates. Administrators should scan and patch, just like regular vulnerability management. Good administrators will enforce use of a safe browser similar to the one described in my first paragraph.

Most importantly, developers should respond to issue tracking about XSS findings (reported by the administrators / operators) immediately as the highest priority… higher than application availability issues (24×7x365). They should always use validators that are built into their framework properly. Before coding anything, they should have an enforceable coding standard built into their IDE. They should use source and static-file code checkers in their IDE. They should use source checkers (again), static-file checkers (again), and path/code coverage tools (e.g. concolic unit testing) that run fuzz testing across all inputs at build time, including on dependencies. They should combine model checkers and continuous integration tools (especially build schedulers), ensuring a clean release.

Applications should be monitored for security events using application monitoring tools (not network security tools or log management tools) by both operators/administrators and developers.

Web Application Security Scanners and Web Application Firewalls are OPTIONAL but NOT REQUIRED.

I refer to this strategy as NTPolicy. You may use or change it however you like.