Recent developments have provided additional configuration options to allow a more relaxed security profile than is provided by default.

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

• Confidentiality: projects may be configured so that only authorized staff are able to read their source files or access their history. It is even possible to conceal a project's existence from other users on the same computer.

• 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.

• Integrity: Aegis has separate ACLs for developers, reviewers and integrators. Various operations during the lifetime of a change set are limited to one or other of these roles.
• Integrity: It is possible (and recommended) that the project repositories (history and baselines) be read-only to all project staff. The rest of this discussion will assume this facility is being used. All operations which modify the repository are mediated by Aegis.
• Integrity: The meta- data files cannot be edited by project staff.
• Integrity: The history files cannot be edited by project staff.

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

• Availability: Aegis relies on the host computer's facilities for this, including backup of its meta-data and repository.

• 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 clear text?

• Authentication: Aegis relies on the host operating system for this. Once the operating system has authenticated a user, Aegis trusts the operating system.
• Authorization: Aegis has separate ACLs for each project for each role (developer, reviewer, integrator). Only authorized users may advance a change set through the process.

• audit: Are actions recorded?

• Audit: Aegis records all actions by all users who advance a change set through the process, including the user's identity, what they did and a time stamp.

• non-repudiation: Can the system "prove" that a certain user/key did an action later?

• Non-repudiation: Because Aegis relies on the host operating system to authenticate users, the non-reputation features of the operating system carry over to Aegis.

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

• Self-protection: The recommended mode of operation, where the projects repository (history and baselines) are read-only to the entire project team, means that all changes to the repository are mediated by Aegis. Thus, Aegis can trust that its meta-data is untainted (it can't defend against root privilege).

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

• Trusted paths: Aegis has a number of features which facilitate geographically distributed development. By using tools such as OpenPGP or GnuPG when change sets are in transit, as much or as little protection as desired can be achieved.

Most aspects of Aegis' meta-data are immutable. Only project administrators may change the description of a change once it has been committed to the repository (developers are notoriously bad at accurately describing their changes); project administrators cannot alter any information about the file histories or the various users and time stamps the change set has accrued.

The default configuration is medium paranoid. It is possible to increase that to extremely paranoid (or extremely officious, depending on your perspective), or weaken it to merely be helpful.

However, this leaks the existence of the project. By using the AEGIS_PATH environment variable, telling Aegis where to look for projects, it is also possible to conceal the existence of a project.

Aegis has separate ACLs to developers, reviewers and integrators, limiting the number of users who can modify the project - but even then, they must follow the process.

It would be possible (although this isn't the case at present) to add code to Aegis to allow "anybody" to be a change set developer. It is probably most undesirable to allow "anybody" to be a code reviewer or integrator.

Aegis breaks the traditional "commit" step into several pieces. Large project are able to be configured to require a user other than the developer to perform the code review step (this is the default). Thus, it is safe for naive developers to modify any source file they like, but they have to get it past a code reviewer before it will appear in the repository. There are facilities in Aegis to require specific code reviewers for specific portions of the code.

• Make sure that developers can't corrupt the repository. As a counter-example, GNU Arch allows developers to share a writable directory as a repository. That's very convenient, but if you're worried about malicious developers, that's not enough; a malicious developer could easily remove data or corrupt it in such a way that it'd be hard to tell who caused the problem (there's current effort to create an "archd" server that would probably counter this problem).

• The recommended Aegis configuration has the history files and the project meta-data read-only to the entire development team, even users authorized to integrate change sets into the repository. All operations which advance a change set along the process are logged, including the final one which actually alters the change set's files' histories.

• Make sure that all developer actions are logged in a non-repudiatable, immutable way. That way, even if someone makes a change, it's easy to see who made what changes, in any time in the future. That "someone" may be a malicious developer, or an attacker with the credentials (e.g., cryptographic keys) of a developer -- but in either case, once you find out who did a malicious act, the SCM should make it easy to identify all of their actions. In short, if you make it easy to catch someone, you increase the attackers' risk... and that means the attacker is less likely to do it. In practice, this can be done by requiring that all changes be cryptographically signed by each developer. Implied here is that there is an easy way to undo those changes; after all, if it's easy to identify exactly what a developer did, they can be undone.

• All operations which advance a change set along the process are logged. There are no facilities for removing this meta- data, and the meta-data files themselves are read-only to the entire project team.
• The non-repudiation of logged change set events is limited to the ability of the operating system to provide non- repudiatable user authentication.

• Make sure all developer actions can be easily reviewed later. A simple action to show exactly what's been changed recently will make it easy for new changes to be reviewed - and possibly set off alarms.

• Aegis provides numerous ways to review change sets and/or files. You can obtain a listing of all historical events for a change set. You can obtain a listing of all historical events for a file. You can obtain a listing of all change sets applied to a project to data. You can get "blame listings" for files.

• Have tools to record and/or require others' review. If you really want to make sure that malicious code doesn't get through, the best method known is to make sure that some other person (who is unlikely to be colluding) reviews the code. Thus, ways to cryptographically sign that a person reviewed anothers' changes can be helpful, as long as the reviewer's signature can't be forged, and as long as the signature clearly indicates what was reviewed. A review could be at a brief "I briefly scanned for malicious code" all the way to "I deeply analyzed every line for correctness", so the SCM tool should support recording to what level the review occurred too.

• By default, Aegis requires code reviews; it is possible to configure them away. It is possible to require several code reviewers for a change set, or specific code reviewers for portions of the code. The review policy is highly configurable.
• There are several "hooks" that can be used to perform automatic checking for change sets: the build hook, the diff hook and the review policy hook.

• Support automated checking before acceptance, including detection of suspicious/malicious changes. An SCM system should make it possible to enforce certain rules before accepting a change (at some level): such as enforcing formatting rules, requiring a clean compile, and/or requiring a clean run of a regression test suite (in a suitably protected environment). It should be possible to watch changes to find "suspicious" changes: the first time that developer has modified a given file, code that looks a like a Trojan horse, formatting/naming style that's significantly different than this developer's normal material, attempts to send email or other network traffic during a code build, and so on. This is basically intrusion detection at the code change level. It should also be possible for an automated process to quickly check for hints of "stolen" code before accepting anything (e.g., to detect copyright-encumbered code), by calling to programs such as Eric S. Raymond's comparator.

• Aegis provides the ability to prevent a change set from advancing to code review until it builds successfully.
• Aegis provides the ability to prevent a change set form advancing without a unit test and the test must pass.
• Aegis provides the ability to require a bug-fix change set's unit test to fail against the unaltered code baseline, to confirm that the test accurately reproduces the bug.
• Aegis makes it simple to run all of these accumulated tests against a change set's private work area to confirm that the change set will not break anything.
• It is possible to have Aegis suggest suitable tests to run for the files in a change set, based on the correlation between source files and accompanying test files in previous change sets.

• Support authentication/cryptographic signature key changes and re-signing. No matter what protection is put in place, a developer's secrets (e.g., their login passwords or private keys) may be acquired by an attacker. Thus, an SCM (along with its support environment) need to support changing such secrets. In particular, it may be useful to "cycle" developer private keys, having developers switch to new private keys, ensuring that the old keys will not be accepted for newer changes, and possibly destroying all copies of the older private keys (so that they cannot be stolen by anyone). Since private keys may be compromised, once such a compromise has been detected, it should be possible to invalidate the compromised keys and re-sign data (once it's checked) with new cryptographic keys. This is yet another reason to support multiple signature keys (in addition to supporting multi-person review).

• Aegis depends on the host operating system for authentication services.
• When transmitting change set between repositories, it is possible to use OpenPGP or GnuPG to provide adequate security.

• On login, acquisition, and commit, report the "last time" and source location (e.g., IP address) where reading and writing (committing) were performed. Although this doesn't deal with a malicious developer, it does increase the likelihood that an attack using stolen credentials will be detected. After all, the developer is mostly likely to know the last time that they read from and wrote to some repository, so they'll be able to detect when someone else forges their identity. Ideally, this would be resistant to repository attacks.

• Aegis depends on the host operating system for authentication services.

One mechanism for dealing with an encumbrance pollution attack is to allow specially-privileged accounts to "mask" history elements; i.e., preventing access to certain material by normal developers so that it's no longer available, so that the material isn't included in later versions (essentially it works like an "undo" against that change). However, a "mask" would still record the event in some way so that it would be possible to prove that the event occurred at a later time. Perhaps the system could record a hash of the encumbered change, allowing the encumbered material to be removed from the normal repository yet proving that, at one time, the material was included. A "masking" should include a cryptographic signature of whoever did the masking. This mechanism in particular requires careful design, because the mechanism should be design so that it doesn't permit other attacks.

• By using Aegis' code review feature, it is possible to mitigate the risk of an "encumbrance pollution attack". If the change set is unacceptable, it will be (should be) caught by the code reviewer.
• Until a change set is integrated, its history and meta- data are not immutably encumbered.
• The meta-data files (and often the source file) are all simple text files. It would be possible (via root) to edit the offending portions away.

Aegis was designed long before this concept evolved. Its meta-data is not in a form which allows it to be placed in an immutable file, with each update to the meta-data being placed in another immutable file.

Portions of the meta-data are immutable, but because it is stored in the same file as some changeable data (for example, where the change set is in the process) digital signatures are problematic.

It is possible to encrypt change sets when they are in transit between repositories, using OpenPGP or GnuPG.

• Cryptographic signing of changes can help significantly here, since this makes it possible to detect changes by anyone other than the authorized developers. Clearly, the list of public keys needs to be protected; this can be protected in part by ensuring that the list is visible to all developers, and having tools automatically check that the public listed key is correct (each developer's tool checks that the key listed is really that developer's key).

• Aegis was not designed to do this.

• Change set chaining can help detect problems (including unintentional ones). Basically, as changes are made, a chain recording those changes can be recorded and later checked. This is typically done using cryptographic hashes, possibly signed so you know who verified the chain. Note that this is also useful for detecting accidental corruption.

• Aegis was not designed to do this.

• Automated tools to detect if "my" change has been altered. Any given developer will know what changes they checked in. So, record that information locally/separately, and check it later. That way, someone can modify the repository to remove the latest security fix, but the developer of the change can quickly tell that it's been removed.

• Aegis was not designed to do this.

• Immutable backups, and tools to check them, can help as well. If a repository's history is changed, that change can be compared with backups. Be careful that a corrupted tool won't create misleading backups, and make sure that the repository can't give one view to backup tools, and another view to whoever actually takes and uses the program.

• Aegis relies on the host operating system for backups. If the host operating system is capable of cryptographically signed backups, use them.

• Simple, transparent formats can help make it harder to hide attacks. Data that is stored in simple, well-understood formats that can be analyzed independently (e.g., a signed tar file of patches) tend to be more resistant to attack than data structures that presume that no other process will manipulate the data contents (e.g., typical databases).

• Aegis' meta-data is in simple text files. These can be parsed by external verification programs if desired. (Aegis pre-dates XML by over a decade; these days XML would have been a good choice.)

• A malicious developer could insert a few lines into a build process that said "when you compile, email to me your private key data" - then, once they had the private key, remove that line, and then forge other changes as that unsuspecting developer. But an SCM system with all of the capabilities above would make it much harder to hide this. The change with these malicious instructions would be clearly labelled as from that developer, and later changes would be labelled as being from that developer or one of the compromised systems - and removing the change later would record yet another change that might be detected.

• In a properly configured project, in order for malicious code to be inserted into the build system, the code reviewer has to be compromised, negligent or the attacker must compromise two users' accounts, not just one.
• The second change set must also pass through the process, increasing the risk that something will be noticed.

• A malicious attacker might take over the repository, and repeatedly remove a critical patch to a security vulnerability. Still, the removal could be detected by the creator of the patch, and actions such as changing to a different repository could be performed. Trying to change older copies would likely be detected by chaining and comparisons with backups.

• As mentioned above, Aegis has no defense against a compromised root account, however this is not a back-door into any other machine via Aegis' support for geographically distributed development. If root isn't compromised, rescinding a previous critical security change set requires at least the help of a reviewer.