Free Software Audit

Our expectations for a Free Software security audit

How to get more Free Software in the public administration

Public bodies have to implement concrete measures as soon as possible. Standard decisions dominate public bodies choice of software for several years, possibly decades. The most important factors for this are:

1. use minimalistic standards which can also be implemented by Free Software. First it needs to be a real Open Standards. Second it needs to be minimalistic; the two central questions hereby are (see minimalistic standards):

2. enforce that whenever software is written with public money, that this software has to be published as Free Software.

Misc concerns and suggestions

Three parts of an audit (additional information)

Processes (long term)

What processes were used to develop the software (traditional waterfall model, SCRUM,...)? How is a requirement / user story identified, managed and tracked? How is a requirement / user story transformed into a software design and finally into code?

How does the way of a patch to the mainline code base look like? What quality gates are there before a patch can enter the next stage (on its way to the code base)? How do the processes look like at the different quality gates? Who decides whether a patch is allowed to pass a quality gate and how?

How formalised are these processes? How transparent are they?

Free Software licence and the use of well defined minimalist Open Standards per se are already a necessary precondition for having transparent processes in a security relevant project.

A transparent and open development model with well-defined processes (bug tracker, easy ways to submit patches,...) and a good quality assurance is really helpful. (It is not always the case in Free Software that an open development method is used, see Point 1 in <https://fsfe.org/freesoftware/enterprise/freesoftwarecompany.en.html>)

Software architecture (middle term)

Does the software have a carefully thought out software design (at best, it is even specified and documented)? Are there well-defined interfaces? Does the software make use of well-defined minimalistic Open Standards?

Especially when it comes to cryptography: Does the software make use of cryptographic methods, algorithms and formats that are well-analysed and recommended by the world-wide cryptographic community (with recommended and strong enough cryptographic parameters)?

Does the software design include a security concept with a well-defined thread model? (In general, a non-security related software can even have a nice, but highly insecure software design if security is simply not considered.)

Apart from a good software design in general, in a security related software project, it is important to a have good security concept with well-defined attacker and threat models. If the software project does not specify a security concept, the reviewers should consider formulating one.

Code (short term)

How does the code look like? Is it well-structured and clearly written? Does it make use the of the standard methods of the programming language or does it over and over re-invent the wheel (which is much more error- prone)?

Does it comply to standard security coding guidelines (e.g. always validate the input, correctly initialise variables, always use secure variants of standard library functions, if you do bash scripts, unset the PATH variable and explicitly specify all the binaries you execute, ...)?

This area is highly language specific and there are many really good guidelines, such as (Herb Sutter, Andrei Alexandrescu: C++ Coding Standards: 101 Rules, Guidelines, and Best Practices. Addison-Wesley.) or the CERT Secure Coding Standards.

One rule of thumb to apply when doing code reviews or when writing software yourself is: If there are conflicting goals, go for

  1. explicitness, clarity and readability first, then comes
  2. code elegance, and only then follows
  3. performance.

Policy/FossaComments201507 (last edited 2016-07-11 07:27:19 by mk)