6 steps to Protect Source Code

Source code is one of the most valuable assets an organization can own. It can contain trade secrets, patented algorithms, and even personal information. With access to it, hostile actors could compromise a system, steal data, and take over an entire machine.

Repository Security

Repository security and management is a developer’s responsibility.

Use the principle of least privilege

Source code repositories should be strictly controlled so that access is given to authorized persons on an as?needed basis. For example, a new developer should not be given complete access to all the source code the organization has. Instead, they should only be given access to what they need to get their job done. This process is known as the principle of least privilege and it’s a vital part of security.

Limit administrator access

Limit administrative access to source code repositories. The administrators must be trusted stakeholders in the organization who have a vested interest in the security of the source code. Don’t give all developers on all teams administrator access to the settings. Doing so could lead to leaked access. Most source code repository software have settings that can enforce good policies like requiring code reviews, requiring builds to run on code changes, and requiring that an automated test is executed and reported. If any developer has administrator access and can change these critical settings, it could lead to unintended consequences and security liabilities.

Require code reviews

Code should always be reviewed by another person who had no part in writing the code. These reviews improve the code and this practice has been established as a standard in the worldwide developer community. There are two key factors to consider in this process:

1. Code reviews should be relatively swift and should never take more than a few days. When code reviews take weeks or even months, it can be a sign of bad culture, or an indication that developers are refusing to engage in peer review, which is a poor engineering practice.
2. Always include all stakeholders in code reviews. The developers who created the original code, or had significant roles in maintaining it, know the code well and can offer the most insight into potential changes.

Limit merge credentials

Don’t allow all developers to merge their code without oversight. Instead, designate a select few to accept code submissions. Most repository programs can restrict merging capabilities to specific individuals with authorized credentials. This practice should be followed as much as possible. Permitting any developer to make changes could introduce security vulnerabilities (as well as functionality issues).

Prevent proliferation of code repositories

If all developers have the ability to create a repository, over time the number of repositories could get unmanageable and code might get lost, forgotten, or become obsolete. This could create a dangerous situation where a developer leaves the organization, yet still has access to a code repository that management forgot about. Stakeholders must be aware of all source code repositories and keep a secure handle on all of them.

Enable merges only after tests pass

Checks should be enabled to ensure a build will fail if testing fails. The result of this check should be passed back to the pull request. If the build fails, the button to merge the updated code should be disabled. This practice ensures that failed tests with broken code do not creep into the working product. A product with untested (or worse, broken) components introduces unnecessary security risks.

? 2022 The Security Awareness Company - KnowBe4. 
Inc. All rights reserved.