On the ServerGrove blog there's a new post looking at some of the currently available PHP security tools you can use to help keep your applications safe.

Security is getting more and more important, and the PHP community has been doing great improvements in this topic during the last few years. From better configuration settings to provide some level of security by default to frameworks providing functionality to avoid common attacks such as XSS, CSRF or SQL injection. [...] Well, any piece of software can have bugs, and obviously open source projects are not an exception. The good point is that security researchers, once they find a vulnerability, it is reported and added to a database of known vulnerabilities. We basically need to find a way to avoid using code with known vulnerabilities, and there are some interesting tools out there to help us.

They list four tools that focus on different areas of the security of your application to help provide good basic coverage:

• Security Advisories Checker
• Roave Security Advisories
• iniscan
• versionscan

One thing to note, these are all automated tools so they shouldn't be relied upon exclusively to ensure the security of your application. Testing and evaluation of the codebase with these and other testing tools should always be done as well.

Pádraic Brady has a new post today proposing that what the PHP ecosystem needs is a way to better publish security disclosures in a format that's easy to parse and deal with.

This is a branch off from a separate discussion on the PHP-FIG mailing list about other ways the Framework Interoperability Group can encourage and foster wider interoperability among its member projects (and by extension, the whole PHP community). I’ll start by noting two interesting developments in recent months and one long standing best practice.

The two "interesting developments" he mentions are the relatively recently released SensioLabs Security Checker that uses you Composer file to find security issues and the new entry in the latest version of the OWASP Top 10 list for "Using Components with Known Vulnerabilities". The best practice he talks about is more around the timely/responsible disclosure of vulnerabilities and how some kind of decentralized tracking of these issues that puts the responsibility back on the developers of the tool and not on one tracking resource.

In his latest post Fabien Potencier introduces a new effort to help PHP developers using Composer for their dependencies find potential security issues automatically - the security.sensiolabs.com site.

I want to provide a simple and efficient way to check for vulnerabilities in a project and I want to serve more than just the Symfony community. That's why I'm really proud to announce a new SensioLabs initiative: a simple way to check if your project depends on third-party libraries with known security issues. The website explains how it works in details (https://security.sensiolabs.org/), but basically, this initiative gives you several ways to check for security issues in your project dependencies based on the information contained in you composer.lock file (you are using Composer to manage your dependencies, right?)

Composer users can upload their "composer.lock" file and the system will evaluate it against the vulnerabilities it knows about and return any issues it might find. The current database is hosted on github and can be added to by anyone using a pull request. Additionally, you can install the command-line version if you want to do checks locally.

On the Blue Parabola blog Matthew Turland has written up a post about working with the CDC, the Ceres Document Checker - a project he's developed to check documents based on the Ceres document format.

If you've written or done editing for php|architect before, you're probably familiar with the custom markup format they use called Ceres, which looks a bit like Markdown. Both articles and books use it, though each has slightly different formatting requirements. Some of these requirements can be tedious to check for and easy to miss. As much as I've been working with documents in the format, I decided to write a tool to help me out.

He outlines the requirements he wanted to follow including that it could be run from the command line, that it could detect code blocks, it could perform lint checks on the code samples and it could give a rough word count excluding code. He also includes his three methods for processing - finding a file and checking it, recursing through a directory and finding files matching a regular expression.

Files are pulled in and processed line-by-line until a code block is reached. This is processed via a regular expression and the script continues on. If you're interested in the code, you can check out the latest version from the project's github page. There's also a TextMate bundle (written by Davey Shafik) for those users of the TextMate editor.