During the security talk at Apache Con a topic commonly glossed over bydevelopers was covered in quite some detail: With software being developed thatis being deployed rather widely online (over 50% of all websites are poweredby the Apache webserver) natually security issues are of large concern.

Currently there are eight trustworthy people on the foundation-wide securityresponse team, subscribed to security@apache.org. The team was started byWilliam A. Rowe when he found a volnarability in httpd. The general work mode -as opposed to the otherwise ``all things open'' way of doing things at Apache -is to keep the issues found private until fixed and publicise widelyafterwards.

So when running Apache software on your servers - how do you learn aboutsecurity issues? There is no such thing as a priority list for specificvendors. The only way to get an inside scoop is to join the respectiveproject's PMC list - that is to get active yourself.

So what is being found? 90% of all security issues are found be securityresearches. The remaining 10% are usually published accidentially - e.g. byusers submitting the issue through the regular public bug tracker of therespective project.

In Tomcat currently no issues was disclosed w/o letting the project know. httpdstill is the prime target - even of security researchers who are in favour ofa full disclosure policy - the PMC cannot do a lot here other than fix issuesquickly (usually within 24 hours).

As a general rule of thumb: Keep your average release cycle time in mind - howlong will it take to get fixes into people's hands? Communicate transparentlywhich version will get security fixes - and which won't.

As for static analysis tools - many of those are written for web apps and assuch not very helpful for a container. What is highly dangerous in a web appmay just be the thing the container has to do to provide features to web apps.As for Tomcat, they have made good experiences with Findbugs - most others havetoo many false positives.

When dealing with a volnarability yourself, try to get guidance from thesecurity team on what is actually a security volnarability - though the finaldecision is with the project.

Dealing with the tradeoff of working in private vs. exposing users affected bythe volnarability to attacks is up to the PMC. Some work in public but call theactual fix a refactoring or cleanup. Given enough coding skills on the attackerside this of course will not help too much as sort of reverse engineering whatis being fixed by the patches is still possible. On the other hand doingeverything in private on a separate branch isn't public development anymore.

After this general introduction Mark gave a good overview of the good, the badand the ugly way of handling security issues in Tomcat. For his slides(including an anecdote of what according to the timing and topic looks like itwas highly related to the 2011 Java Hash Collision talk at Chaos CommunicationCongress).