How are security bugs dealt with?

The
RIA Security - Broken By Design
presentation says: “a system is secure if it is designed to be secure and there are no bugs”
It makes a good argument that Vaadin is designed to be secure, and acknowledges that “There will be bugs”. It disappoints me that it then argues that “The
only
thing you can do is think how to avoid those bugs”. An important part of application security is how you deal with the bugs that you failed to avoid.

So how does Vaadin deal with security bugs that are discovered in Vaadin code that has already been released?
Does Vaadin follow the example of most open source projects: Be open about them, announcing them publicly?
If so, would that also include vulnerabilities that are discovered internally?
How about vulnerabilities in addons (officially by Vaadin or by Vaadin employees)?

Looking for the answer myself, what I find disturbs me a bit.

On the
Security Alerts
page I read that “The Vaadin Pro Account members get timely email notifications about verified security vulnerabilities as soon as we find out about them”. Does that mean that Vaadin users without a pro account do not get the same timely notification? Are they left vulnerable while all pro account holders already know about the vulnerability?

Searching for Vaadin security vulnerabilities from the past, I only find
a ticket, about a XSS vulnerability in the index page
, (CVE-2011-0509 I guess). In the comments there is a mention of XSS via the window caption, and via error messages. I’m surprised I can’t find more clear statements about these problems.
Mostly because it makes me wonder: Have there been other vulnerabilities too?

That’s the kind of information I was hoping to find on the
Security Alerts
page.
(Btw, it would be a good idea to include a security contact address there.)


Note that this is my point of view as a Vaadin core developer and a Vaadin Ltd employee, not an official answer:

Certainly there will be bugs, some of which will affect security. However, in Vaadin, the parts of the framework itself where bugs would be likely to have security implications are much smaller than with many alternative approaches. Of course, Vaadin cannot prevent the application developer from creating vulnerabilities in his own application, but even there the security critical parts tend to be smaller and certain types of potential vulnerabilities are not easy to create.

With respect to disclosure, any significant security bugs in Vaadin - whether found internally or by an external party - will be publicly disclosed when a fix is available, and the corresponding tickets are visible in release notes. However, Pro Account subscribers get an explicit advance notification of the issue and may have access to workarounds or custom builds before a public release with the fix is made. Furthermore, for versions older than the current stable version, builds are normally only made for Pro Account subscribers but the fix will be available in version control for other users who are unwilling to upgrade. In the case of especially serious vulnerabilities, exceptions can be made to help other users react to the vulnerability.

Several potential security issues (mostly issues permitting XSS) were found in a security review soon after Vaadin 6.0. As far as I can remember, no serious security bugs have been found since Vaadin 6.1 or 6.2.

There have also been some improvements more recently that e.g. permit changing the internal security key after login, but I would say these help users avoid possible vulnerabilities in his application in certain specific use cases rather than fix vulnerabilities present in Vaadin.

Thanks for the concern - we find security to be one of the strong points of Vaadin and thus would more than welcome all discussion about it. As Henri added a disclaimer on the opinions for being “non-official”. I’ll summarize the
official view below
.


Principles
(related to the questions) we live by:


1)
Non-paying users of Vaadin Framework will always get the same security and other fixes as the paying ones. There are no second class users or an “enterprise version” of the product with “better security”, “better quality” or “better performance”.


2)
We are as transparent as possible in our development process and communications as possible. Everything is
online
and accessible to everyone. There is one exception to this principle - if a security hole would be found in Vaadin Framework and it would not be publicly disclosed already, we will try to develop a fix to it before publicly disclosing the security issue.


3)
To be able to serve
everyone
the best way possible, we sell
support
,
add-ons tools and components
and
services
. These enable our investment in Vaadin technology and products that benefit everyone. None of the commercial product or services are
required
for productive and serious use of Vaadin Framework, but they will help paying customers to be even more productive with Vaadin Framework. Our goal is that the free Apache licensed Vaadin is the best choice out there regardless of price tag. This is the base level we build our commercial offering on. For customers who
choose
to pay, we strive to make the return for their investment best possible.


So how
Vaadin Pro Account Security Alerts
fit the picture?
We want to
ensure
that our customers always hear about any possible security issues first. This does not mean that they would hear about it before others. Information about security issues is available to everyone using Vaadin, but by sending a personal email to each
Pro Account
subscriber we make sure that they do not miss this information.

Normally maintenance releases for the latest stable Vaadin Framework version (currently 6) are done once every 2-4 weeks. Maintenance releases for earlier supported stable versions (currently 5) are much less frequent. If a critical security hole would be found, we would release a maintenance version outside of the normal release cycle to address the issue as soon as possible. On the other hand - if the issue would not be critical, we might choose to keep the normal maintenance release cycle. In that case, Pro Account subscribers would be in advantage - when others wanting to use a fix/feature before the normal official maintenance release would need to either use a
nightly build
or build the release themselves, Pro Account subscriber could use
automatically tested custom builds
containing the fix/feature even before the next maintenance release.

I hope everyone finds these principles and the above model fair. In any case - we are open for feedback on how to make the model even better.

Thanks for the clear explanation. Now it does seem a lot more fair to me than my original impression.