SCM(security) Team 5

The Security Basics
Fundamentally, there are some basic (potential) security requirements that any system needs to consider. These are:

• confidentiality: are only those who should be able to read information able to do so?

• integrity: are only those who should be able to write/change information able to do so? This includes not only limiting access rights for writing, but also protecting against repository corruption (unintentional or malicious). Changesets must be made atomically; if 3 files change in a changeset, either all or none should be committed.

• availability: is the system available to those who need it? (I.E., is it resistant to denial-of-service attacks?)

• identification/authentication: does the system safely authenticate its users? If it uses tokens (like passwords), are they protected when stored and while being sent over a network, or are they exposed as cleartext?

• audit: Are actions recorded?

• non-repudiation: Can the system "prove" that a certain user/key did an action later? In particular, given an arbitrary line of code, can it prove who was the individual that made that change and when? Can it show all those who approved/accepted it, as a path?

• self-protection: Does the system protect itself, and can its own data (like timestamps, changesets, other data) be trusted?

• trusted paths: Can the system make sure that its communication with users is protected?

• resilience to security algorithm failures: If a given security algorithm fails (such as the hash function or encryption), can the algorithm be easily replaced to protect past and future data? (Added 2005-03-02, after the revelation of serious problems in SHA-1).

• privacy: Is the system designed so it's not possible to retrieve information that users want to protect? For example, spamming is a serious problem; it may be desirable to NOT record real email addresses, at least in some circumstances. If there is a "secret branch" where security patches are located, try to not store its location in the dataset. This is similar to confidentiality, but you might not even trust an administrator... the notion is to NOT store or depend on data you don't want spread.

An SCM has several assets to protect. It needs to protect "current" versions of software, but it must do much more. It needs to make sure that it can recall any previous version of software, correctly, as well as the audit trail of exactly who made which change and when. In particular, an SCM has to keep the history immutable - once a change is made, it needs to stay recorded. You can undo the change, but the undoing needs to be recorded separately. Very old history may need to be removed and archived, but that's different than simply allowing history to be deleted.