# Secure System Development Lab 3 - SCA OSA and Secrets detection

**Team Members:**
* Daniyar Cherekbashev ([e-mail])
* Gleb Statkevich ([e-mail])
* Daria Kalashnikova ([e-mail])

## Task 1
**1. Q: Explain what is a suply chain security and how it works?**
A: Software supply chain security is the protection of all elements, processes, and procedures involved in the development and deployment of software. It include third-party/proprietary code, deployment methods and systems, interface and protocol standards, as well as the practices+tools used by developers. Supply chain security works by implementing (and use) a range of strategies and technologies to protect the supply chain at various stages.
**2. Q: List and explain the key components of an effective supply chain Security.**
A:
- **Secure Coding:** Implementing secure coding practices is essential to preventing vulnerabilities in software development. This includes following coding standards, validating user input, and handling errors in a secure manner, using static analyzers and other useful tools.
- **Dependency Management:** it is crucial to ensure that all third-party components and libraries that used during dev process are secure to use. Also, regular updates and security patches can help prevent potential vulnerabilities associated with outdated software.
- **Code Reviews and Testing:** Conducting code reviews and testing, including static code analysis, dynamic testing, and penetration testing, can help identify potential security issues in software before it is deployed.
- **Secure Configuration Management:** Implementing secure config management practices (storing/managing passwords, encryption keys) using secrets managing tools, as well as implementing access controls to sensetive data.
- **Secure Deployment Practices:** Implementing secure deployment (using secure tools, verifying software package integrity, conducting configuration and security checks via special tools, etc.), can help ensure that software is installed securely and safely.
- **Continuous Monitoring** helps to detect and respond to security issues in real-time (asap as some threat was appeared in motitoring). An effective incident response plan can help minimize the impact of breaches and ensure a proper response to security events.

**3. Q: Briefly explain what is Software Composition Analysis (SCA) and how it works.**
A: SCA is an automated process that helps manage open-source projects, components and libraries used in software. SCA tools inspect package managers, manifest files, source code, binary files, container images, and more to evaluate security, license compliance, code quality and other.
**4. Q: What is an SBOM used for?**
A: A Software Bill of Materials (SBOM) is a list of all the open-source and third-party components present in a project. It supports software development and maintenance by providing a record of the components used - helps to improve supply chain security by identifying and managing potential vulnerabilities + ensures compliance with licensing agreement.
**5. Q: What does an SBOM contains?**
A: SBOM is a document that provides detailed information about all the software components used in a project, including versions, dependencies, licensing information, origin/source, risk and vulnerability data, as well as metadata.
**6. Q: What is SBOM attestation and how is it useful?**
A: SBOM attestation is a process that helps customers adjust the reliability and integrity of software components listed in the SBOM. Attestation makes easier to verify the software they are using, ensure security and compliance of software applications.
**7. Q: Briefly explain what is Secret detection and how it works.**
A: Secret detection is a process used to ensure that sensitive data is not leaked in source files. This is done by scanning the code, configuration files and other public locations for patterns that could reveal secrets. If any secrets are found, the tool alerts the developers so they can take steps to prevent anyone else from accessing the information.
**8. Q: Explain what are the limitations of Secrets detection**
A:
- **False positives:** Secret detection tools may incorrectly mark strings or patterns as sensitive data.
- **Limited coverage:** Some secret detection tools may be unable to detect all types of sensitive data or may have limitations when scanning certain file formats or operating envs, reducing the effectiveness of these tools in complex secrets identification.
- **Encryption Challenges:** Encrypted secrets or dynamically generated secrets may not be easily detectable by standard secret detection tools, making it difficult to identify and secure such sensitive information.

## Task 2 - Secret detection with Gitlab CI

1. Added .env file to the juice-shop project:

2. Secret detection job from AutoDevOps:
Artifact with detected leaks is located at gl-secret-detection-report.json

1. Out of 7 secrets, the job detected only 3 of them (actually, even 2, he detected RSA private key twice):
It detected so little secrets probably because we need to manually add custom rulesets for more diverse secret detection.
2. To ignore a secret, we can add `# gitleaks:allow` as a comment to the secret
3. After adding ignore comment, it now detected only 2 secrets out of 3
Artifact:
4. Enabled full history secret detection with

        variables:
            SECRET_DETECTION_HISTORIC_SCAN: "true"

Results:
18 commits were now scanned. Gitlab token was found again, because in one of the commets it was not ignored.
3. **Q: What are the best practices to follow in Secret management and secret storage?**
A:
- **Encrypt Secrets:** Encrypt all stored secrets to protect them from unauthorized access or disclosure. Secure encryption keys and use strong encryption algorithms; + ensure that secrets are not transmitted in a clear way (without decryption).
- **Role-Based Access Control:** Implement role-based access control to restrict access to secrets based on the principle of least privilege. Only authorized user should have access to certain sensitive information.
- **Avoid Hardcoding Secrets:** It is not recommended to hardcode secrets in your code or in other files. Instead, use a secure storage system to store secrets and retrieve them dynamically at runtime
- **Secure Development and Deployment:** Ensure that secrets are not exposed during dev or deployment process. Implement automate checks in CI/CD pipelines for sensitive information in code repositories.
- **Regular Security Audits:** It is essential to conduct regular security audits of secrets management processes to identify potential vulnerabilities and ensure compliance with relevant industry standards and regulations.

## Task 3 - Dependency analysis with Anchor engine and Trivy
1. Pipeline with Docker image building, syft and grype:
<span style="color: green">.gitlab-ci.yaml</span>

    stages:
      - build
      - test

    default:
      image: docker:24.0.5
      services:
        - docker:24.0.5-dind

    variables:
      DOCKER_HOST: tcp://docker:2375
      DOCKER_TLS_CERTDIR: ""

    build_job:
      stage: build
      when: manual
      tags:
        - docker
      script:
        - docker build -t $DOCKERHUB_IMAGE -f Dockerfile .
        - docker login -u $DOCKERHUB_USER -p $DOCKERHUB_TOKEN docker.io
        - docker tag $DOCKERHUB_IMAGE:latest $DOCKERHUB_USER/$DOCKERHUB_IMAGE:latest
        - docker push $DOCKERHUB_USER/$DOCKERHUB_IMAGE:latest

    syft_job:
      image: 
        name: docker.io/anchore/syft:debug
        entrypoint: [""]
      stage: test
      script: 
        "/syft $DOCKERHUB_USER/$DOCKERHUB_IMAGE:latest --output json > sbom.json"
      artifacts:
        paths:
          - sbom.json
        when: on_success

    grype_job:
      image:
        name: docker.io/anchore/grype:debug
        entrypoint: [""]
      stage: test
      needs:
        - job: syft_job
          artifacts: true
      script: 
        "/grype sbom:./sbom.json --output table --file grype_report.csv"
      artifacts:
        paths:
          - grype_report.csv

Job run:

2. Grype job:
3. In artifacts of grype, we see 65 reported vulnerabilities in packages. Some of them are unfixed (tagged with won't fix)

4. Trivy job:

    trivy_job:
      image:
        name: docker.io/aquasec/trivy:latest
        entrypoint: [""]
      stage: test
      script:
        trivy image -f json -o trivy.json $DOCKERHUB_USER/$DOCKERHUB_IMAGE:latest
      artifacts:
        paths:
          - trivy.json


5. Modified trivy job to provide only HIGH and CRITICAL vulnerabilities, also ignoring unfixed vulns (with `trivy image -s HIGH,CRITICAL --ignore-unfixed -f json -o trivy.json $DOCKERHUB_USER/$DOCKERHUB_IMAGE:latest`):
6. Modify trivy job to fail if any CRITICAL vulnerabilities are found (with `trivy image --exit-code 1 -s CRITICAL --ignore-unfixed -f json -o trivy.json $DOCKERHUB_USER/$DOCKERHUB_IMAGE:latest`):

All scan artifacts are provided in attached zip-file.

## Task 4 - Analysis comparison

| Criteria | Trivy | Anchor Engine |
|-|-|-|
| **Total Vulnerabilities Detected** | 69 | 65 |
| Ease of Use and Customization | Easy to setup | Understandable report |
| Critical Vulnerabilities | 18 | 8 |
| High Vulnerabilities | 16 | 10 |
| Medium Vulnerabilities | 36 | 33 |
| Vulnerable OS Packages | 22 | 22 |
| Vulnerable Application Dependencies | 47 | 43 |
| Performance and Speed | Fast and efficient | Slower processing time |

**Q: Based on your comparison, what tool will you choose as a DevSecOps Engineer? Why?**
A: As a DevSecOps Engineer, we (each of us) would choose Trivy for vulnerability scanning. Although Anchor Engine found enough security "moments", Trivy make a better analysis of finding all critical, high and medium Vulnerabilities. Additionally, Trivy has a user-friendly interface, customizable options, and fast scanning speed.