# DevSecOps Lab 2
Ilya Kolomin [e-mail]
Kirill Ivanov [e-mail]
Anatoliy Baskakov [e-mail]

### Task 1 - SAST Theory
* What is Static Code Analysis?
* Static analysis is a process in which code is being tested for the presence of flawsand other issues without actually running the code. It is performed by specific tools and is usually integrated into devops life cycle.
* Give and explain the limitation(s) of Static Analyzers
* If there is a vulnerability a tool does not know about, for example if it was discovere recently, then that tool will not be able to find it in the source code even if it is present.
* There is also a possibility of false positives, when a secure application is reported to have a vulnerability
* Some vulnerablities may exist due to external components which cannot be analyzed by the given tool. In general, if there is a system or component that cannot be analyzed due to various reasons, the static analysis tool will not be able to provide adequate results.
* There are many vulnerabilities that are hard or impossible to find automatically
* Newer languages usually do not have proper static analysis tools
* Give an explain the benefit(s) of Static Analysis Tool
* Increase chances of detecting flaws in an application if present. Detect vulnerabilities on earlier stages
* Can be performed automatically when integrated into CI/CD pipeline and IDE
* Give and explain the best criterias when choosing a Static Analysis Tool
* What vulnerabilities the tool can detect.
* The more the better, but it is not possible for a tool to be able to cover everything. We need to check if a tool can find most common vulnerabilities, as well as keep in mind that some vulnerabilities are more likely (and more dangerous) for the app we are working with
* The tool must work with the language used.
* If a tool cannot work with the language an app is written with, then there is no reason to use it

### Task 2 - Set up your environment
* Deploy a complete Gitlab environment with Gitlab server and Gitlab runner(s).Check back on Lab 1 DevSecOps
* Done

* Import your project into Gitlab and add a register a runner to it.

Our group number is 4, so we use project 1 which is "DAMN VULNERABLE WEB APPLICATION" on PHP. We imported it from github:


* Deploy a sonarQube Docker instance on your server

Deployed using `docker compose`:

version: "3"
services: 
  sonarqube:
    image: sonarqube:9.7.1-community
    container_name: my-sonarqube
    restart: unless-stopped
    volumes: 
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_extensions:/opt/sonarqube/extensions
      - sonarqube_logs:/opt/sonarqube/logs
    ports: 
      - "9000:9000"

volumes:
  sonarqube_data:
  sonarqube_extensions:
  sonarqube_logs:

### Task 3 - Analysis
* SonarCube is configured to run on GitLab CI
* Variables set
* GitLab integration is set up

* CI set up


* Quality Gates
* It is an approach to development in which after different stages of development there are so-called quality gates - check lists of some kind, which need to be passed before the development can proceed to the next stage.
* SonarQube allows to configure quality gates
* Create a quality gate that will break the build pipeline
* Here is our Quality Gate
* 
* Due to already existing critical issues, it causes the gitlab ci pipeline fail
* 
* *Here is the report*

### Task 4 - Remediation

#### Issues solving

We have created MR solving 6 major issues


*Before: 485 major bugs*

*After: 479 major bugs*

#### Telegram integration

We have used [this](https://github.com/danigm/gitlab-telegram-bot) impelmentation to host our own telegram bot for notifications (https://github.com/danigm/gitlab-telegram-bot).

*Webhook on gitlab*

*Running container with bot*

*Result*