Differences
This shows you the differences between two versions of the page.
|
ss:laboratoare:10 [2025/02/26 00:49] jan.vaduva |
ss:laboratoare:10 [2026/05/18 23:44] (current) ciprian.popescu0411 [Laboratorul 10: Rapoarte de securitate și extindere CI/CD] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Laborator 10: Evaluare de Securitate – Audit și Remediere ====== | + | ====== Laborator 10: Rapoarte de securitate și extindere CI/CD ====== |
| ===== Obiective ===== | ===== Obiective ===== | ||
| - | * Înțelegerea procesului de **audit de securitate** și importanța sa | + | La finalul laboratorului veți ști să: |
| - | * Identificarea vulnerabilităților critice în aplicație prin scanări automate și analize manuale | + | * Configurați workflow-uri CI/CD pentru validarea și securizarea unei aplicații web (frontend și backend). |
| - | * Aplicarea măsurilor de remediere pentru riscurile identificate | + | * Generați și exportați rapoarte pentru Unit Testing, Code Coverage, Fuzzing, SCA și SBOM. |
| - | * Integrarea proceselor de audit în dezvoltarea software | + | * Impuneți reguli de Branch Protection și Fail-Fast în pipeline. |
| + | * Evaluați și îmbunătățiți securitatea unui repository folosind OpenSSF Scorecard. | ||
| + | * Automatizați extragerea și afișarea metricilor de colaborare prin apeluri de API. | ||
| + | * **(Opțional)** Extindeți pipeline-ul CI/CD pentru medii Mobile și IoT. | ||
| - | ===== Cerințe tehnologice ===== | + | ===== 1. Introducere ===== |
| - | * **Scanare automată**: OWASP ZAP, Trivy, Grype, Bandit | + | Acest laborator urmărește extinderea unui pipeline de Continuous Integration (CI) centrat pe o aplicație web (frontend în React/JS, backend în Go). Veți automatiza execuția testelor, analiza de securitate și generarea rapoartelor, definind reguli stricte la nivel de repository pentru a bloca integrarea codului nevalidat. |
| - | * **Analiză statică a codului**: SonarQube, Semgrep | + | |
| - | * **Analiză manuală**: OWASP Top 10, Common Weakness Enumeration (CWE) | + | |
| - | * **Fixare vulnerabilități**: Actualizare dependențe, aplicare patch-uri, hardening | + | |
| - | * **CI/CD Security**: Dependabot, GitHub Security Alerts | + | |
| - | ===== Funcționalități ===== | + | Deși repository-ul poate conține și clienți de mobile (Android/Kotlin) sau module IoT (ESP32-CAM în C/C++), securizarea acestora reprezintă un obiectiv opțional, pentru a demonstra scalabilitatea arhitecturii CI/CD. |
| - | ==== 1. Realizarea unui audit de securitate ==== | + | ===== 2. Desfășurarea laboratorului ===== |
| - | * Scanarea aplicației pentru vulnerabilități utilizând OWASP ZAP și Trivy | + | |
| - | * Analiza codului sursă pentru probleme de securitate cu SonarQube sau Semgrep | + | |
| - | * Identificarea componentelor nesigure (dependințe vechi, configurări incorecte) | + | |
| - | ==== 2. Clasificarea și prioritizarea riscurilor ==== | + | ==== Exercițiul 1: Izolarea pipeline-ului web și Fuzzing ==== |
| - | * Maparea vulnerabilităților identificate conform **OWASP Top 10** și **CWE** | + | Componentele aplicației web trebuie testate individual. |
| - | * Prioritizarea problemelor în funcție de impact și probabilitate | + | **Cerințe:** |
| - | * Crearea unui raport de securitate cu riscurile și recomandările de fixare | + | - Configurați pipeline-ul astfel încât job-urile de testare să ruleze independent și în paralel pentru directoarele de frontend și backend. |
| + | - Adăugați o etapă de **Fuzzing** specifică fiecărui mediu web: | ||
| + | * Backend (Go): Apelați fuzzer-ul nativ (''go test -fuzz=Fuzz''). | ||
| + | * Frontend (React): Implementați teste folosind un pachet de Property-Based Testing (ex. ''fast-check''). | ||
| - | ==== 3. Implementarea măsurilor de remediere ==== | + | ==== Exercițiul 2: Generarea și exportul rapoartelor ==== |
| - | * Corectarea codului vulnerabil și a configurațiilor nesigure | + | Extindeți workflow-ul curent cu următoarele etape pentru componentele web. Toate rezultatele trebuie salvate și exportate ca artifacte ale pipeline-ului. |
| - | * Actualizarea și securizarea dependențelor software | + | **Cerințe:** |
| - | * Aplicarea măsurilor de hardening (principiul **Least Privilege**, protecție API) | + | - **Unit Testing & Code Coverage:** Executați testele și generați rapoartele de acoperire a codului. |
| + | - **Static Code Analysis (SCA):** Rulați utilitarele de analiză statică (''ESLint'' pentru React, ''golangci-lint'' și ''gosec'' pentru Go). | ||
| + | - **SBOM (Software Bill of Materials):** Generați inventarul dependințelor cu ''Syft'' sau ''CycloneDX'' și exportați rezultatul în format JSON sau XML. | ||
| - | ==== 4. Integrarea auditului în procesul de dezvoltare ==== | + | <note hint> |
| - | * Configurarea analizelor automate în pipeline-ul CI/CD | + | În GitHub Actions, utilizați ''actions/upload-artifact'' pentru a expune rapoartele generate (coverage, SBOM) după finalizarea execuției. |
| - | * Monitorizarea continuă a vulnerabilităților cu GitHub Security Alerts | + | </note> |
| - | * Crearea unui proces de **Security Review** înainte de lansarea în producție | + | |
| - | ===== Evaluare ===== | + | ==== Exercițiul 3: Condiții de halt și branch protection ==== |
| - | * Realizarea unui audit de securitate detaliat (30%) | + | **Cerințe:** |
| - | * Clasificarea și prioritizarea vulnerabilităților în funcție de impact (20%) | + | - **Fail-Fast:** Configurați pipeline-ul să se întrerupă (Halt) imediat dacă o etapă critică a aplicației web eșuează. Exemple: un test pică, valoarea code coverage este sub 80%, sau utilitarul SCA raportează o vulnerabilitate de severitate HIGH. |
| - | * Aplicarea măsurilor de remediere și verificarea fixurilor (30%) | + | - **Branch protection:** Din setările repository-ului, aplicați reguli de protecție pe branch-ul ''main''. Configurați blocarea operațiunii de Merge pentru orice Pull Request dacă pipeline-ul (status checks) nu s-a finalizat cu succes. |
| - | * Integrarea auditului în fluxul de dezvoltare (20%) | + | |
| - | ===== Resurse suplimentare ===== | + | ==== Exercițiul 4: Evaluarea OpenSSF Scorecard ==== |
| - | * [https://owasp.org/www-project-zap/ OWASP ZAP - Web Security Scanner] | + | OpenSSF Scorecard evaluează automat aderarea repository-ului la bunele practici de securitate (ex. managementul permisiunilor, actualizarea dependințelor). |
| - | * [https://owasp.org/www-project-top-ten/ OWASP Top 10 Security Risks] | + | **Cerințe:** |
| - | * [https://sonarqube.org SonarQube - Static Code Analysis] | + | - Integrați acțiunea OpenSSF Scorecard într-un job separat din pipeline. |
| - | * [https://github.com/aquasecurity/trivy Trivy - Vulnerability Scanner] | + | - Inspectați log-urile sau fișierul SARIF rezultat pentru a identifica scorul general. |
| - | * [https://cwe.mitre.org Common Weakness Enumeration (CWE)] | + | - Alegeți un criteriu penalizat (ex. dependințe nefixate prin SHA, permisiuni excesive acordate token-ului de GitHub Actions) și implementați modificarea necesară pentru a crește scorul. |
| + | ==== Exercițiul 5: Extragerea metricilor de contribuție ==== | ||
| + | **Cerințe:** | ||
| + | - Creați o etapă finală în pipeline care interoghează API-ul platformei (ex. GitHub REST API) pentru a obține statistici despre contribuitori. | ||
| + | - Procesați răspunsul JSON cu un script Bash (folosind ''jq'') sau Python și afișați la standard output (stdout) un tabel formatat conform structurii de mai jos: | ||
| + | ^ User GitHub ^ Nr. Commituri ^ Nr. Pull Requests ^ | ||
| + | | ioan_dev | 34 | 5 | | ||
| + | | maria_front | 42 | 7 | | ||
| + | | andrei_qa | 15 | 2 | | ||
| + | <note tip> | ||
| + | Pentru a simplifica autentificarea API, utilizați GitHub CLI (''gh api'') direct în pipeline. Utilitarul este preinstalat pe runner-ele GitHub și va prelua automat token-ul din context. | ||
| + | </note> | ||
| + | |||
| + | ==== Exercițiul 6: BONUS - Extinderea arhitecturii pentru Mobile și Embedded ==== | ||
| + | Extindeți pipeline-ul CI/CD adăugând workflow-uri complet izolate pentru componentele opționale Mobile și IoT, utilizând toolchain-urile platformelor specifice. Exportați rezultatele ca artifacte și aplicați politicile de Fail-Fast setate la Exercițiul 3. | ||
| + | **Cerințe:** | ||
| + | - **Componenta Mobile (Kotlin / Android Nativ):** | ||
| + | * **Unit Testing:** Rulați testele de logică folosind ''JUnit'' (sau ''Kotest''). | ||
| + | * **Code Coverage:** Generați rapoartele de acoperire folosind plugin-ul ''JaCoCo'' (sau ''EclEmma''). | ||
| + | * **SCA:** Integrați ''Detekt'' pentru analiza codului Kotlin și ''Android Lint'' pentru identificarea erorilor specifice platformei Android. | ||
| + | * **Fuzzing / PBT:** Utilizați ''Jazzer'' pentru a descoperi crash-uri la nivel de JVM sau componenta de Property-Based Testing din ''Kotest''. | ||
| + | * **SBOM:** Generați inventarul dependințelor prin plugin-ul gradle ''CycloneDX''. | ||
| + | - **Componenta IoT (ESP32-CAM / C/C++):** | ||
| + | * **Unit Testing:** Verificați funcțiile izolate prin framework-ul ''Unity''. | ||
| + | * **Code Coverage:** Utilizați ''gcovr'' împreună cu utilitarele din ''PlatformIO''. | ||
| + | * **SCA:** Folosiți ''Clang-Tidy''. Activați seturile de reguli ''CERT'' (pentru securitate cibernetică) sau ''MISRA'' (pentru fiabilitate). | ||
| + | * **Fuzzing:** Implementați teste cu ''libFuzzer'' sau ''AFL++'' pentru parsatoarele de rețea. | ||
| + | * **SBOM:** Exportați lista pachetelor utilizate la compilare folosind ''Syft''. | ||
