GitLab Security
What is GitLab?
GitLab is an open-source Git repository that accelerates your software development lifecycle by providing a single application for development, security, and operations. It is an end-to-end DevOps platform and a version control system that significantly reduces product development time and boosts productivity.
In this article, you will learn:
Why Use GitLab?
GitLab offers a wide range of features and benefits making it a go-to repository and DevOps platform for many organizations. It comes with the below capabilities to empower your software development process.
- It accommodates CI/CD pipelines
- Its inbuilt registry can be deployed without any additional configuration
- It integrates perfectly with Kubernetes
- It offers unlimited private repositories
- It has an intuitive user interface and authentication mechanisms
Differences between GitLab and GitHub
GitLab and GitHub are both web-based Git repositories that allow you to store, manage, and share code with your team and facilitate seamless collaboration. As they maintain Git as the single source of truth, it helps you in safeguarding your application source code from bugs, and accidental changes through an efficient tracking mechanism. Also, they’re both version control systems.
Although they’re both very similar, one stark distinction between the two is that GitHub is simply a collaboration platform enabling you to manage and review your code, while GitLab has CI/CD and DevOps workflows built-in. Further, GitLab focuses on providing a reliable platform, whereas GitHub is popular for its speed.
GitLab offers a complete software development solution with a wide range of third-party integrations such as Jira, Slack and other platforms. As for GitHub, you will have to turn to third-party CI programs like Jenkins in addition to limited integration options available through its Marketplace program.
Also, GitLab offers High Availability capability, which means if a component fails an automatic failover mechanism is triggered which enables a counterpart component to replace the failed one automatically. GitHub doesn’t have such a configuration in place.
What are common vulnerabilities that affect GitLab?
GitLab releases security trends reports twice a year listing the common vulnerabilities that affect projects hosted on the platform. As per GitLab’s security trends report for data evaluated between September 2019 and February 2020, the top 6 known vulnerabilities that are found in projects are as follows:
- Components with known vulnerabilities
The report found that developers tend to use components that are riddled with known vulnerabilities in their projects. You can use various scanning capabilities offered by GitLab to detect these vulnerabilities. This issue is very prevalent among developers and can lead to dire consequences.
How to mitigate?
Make it a point to remove unused components, files, and dependencies from your project, and components that you do use in your applications must be sourced from credible authors or organizations. Also, ensure that your dependencies are patched for security gaps. Conduct regular scans of your projects, code, and containers to identify known vulnerabilities.
- Cross-site scripting (XSS)
XSS vulnerability gives hackers access to complete web applications by injecting malicious code into a browser’s session. Attackers inject the hostile code by enticing users to click on malicious links, which target the user’s browser.
How to mitigate?
You can run SAST and DAST scans to detect XSS vulnerabilities. However, you need to keep an eye out for both reflected and stored XSS threats. Implement frameworks that detect and resolve the vulnerability by design. You can also execute Content Security Policy (CSP) as a defense mechanism against such attacks.
- Lack of secret management
By not following secret management best practices, you invite a range of attacks on your project. You might accidentally store secrets like keys, tokens, passwords, and other sensitive data in your repository, voiding its confidentiality.
How to mitigate?
You can run secret detection scans to check if any secrets were committed to Git and reset them. In addition, it is important you set strict policies for your team on the storage of secrets.
- Content security policy (CSP)
Content security policy is an extra security layer that detects and defends your project from attacks like XSS and data injection. By not implementing CSP, you open your project to serious threats including data theft, malware distribution, and site defacement.
How to mitigate?
You can avoid security threats by enabling CSP for all your web applications. To enable this security layer, configure your webserver to return the Content-Security-Policy HTTP header. Also, run DAST scans for all your applications to detect any security gaps in the early stages.
- Cross-site request forgery (CSRF)
With Cross-site request forgery (CSRF), hackers force an authenticated user to execute malicious code or unwanted action on a web application. Hackers employ methods like sending a malicious link through an email or message to trick you into implementing the attacker’s designs. This attack compromises the entire web application.
How to mitigate?
Implement CSRF protection frameworks to avoid malicious attacks, besides adding a CSRF token to all state-changing requests. Also, ensure a strict security layer is in place to protect your application against XSS attacks, as they override all CSRF mitigation exercises.
- SQL Injection (SQLi)
Injection vulnerabilities happen when an attacker sends hostile data – vector, the environment variable, or parameters – to an interpreter, which is not properly sanitized or validated. These are prevalent in SQL, XPath or NoSQL queries, XML parsers, etc.,
How to mitigate?
To avoid injection attacks ensure that all the incoming data is properly sanitized. Also, it is recommended that you use a safe API that provides a parameterized interface. You can detect the presence of suspicious data in your project by running SAST and DAST scans.
Best practices that ensure GitLab security
Securing Access
- Implement Two-Factor Authentication
You can ideally log in to your GitLab account using your credentials – username and password. However, it is highly recommended that you use two-factor authentication (2FA) to add an extra security layer. Since your username is publicly available, it makes sense to add another factor of authentication.
You can use a reliable authenticator like Google authenticator or 1Password Time-based One Time Password (TOTP). Meanwhile, avoid SMS-based authentication mechanisms as hackers have engineered ways to bypass them. You can also employ other authentication methods like SAML SSO using an identity provider.
- IP address-based Access Limitation
Your team might be working from different locations, which will see a surge of traffic from a variety of IP addresses. You can whitelist the IP addresses of all your employees or team members working on a project. In addition, you must implement a layer to filter all the IP addresses you’re receiving traffic from to detect suspicious hits. This will help you build a list of IP addresses that pose a risk and block them to avoid any untoward incidents.
Securing Data
- Disabling forking of the project
Forking enables you to create a copy of your repository and experiment with code without affecting the original version. But it adds undue complexity. The more forks, the tougher it becomes for you to manage the security of your project.
GitLab allows you to restrict forking at the project level with premium accounts.
- Control project visibility
You need to ensure that proper visibility measures are placed at both the project and group levels. The visibility controls are crucial to secure your repositories from leakages by accident or on purpose.
GitLab offers project and group visibility through three mechanisms:
- Public: In this, users don’t need authentication to clone a project listed in the public access directory.
- Internal: For internal groups and projects, only authorized signed-in users are allowed to clone projects. They are visible in the public access directory only for signed-in users.
- Private: Only project members can access and clone projects, and are visible in the public access directory for project members.
Detect phishing attacks
GitLab conducts periodic tests where it simulates a phishing campaign to generate awareness against malicious links that are sent in the form of emails. Phishing attacks are conducted to steal passwords or force authenticated users to download malicious attachments.
It is recommended that anytime you receive a mail with any suspicious link, hover your mouse on the link to verify its destination. GitLab also offers training sessions on how to avoid such scams.
Aqua’s Policy-based Security Solution
Though critical, implementing the best practices to secure your repository and CI/CD pipeline might seem tedious. You can ensure that your focus isn’t diverted from application development, you can use Aqua’s policy-based security solution to secure your entire CI/CD pipeline. Aqua’s solution offers a holistic security strategy to safeguard your project from both external and internal threats.
