Differences
This shows you the differences between two versions of the page.
|
ss:laboratoare:08 [2025/02/26 00:39] jan.vaduva [Laborator 8: Generarea și Utilizarea SBOM (Software Bill of Materials)] |
ss:laboratoare:08 [2026/04/27 18:21] (current) ciprian.popescu0411 |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Laborator 8: Generarea și Utilizarea SBOM ====== | + | ====== Laborator 8: Implementarea unui pipeline CI/CD pentru aplicația mobilă ====== |
| - | ===== Obiective ===== | + | Procesul de dezvoltare a unei aplicații de orice tip implică o serie de etape, printre care se numără |
| - | * Înțelegerea conceptului de **Software Bill of Materials (SBOM)** și importanța sa în securitatea aplicațiilor | + | scrierea codului, compilarea, testarea și lansarea software-ului. În cadrul acestui laborator ne vom |
| - | * Generarea unui SBOM pentru una dintre aplicațiile dezvoltate în laboratoarele anterioare | + | propune să automatizăm aceste etape prin implementarea unui pipeline CI/CD specific aplicației mobile |
| - | * Analiza componentelor software și a dependențelor pentru identificarea vulnerabilităților | + | realizate în cadrul acestei materii. |
| - | * Integrarea SBOM într-un proces CI/CD pentru actualizarea automată a inventarului software | + | |
| - | * Utilizarea SBOM pentru conformitate și raportare | + | |
| - | ===== Cerințe tehnologice ===== | + | Astfel, vom folosi GitHub Actions pentru a defini un pipeline simplu care va compila și rula testele |
| - | * **Generare SBOM**: Syft, CycloneDX, SPDX | + | unitare ale aplicației la fiecare push în repository. |
| - | * **Analiză vulnerabilități**: Grype, OWASP Dependency-Check, Snyk | + | |
| - | * **CI/CD Integration**: GitHub Actions, GitLab CI, Jenkins | + | |
| - | * **Format SBOM**: JSON, XML (CycloneDX, SPDX) | + | |
| - | * **Securitate și conformitate**: NIST SSDF, ISO 27001 | + | |
| - | ===== Funcționalități ===== | + | ==== Indicații de implementare ==== |
| - | ==== 1. Generarea unui SBOM pentru proiect ==== | + | Pentru a configura pipeline-ul, vom crea structura de directoare necesară și fișierul de workflow în |
| - | * Utilizarea unui tool (ex. Syft, CycloneDX) pentru a genera automat un SBOM | + | rădăcina proiectului, astfel: |
| - | * Exportarea SBOM în format JSON/XML și analiza sa | + | |
| - | ==== 2. Analiza componentelor și identificarea vulnerabilităților ==== | + | === Pasul 1: Creați directorul pentru workflow-uri: === |
| - | * Utilizarea SBOM pentru scanarea dependențelor și găsirea CVE-urilor | + | |
| - | * Integrarea unui tool precum Grype pentru analiza statică a vulnerabilităților | + | |
| - | ==== 3. Automatizarea procesului SBOM în CI/CD ==== | + | <code bash> |
| - | * Generarea SBOM la fiecare build și adăugarea sa în artifacte | + | mkdir -p .github/workflows |
| - | * Scanarea periodică a SBOM pentru a detecta noi vulnerabilități | + | </code> |
| - | ==== 4. Utilizarea SBOM pentru conformitate și raportare ==== | + | === Pasul 2: Creați următorul fișier de configurare: === |
| - | * Validarea compatibilității componentelor cu standardele de securitate | + | |
| - | * Crearea unui raport privind componentele open-source și licențele utilizate | + | |
| - | ===== Evaluare ===== | + | <file yaml mobile-ci-cd.yml> |
| - | * Generarea și exportul SBOM pentru aplicație (25%) | + | name: Mobile CI/CD |
| - | * Analiza vulnerabilităților identificate și propunerea unor soluții (30%) | + | |
| - | * Integrarea procesului SBOM în pipeline-ul CI/CD (30%) | + | |
| - | * Crearea unui raport de conformitate și securitate (15%) | + | |
| - | ===== Resurse suplimentare ===== | + | on: |
| - | * [https://cyclonedx.org CycloneDX Documentation] | + | push: |
| - | * [https://spdx.dev SPDX Specification] | + | branches: [ "main" ] |
| - | * [https://anchore.com/syft Syft - SBOM Generator] | + | pull_request: |
| - | * [https://owasp.org/www-project-dependency-check/ OWASP Dependency-Check] | + | branches: [ "main" ] |
| - | * [https://grype.dev Grype - Vulnerability Scanner] | + | |
| + | jobs: | ||
| + | unit_tests: | ||
| + | name: Run Unit Tests | ||
| + | runs-on: ubuntu-latest | ||
| + | steps: | ||
| + | - name: Checkout code | ||
| + | uses: actions/checkout@v4 | ||
| + | - name: Set up JDK 17 | ||
| + | uses: actions/setup-java@v4 | ||
| + | with: | ||
| + | java-version: '17' | ||
| + | distribution: 'temurin' | ||
| + | cache: gradle | ||
| + | |||
| + | - name: Grant execute permission for gradlew | ||
| + | run: chmod +x gradlew | ||
| + | |||
| + | - name: Run Unit Tests | ||
| + | run: ./gradlew test | ||
| + | </file> | ||
| + | |||
| + | Principalele elemente ale fișierului de workflow sunt: | ||
| + | |||
| + | * **''on: push''**: Aici se definește când pornește automat pipeline-ul. În acest caz, la fiecare ''push'' / ''pull_request'' pe branch-ul ''main''; | ||
| + | * **''runs-on: ubuntu-latest''**: specifică mașina virtuală pe care va rula job-ul (un container Linux standard oferit de GitHub); | ||
| + | * **''actions/checkout''**: Acțiune oficială GitHub care clonează repository-ul în mediul de lucru CI; | ||
| + | * **''setup-java''**: Instalează JDK-ul necesar compilării proiectului Android; | ||
| + | * **''./gradlew test''**: Comanda Gradle care compilează codul și rulează testele unitare (cele care nu necesită dispozitiv Android/emulator). | ||
| + | |||
| + | === Pasul 3: Încărcați workflow-ul creat în repository: === | ||
| + | |||
| + | <code bash> | ||
| + | git add .github/workflows/mobile-ci-cd.yml | ||
| + | git commit -m "Add Mobile CI/CD workflow for unit tests" | ||
| + | git push | ||
| + | </code> | ||
| + | |||
| + | După ce ați terminat de implementat acest workflow, puteți verifica tab-ul ''Actions'' din repository-ul | ||
| + | vostru de GitHub pentru a vedea pipeline-ul rulând. | ||
| + | |||
| + | ==== Cerință ==== | ||
| + | |||
| + | Într-un mediu real de lucru acest pipeline este incomplet, astfel propunem îmbunătățirea acestuia | ||
| + | prin adăugarea de etape suplimentare: | ||
| + | |||
| + | - analiza statică a codului înainte de etapa de testare propriu-zisă; | ||
| + | - rularea testelor instrumentate; | ||
| + | - compilarea aplicației sub formă de APK; | ||
| + | - încărcarea APK-ului în GitHub Releases. | ||
