As Marco Pivetta has mentioned in his latest post to his site, Roave has released a tool for use with Composer that helps prevent vulnerable versions of software from even being installed (based on the data from the security-advisories data from FriendsOfPHP).

Since it's almost christmas, it's also time to release a new project! The Roave Team is pleased to announce the release of roave/security-advisories, a package that keeps known security issues out of your project.

The tool makes use of a "conflict" metapackage, mentioned in the Composer spec, and fails when the software and version is listed in the FriendsOfPHP information. This integration with Composer means that there's no need to run a separate tool for the checks to be made. It's integrated into the workflow and will dynamically fail without the need for you to update anything.

Joomla users may or may not know about this list of extensions on the Joomla Docs that have been marked as vulnerable to various kinds of attack. Before you install an extension, you might want to check the list to ensure you're not exposing your site to a malicious attacker.

Please check with the extension publisher in case of any questions over the security of their product. Report Vulnerable extensions either in the jforum:432 security topic or the extensions topic clearly marked with the first word in the title being Vulnerable where the security moderators or JSST team will respond. This list is change protected, for updates or editing requests Mandville or lafrance.

Each of the issues includes the extension name, a summary of what the issue is, when the vulnerability was published, a possible severity level and a link to more information about the problem. Some extensions listed also include a link to an updated version that corrects the issue.

In response to some of the claims made by CNet about the security of PHP, Ken Guest has made a few comments on his blog hoping to correct a few wrongs.

What are featuring in IBM’s top ten of vulnerable that makes the report insinuate that the PHP language is a security risk are Jooma, Wordpress and Drupal. How PHP would feature in a list of "vendors" is beside the point.

He illustrates with an allegory that it's not the tool's fault if it's used improperly. Pointing out software like WordPress and Drupal is not the same as pointing out issues with the language that powers them (no matter how trendy it is). The burden is on the developers to use the power the language offers to create more secure, flexible, stable applications. Does PHP have its share of problems? Sure, but get it right next time CNet - don't blame the tool if the builder's not up to spec.

Ivo Jansch mentions an interesting comparison that CNet made on security and levels of vulnerability in a new blog post today. Their article mentions PHP right along side Apple and Microsoft in their list of "most vulnerable software".

This article once again demonstrates the cluelessness that some people have regarding what PHP is. First of all, PHP is not a vendor, so "Apple, Microsoft & PHP" does not make much sense. Furthermore, the only reason PHP even is mentioned in this context is that Joomla, Drupal and Wordpress appear in the list. So PHP, a programming language, gets blamed for the security flaws that are in these packages.

By their logic (applications written in a language on the list means the language is more insecure), they should have marked C as a more insecure language given the ratio of PHP to C software.