{"id":92519,"date":"2020-08-28T07:42:26","date_gmt":"2020-08-28T05:42:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devsecops-princzipy-raboty-i-sravnenie-sca-chast-pervaya"},"modified":"2020-08-28T07:42:26","modified_gmt":"2020-08-28T05:42:26","slug":"devsecops-princzipy-raboty-i-sravnenie-sca-chast-pervaya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/devsecops-princzipy-raboty-i-sravnenie-sca-chast-pervaya","title":{"rendered":"DevSecOps: principi di funzionamento e confronto SCA. Parte prima","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

L'importanza dell'analisi dei componenti software di terze parti (inglese: Software Composition Analysis - SCA) nel processo di sviluppo cresce man mano che vengono pubblicati annualmente rapporti sulle vulnerabilit\u00e0 delle librerie open source dalle aziende Synopsys, Sonatype, Snyk, White Source. Secondo il rapporto La situazione delle vulnerabilit\u00e0 di sicurezza nel software open source 2020<\/a><\/noindex> il numero di vulnerabilit\u00e0 scoperte nel software open source nel 2019 \u00e8 aumentato di quasi 1,5 volte rispetto all'anno precedente, mentre i componenti open source sono utilizzati nel 60% - 80% dei progetti. Secondo un parere indipendente, i processi SCA rappresentano una pratica separata all'interno degli standard OWASP SAMM e BSIMM come indicatore di maturit\u00e0, e nella prima met\u00e0 del 2020, OWASP ha pubblicato un nuovo standard, l'OWASP Software Component Verification Standard (SCVS), che fornisce le migliori pratiche per la verifica dei componenti di terze parti nella catena di approvvigionamento software.<\/p>\n

\"DevSecOps:
\n<\/a><\/noindex>
\nUno dei casi pi\u00f9 emblematici \u00e8 avvenuto<\/a><\/noindex> con l'azienda Equifax nel maggio 2017. Sconosciuti hacker hanno ottenuto informazioni su 143 milioni di americani, incluse le loro nomi completi, indirizzi, numeri di previdenza sociale e patenti di guida. In 209.000 casi, nei documenti era anche presente l'informazione sulle carte di credito delle vittime. Questa violazione \u00e8 avvenuta a seguito dello sfruttamento di una vulnerabilit\u00e0 critica in Apache Struts 2 (CVE-2017-5638), mentre la patch era stata rilasciata gi\u00e0 a marzo 2017. L'azienda aveva due mesi per installare l'aggiornamento, ma nessuno si \u00e8 preoccupato di farlo.<\/p>\n

In questo articolo si discuter\u00e0 della scelta dello strumento per condurre la SCA dal punto di vista della qualit\u00e0 dei risultati dell'analisi. Sar\u00e0 anche fornito un confronto funzionale degli strumenti. Il processo di integrazione in CI\/CD e le possibilit\u00e0 di integrazione saranno trattati in pubblicazioni successive. Una vasta lista di strumenti \u00e8 stata presentata da OWASP sul proprio sito<\/a><\/noindex>, ma nel presente studio ci concentreremo solo sullo strumento open source pi\u00f9 popolare, Dependency Check, sulla piattaforma open source meno conosciuta Dependency Track e sulla soluzione enterprise Sonatype Nexus IQ. Analizzeremo anche come funzionano queste soluzioni e confronteremo i risultati ottenuti riguardo ai falsi positivi.<\/p>\n

\"DevSecOps:
\n<\/p>\n

Il principio di funzionamento<\/h3>\n

\nDependency Check<\/a><\/noindex> \u00e8 uno strumento (CLI, maven, modulo jenkins, ant) che analizza i file del progetto, raccoglie frammenti di informazioni sulle dipendenze (nome pacchetto, groupid, titolo specifica, versione\u2026), costruisce una stringa CPE \u2014 (Common Platform Enumeration), Package URL (PURL) e identifica per CPE\/PURL vulnerabilit\u00e0 da database (NVD, Sonatype OSS Index, NPM Audit API\u2026), dopodich\u00e9 genera un rapporto una tantum in formato HTML, JSON, XML\u2026<\/p>\n

Vediamo come appare un CPE:<\/p>\n

cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other<\/code><\/pre>\n
<\/p>\n