Should We Trust Frameworks?

In light of Fortify's recent study of FLOSS libraries and frameworks for Ajax with regards to Javascript Hijacking, I thought I would provide some help in making decisions on whether to use a framework/library/API, or to roll your own for what it is you're doing.

Obviously, it would be foolish of me to have a "sky is falling" mentality about the findings, but there are some common-sense things to keep in mind when selecting an API or writing a new API for what you need to do.

• New is not always better. It's just new. This applies to API's and technologies both. For example, when some FLOSS project releases a brand spankin' new Ajax library, that doesn't mean it's better than everything else out there.
  
• Do you need a new technology? Is Ajax really going to substantially improve your user experience? Or are there other features that should be implemented first? Whatever the new technology is that you hope to implement with the API, evaluate your need for the technology in general before you even go to selecting a tool provider.
• Is the provider a trusted source? This is becoming harder to deal with as really rich, interactive web UI's are becoming the norm. Several years ago, there was a shift to making large improvements for the sake of developers, and MVC was going mainstream in webapps. After a few years, a handful of really good MVC frameworks emerged. Can you wait that few years for the really good new framework to emerge?
• I don't have a metric for this, but is there a "number of man-hours invested into development" appropriate for the function the library provides? For example, are you going to pick an API by a guy who spends a couple of hours on the weekends developing the tool, or something where there's a really active development team spending a total number of hours far exceeding the one guy? More is not necessarily better, but in the FLOSS community, really active projects generally get a little more momentum in getting things fixed.
• Is the API/toolset extensible? This is a huge one for me. I want to like Ruby on Rails, but I have a real problem with key exposure. And I have a real, real problem with not being able to work my way to the internals to make Rails work with a layer of indirection without having to write all my apps to use it - end result, it's just as quick for me to write my apps in a "slow" framework where I can change as necessary.
• Has the provider responded to findings in the past? Do they fix security things? Or do they ignore them and possibly provide documentation so you can fix it yourself?
• Will the API save you enough time and give you enough flexibility to outweigh the benefits of writing it yourself? I can't phrase this in the right way strongly enough. Fortify found problems with a lot of Ajax libraries. But they are far more likely (the active ones, anyhow) to fix the problem and fix it right than you are, unless you're one of them. Not an insult to you, but if you're really good at writing applications, try to spend your time doing that, rather than writing your own frameworks.

The question on the last point probably came out wrong. If you even think for a moment that you can write the API yourself, please reconsider and look into some of the more mature API's and frameworks out there. I think all of us who do security assessment have seen too many opportunities to use good API's go by the wayside and be replaced with home-grown API's that are really deficient. The two things in the past that I still see come to surface are home-grown crypto API's (really bad idea), and home-grown MVC that almost always have directory traversal, forced browsing, or arbitrary object instantiation issues.

So, even though Fortify found some problems with the frameworks out there, please consider using one of those. But before you consider using one of those, consider whether it's really time to implement that shiny new technology at all. You might have better functionality that you can provide without committing to something that's really immature right now.