MOSS/Secure Open Source/Process

This page explains the process for a Secure Open Source Fund audit. The entire process is confidential until the "publication" stage, and should be kept so by both auditors and project maintainers. All email containing audit findings should be sent encrypted. (Key for Gerv.)

Planning

Mozilla will contact a project (who may have previously suggested themselves, or been suggested by others) and propose an audit. If the maintainers agree, Mozilla will select an appropriate auditor and put them in touch in order for them to discuss an appropriate audit scope. This scope may be made up of a core piece and certain optional extras, depending.

The auditors will produce a scoped plan explaining, at a high level, what they plan to do, and how much it will cost. Once Mozilla has agreed this plan, Mozilla and the auditors will execute a contract and SoW (or just an SoW, in the case of auditors getting repeat business) to cover the work. Note that the dollar amount on the SoW may be a maximum; the actual amount invoiced is determined by the work done as we go along.

Audit

The auditors will perform the audit according to the agreed plan and budget, although there is scope for modifying one or both along the way if the auditors can make a good case that particular additional work items would be valuable or particular other items can be skipped.

Once the audit report is completed, it will be sent to Mozilla (only). Mozilla will re-confirm that the project is committed to the principles of responsible disclosure, and has a process for dealing with security bugs in a way consistent with industry best practice. Once that is agreed, the report will be sent on to the development team.

Remediation

The audit report is used by the maintainers (or, by agreement, their delegates or someone found by Mozilla) to fix the issues raised.

Funding is available, at standard consulting rates, for the remediation process. However, this requires signing a contract with Mozilla, which may delay the process. In the past, some maintainers have opted to go this route, and some (perhaps those with only simple fixes to implement, or for whom the maintenance is not a normal source of income) have not. Any maintainer is allowed to make either choice.

The output of this stage is a Fix Log, which details the commits which fixed the issue (if a commit is necessary), along with any comments from the maintainers. This means it makes things much clearer if maintainers fix at most one issue per commit. Maintainers do have the option to not take any action regarding a particular audit finding, if (for example) their view is that the code is working as designed, or if fixing the issue would consume resources wildly out of proportion to the problem solved. However, the entire audit report will be published at the end of the process, even if the maintainers choose not to address an issue.

Validation

The Fix Log is then passed back to the auditors for them to validate that the fixes implemented actually do properly fix the issues found. This may well lead to a dialogue between auditors and maintainers as issues are more fully explained, and this may lead to further remediation.

Publication

Once the fixes are in and validated, and fixed versions of the software are available to users, the audit report and fix log are published and the audit is completed.