GitLab Security Testing đź“„
In this article, we delve into security testing on GitLab. In the software development process, the security of your applications becomes more important than ever. Therefore, we will examine the security testing tools provided by GitLab. We will explore ways to enhance the security of your code and applications using tools like SAST, DAST, and others step by step. Enjoy reading!
Before conducting security tests, let’s start by examining the processes that should be considered for security in the CI/CD pipeline.
First and foremost, when developing our code, we should take care not to embed sensitive information such as private keys and secret values directly into the code. This is crucial during the storage phase of the application. Because having such sensitive information within the code can lead to serious security vulnerabilities in the event of a cyber attack. For example, if developer accounts are compromised or unauthorized access to servers is gained, important data like AWS credentials could be at risk. To make our code more secure, we should adopt a cleaner approach rather than embedding such information directly into the code. For instance, we can use configuration files stored in a common location or environment variables. This way, we can make our code cleaner and more secure.
So, how does GitLab provide us with a security method for this?
GitLab CI/CD variables, also known as Environment Variables, make this possible. These variables can be used to store sensitive information such as private keys, API keys, etc. Hard coding sensitive information (such as secret keys, passwords, API keys, etc.) directly into the .gitlab-ci.yml file can pose security risks. To prevent this, these variables can be made visible only to authorized users or in specific runtime environments, thus ensuring security.
At this point, concepts like SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing) come into play. Both methods aim to identify security vulnerabilities using different approaches.
Now, what is SAST?
SAST is a testing process that allows us to find security vulnerabilities in code using static analysis. It operates at the user level and requires access to the source code. The goal is to identify and address all vulnerabilities in the project before deployment. Developers need to have their code processed and validated by this test before merging it into the main branch. In other words, verification is ensured after each merge request.
In these tests, it provides us with what is called White box testing. What does this mean?
During the testing process, access to the code’s contents is available. Testers can access what types of frameworks, design patterns, and implementations are being used.
Below, I’ll mention some official analysis tools supported by “SAST” for various programming languages and general testing processes that I could write about on Medium.
C/C++ => flawfinder
Node.js => nodejs-scan
Java, Groovy, Scala => spotbugs
.Net => security-code-scan
You can perform your SAST tests thanks to such tools.
Let’s do a demo.
The first step is to properly configure the GitLab project by writing the relevant code into the .gitlab-ci.yml file. Once you’ve committed the changes and created a new merge request to the main branch, the pipeline will start running the corresponding tests.
In this section, I’m sharing an example of a SAST scan result. Looking at this result, it’s worth mentioning that it prioritizes vulnerabilities it finds. We see an expression called “fixed vulnerability” here, and the reason for this is that it compares scans performed in different versions/pull requests.
The absence of setting the header as “nosniff” allows older versions of Internet Explorer and Chrome to perform MIME sniffing on the response body. Alerts like these are crucial for web security and should be taken into consideration by web developers. Properly setting the header helps ensure a more secure browsing experience for users.
What should we do after successfully completing SAST tests?
Development processes and deployment strategies may vary depending on the project’s programming languages. In compiled languages, you typically obtain an executable file directly after the compilation process, which can be copied to the target environment and executed. However, in interpreted languages, deploying to production often involves using solutions like Docker. Docker containers can include all the dependencies necessary for the application to run, allowing for easy deployment across different environments. However, Docker containers may contain security vulnerabilities depending on the image and its components, so it’s important to scan Docker images for security vulnerabilities before deploying to production. These scans are performed to detect security vulnerabilities in the components within the Docker image.
The next step should be deploying a DAST scanner.
So, what is DAST?
DAST tools, unlike SAST tools, are not specific to particular programming languages but are often limited in terms of the types of applications they can test.
Black box security testing is employed as a security testing technique where the tester is unaware of the technologies, frameworks, or implementations used. The primary objective is to identify security vulnerabilities rather than the functionality of the code. Such tests aim to discover security vulnerabilities that may occur at runtime.
Furthermore, the behavior of the application in different environments is carefully observed and analyzed. These tests are crucial for evaluating how secure the application is against external threats and for identifying measures to enhance its security.
Security teams can utilize tools like Burp Suite and IBM AppScan for this purpose.
Let’s start the testing.
The first step is to properly configure the GitLab project by writing the relevant code into the .gitlab-ci.yml file.
All HTTP communications within the project, as well as potential XSS attack scenarios, are tested within GitLab, and ultimately, a report is generated.
Appropriate demo user information is entered in this section so that testing stages can be carried out in all roles.
Afterwards, we commit all the transactions we have made and send a merge request to the main branch.
DAST tests are observed to be functioning as expected. During DAST execution, security vulnerabilities in applications and APIs are simulated to mimic real-world attacks. GitLab provides us with reports on these vulnerabilities.
GitLab offers several options for integrating popular DAST tools. For example, tools like OWASP ZAP or Burp Suite can be integrated into GitLab.
Dependecy Scanning
I’d like to talk about a security feature called Dependency Scanning. This feature examines the “dependencies,” which are other software components that an application retrieves from external sources, and searches for known security vulnerabilities within them. These dependencies can include not only those directly used in the application’s code but also those used by the dependencies themselves.
Having libraries added to your project during the development phase that contain security vulnerabilities can pose a serious risk to your project’s security. In particular, if a security vulnerability exists in one of these libraries, it can also trigger a similar vulnerability in your project. For example, if remote code execution attacks can be performed through a library, a similar security vulnerability may arise in your project.
Therefore, it is important to regularly check for such security vulnerabilities during the development process. You can use tools provided by GitLab, such as Dependabot, for this purpose. Dependabot regularly scans your project’s dependencies and notifies you if it detects any security vulnerabilities.
The working principle of Dependabot is quite simple: It regularly scans the dependencies in your project and their latest versions. If a newer version with a security vulnerability fixed is available for a dependency, Dependabot automatically suggests an update. This allows you to quickly detect and address security vulnerabilities.
Some advantages of Dependabot include:
- Automatic Update Notifications: Dependabot automatically notifies you when security vulnerabilities are found in your project’s dependencies. This allows you to quickly identify and address security vulnerabilities.
- Automatic Update Actions: Dependabot can automatically perform updates or offer you the option to perform updates manually. This makes it easy to address security vulnerabilities.
- Comprehensive Reporting: Dependabot provides comprehensive reports on updatable dependencies in your project. This gives you an overview of your project’s security.
Integrating Dependabot into your project is an effective method for detecting and addressing security vulnerabilities. This way, you can reduce potential security risks during the development process and enhance the security of your project.
After completing the DAST process, our application becomes ready for production. But does our DevSecOps journey end here?
No.
There are still some precautions to be taken after the application goes live. For example, having a Web Application Firewall (WAF) in place provides us with traffic analysis that protects us against vulnerabilities resulting from external attacks on our application. Through the analysis of this traffic, any attempted attacks by users are clouded and protected.
WAF flow operates as follows: When a user connects to the site, they connect through this firewall. In case of malicious traffic, it interrupts the traffic flow, thus preventing attacks like DDoS. It may restrict access to certain endpoints; for more detailed results, you may want to research Zero Trust Network.
Alternatively, you may need bot defense mechanisms. For instance, on an e-commerce site, you might need mechanisms to prevent individuals from extracting prices through bots feeding off your data.
Security isn’t just an extra feature in the software development process; it’s a fundamental necessity. Today, ensuring reliability is essential for the success of any application or platform. DevSecOps offers a security-focused approach by integrating this necessity into every stage of the development process. This approach doesn’t stop just before the software reaches the end-user; it continues to be updated and monitored while running live.
Tools like GitLab become significant components of this security-focused process. Features like SAST, DAST, and Dependency Scanning ensure continuous security from the development phase to deployment. Additionally, measures like WAF ensure the protection of live systems.
However, security isn’t limited to just one tool or process. We must continuously monitor security threats, adapt to new attack techniques, and take necessary measures to protect user data. DevSecOps guides us in the ongoing battle against these evolving threats, and together, we must strive for a secure digital world.
Until the next article in the series!
