I previously wrote about Secunia’s PSI tool to help you keep your desktop updated. Secunia has another good use: checking up on software security history. Looking at a software’s security history is a good step in any software selection process.
Security History
I always encourage people to research a web application’s bug and security history as a part of the software selection process. Few software products are free of security issues. The key item is how quickly the vendors reconcile the problem and how often the same type of issues repeat. Searching for a software title at Secunia can let you check up on a products security history.
Security Alerts
Though there are many outlets for security information, I’ve found Secunia’s one of the easiest to use. Security alerts are often assigned a CVE-identifier or a code to help track the issue. The CVE code helps standardize the report of a security items and allow various web sites to assure they are discussing the same issue.
The US Government maintains the NVD or National Vulnerability Database which keeps track of security bugs. Securityfocus also maintains a system called BugTraq. Often data between various sources is cross-referenced to help keep track of the issue.
Red Flags
If you search for a product, PHPList for example, you will get a history of security items. A key thing I look for is unresolved critical issues. If the exploit was recently identified, the vendor may not have fixed it yet. But for PHPList, you see that there are exploits from 2005 that have yet to be addressed.
Now Secunia or other exploit lists are not definitive. The software vendor/author may have released a new version or simply failed to have closed the CVE issue. So you should always check the vendors web site. They typically maintain a change log and will often address the security issue directly by including the CVE number. The PHPlist site, unfortunately, does not have any clear security information or any indication that the author has addressed the issues in the CVE list.
In my experience, reliable vendors and authors quickly address security issues. If software has a long open critical issue and the product’s web site does not include any additional information, I am wary of using such software. If alternative programs exist, I may consider using them first. This is not a killer in a software selection process but something I certainly consider.
Recurring Issues
Another thing I watch for is the recurring issues based on the class of exploit. Typically, security issues fall into a class of exploits.
SQL injection is a common security issue. If you see a program has repeated SQL injection vulnerabilities, this may point to an underlying problem with how the application was programmed. Poor programming practices can lead to SQL injection problems. Good programmers will often scan their code to assure a similar issue does not exist in other parts of their applications.
I often see a patch for an XSS exploit and then a few days later another patch for another XSS exploit. Often this is the result of the programmers going over their code and looking for similar issues to the initial exploit. This is a very good practice. So you may see a rash of XSS exploits in a history report and then a pause in XSS issues. This may signal a good security practice.
Software Selection
So when you go to find that cool blog, email or cms tool, I recommend checking the security history for a product. More popular programs will likely have more exploits simply due to increased usage and scrutiny, so the number of exploits is not as important as how they are handled.
One of the most common requests I get is for a secure form to email processor, I’ve been recommending Tetcite’s Formmail program. To date, I’ve not known of any exploits for it.