There are a number of differences between our approach (closed source but with paid peer reviews and security analyses) and the open source approach. CVE handling is arguably a critical difference, but we shall start with general arguments first.

General arguments for and against open source

Common arguments in favour of open source encryption software are:

1. The source code is available so you can inspect it.
2. If anyone finds faults with the code, it can be fixed rapidly and by any developer (subject to license terms).
3. Developers can fork or branch source code and start their own development, or contribute to the development team.

The problem with these arguments are:

1. Even if source code is open source, few people possess the qualifications and the time to inspect the source code. By way of example, the now-defunct TrueCrypt project was launched in 2004, and yet was not audited for many years, with formal audit reports only released in February 2014 and March 2015 – some 10 years later.
2. Forking source code can be dangerous if the contributors are not suitably qualified to manage the code, and merging development from the main trunk into branches is onerous and ongoing.
3. Despite the stated virtues of open source implementations, vulnerabilities are still discovered on an ongoing basis.

Our adopted model is to have our designs and implementation designed and peer-reviewed by appropriate experts prior to release. We also, on an ongoing basis, commission audits to ensure the quality of our code and designs.

Thus, you could say that Scram takes a proactive approach to security, whereas the open source model tends to be more reactive.

CVE-handling process

The CVE handling process is one area of significant difference between closed and open source.

General CVE-fixing process in the opensource project is follows:

1. Someone finds a vulnerability and reports it in a private email to the project maintainers. Public exposure is not good from the ethical point of view because hacker does not give maintainers time to create a patch fixing the vulnerability.
2. After some time, project maintainers provide a patch, publish CVE and send a email to mailing lists that urgent security update is required.
3. Software users get the update after some delay, because software have to re-build, tested, packaged, deployed, shipped on user’s computers - every step takes some time - from minutes to days.

Between steps 2) and 3) user remains completely unprotected against hackers that can exploit recently posted vulnerability - hackers know the details of the security flaw, see the source code that fixes it - writing an exploit is a minute-to-hour task if the vulnerability is exploitable.

Closed source CVE handling allows software vendors to handle the situation better. They can provide a security fix before publishing CVE details. Firstly, all clients can be patched and protected protected against the threat, and only then will the details of the CVE be published.