Securing the Build Source
Source Code Security
The first step to securing the pipeline and the build is to secure the source. In the event that a threat actor can compromise the source of our build, they are in a position to compromise the build itself. We want to protect our source code from the following two main issues:
Unauthorized Tampering - This is the simplest issue of the two. Only authorized users should be able to make changes to the source code. This means that we want to control who has the ability to push new code to our repo.
Unauthorized Disclosure - This is a bit more tricky. Depending on the application, the source code itself might be considered sensitive. For example, Microsoft would not like to disclose the source code of Word since that is their intellectual property. In cases where the source code is sensitive, we must ensure we do not intentionally disclose it. This issue is a lot more common to find.
Confusion of responsibilities
Let's take a look at exploiting an insecure build source. A common mistake made in large organizations is believing that the perimeter is a sufficient security boundary. Although the perimeter plays a role, it should not be seen as the only boundary. Granular access control on the internal network should be implemented as well. This false belief can lead to interesting misconfigurations. Let's take a look at a practical example.
Some organizations are incredibly large and have multiple teams and business units responsible for different things. If we take an organization such as a bank, many different teams and units work together to run the bank. Furthermore, in large organizations like this, it isn't as simple as just saying that we have an "IT" business unit, as there may be several teams working on many different IT and development projects within the bank, using a wide range of coding languages, CI/CD pipelines, and build frameworks. Such large organizations may choose to host their source code internally, since much of that development may be intellectual property (IP). While we would hope that access to the various source code repos would be managed in granularity, mistakes do creep in.
One such mistake is that organizations can leave registration for their GitLab instance open. Not open to the internet (although this has also happened before), but open to any user on their internal network to register a profile. This was simulated in the previous task by allowing you to register your own Gitlab profile.
Some would consider this not to be a direct risk, but let's look at how the attack surface grows. Our example bank organization might have 10,000 employees, of which 2000 may be working as developers and need access to Gitlab. In essence, our attack surface has grown by 500%! If a single employee of our bank is compromised, an attacker would have the ability to register a profile and exfiltrate any publicly shared repos.
This is the second misconfiguration that comes into play. Developers of our bank may believe that because the GitLab instance is only accessible internally, it is okay to configure repos to be shared publicly. This means that any user who has a valid GitLab account will be able to view the repo. While they may not be able to alter the code, remember, in this example, the code itself is seen as the IP of the bank. This confusion between who is responsible for securing the source code can lead to sensitive information being disclosed to the threat actor
Securing the Build Source
Granular access control is crucial to managing repositories and the GitLab platform. It involves defining specific permissions and restrictions for different users or groups, ensuring that only authorized individuals have the appropriate level of access to sensitive resources. This helps maintain security, confidentiality, and effective collaboration within a development environment.
In GitLab, group-based access control is a powerful mechanism that simplifies permissions management across multiple repositories and projects. Here's how it works:
Group-Based Access Control: GitLab allows you to organize projects into groups. Instead of managing access for each project separately, you can set permissions at the group level. This means that the same access rules apply to all projects within the group, making it easier to maintain consistent security policies. For example, you can create a group for the development team and define permissions, such as who can view, edit, or contribute to projects within that group. This approach streamlines access management and reduces the chances of errors or oversights when configuring permissions for individual repositories.
Access Levels: GitLab offers different access levels, such as Guest, Reporter, Developer, Maintainer, and Owner. Each level comes with specific capabilities and permissions. Assigning the appropriate access level to each user or group ensures they have the necessary privileges without granting unnecessary permissions.
Sensitive Information Protection: One critical consideration is preventing the accidental exposure of sensitive information. GitLab provides features to help with this:
GitLab's .gitignore: This file specifies which files or directories should be excluded from version control. It's crucial for preventing sensitive data like passwords, API keys, and configuration files from being committed to repositories.
Environment Variables: GitLab allows you to define and manage environment variables securely, separate from the source code. This is especially useful for storing sensitive data needed during the CI/CD process without exposing it in the repository.
Branch Protection: Branches, like master or main, can be protected to prevent direct pushes, ensuring that changes go through code review and automated testing before merging.
Remember, maintaining the security of both the repositories and the GitLab instance itself requires constant vigilance and best practices:
Review and update access permissions regularly as team members change roles or leave the organization.
Implement two-factor authentication (2FA) to add an extra layer of security to user accounts.
Monitor audit logs to track who has accessed or modified repositories and projects.
Regularly scan repositories for sensitive information using tools designed for this purpose.
Last updated