Oops. Resending with completed body.
It really depends on what evaluate, and what options do you have.
Doing security audits by experts is the only way to ensure your code (whether you wrote it or not) is (reasonably) secure. Most people are underqualified to do these sort of audits, myself included. Maintaining high security standard is very expensive.
For most projects, hiring a security expert to do regular security audit is in feasible. The next best thing you can do to approximate that is to rely on the experts in the community to review the key components (Ruby, Rails, etc) you rely on, and follow their recommendations as issues are discovered. (Subscribe to the security list if you haven't already.)
But then the problem is that the community is very constrained on (human) resources, and quite naturally old releases are getting less attention than the current ones. So if you are unable to move up to the current releases, and couldnt afford to hire your own reviewers, then your options are quite limited. You can probably learn some basic security principals and make sure your code and it's dependencies are not trivially exploitable, but beyond that I'm not sure it there's much else you could do.
If you are stuck on old, possibily unmainted versions, then you'd just have to bare with the risk of not getting audits/advisories/patches, and decide if that risk is more expensive than upgrading. Everyone says/would like to think that security is their top priority, but this is much easier said than done. Sometimes your application and the data it holds just isn't mission critical enough to justify the security-maintenance expense, and you'd just have to live with that.
So to reiterate, if you could afford it, it's always better to keep your dependencies up to date and run on actively maintained versions. So security-wise, Rails 3.2 is better than 3.1, and (oddly) 2.3 is better than 3.0 (but not for long); likewise, Ruby 1.9 is better than 1.8 - if that's what you're asking.
If you're asking "I'm stuck on an unmaintained version, what can I do?" Then I'm afraid the answer is not what you wanted to hear. Your best bet is to probably follow security advisories for maintained versions and try to determine if the version you're on is similarly affected and try to work out a similar patch. But then again, most people are under qualified to do that sort of stuff and it's not unlikely that you end up breaking something else in the process.
On Sunday, February 3, 2013, Clayton Cottingham wrote:
sure! who watch dogs the gems still in the system that are inactive, no longer useable etc? why arent they removed from the gem repos??
CPAN for perl does this sort of check, if a perl module fails it isnt allowed to be searched and used, but one can still download at their own peril, its just not available through cpan interface
moving to 3.2 isnt always a choice. clients are running what they are running and moving to a new version of rails is a daunting task for some and sometimes time and money are involved
there has to be a less confusing way to evaluate these issues?
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Clayton Cottingham ([address removed]) from Vancouver Ruby Meetup Group.
To learn more about Clayton Cottingham, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages
Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]