{"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 lavoro e confronto SCA. Prima parte","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

L'importanza dell'analisi dei componenti software di terze parti (Software Composition Analysis \u2014 SCA) aumenta durante il processo di sviluppo, mano a mano che vengono pubblicati report annuali sulle vulnerabilit\u00e0 delle librerie open source dalle aziende Synopsys, Sonatype, Snyk e White Source. Secondo il rapporto Lo stato delle vulnerabilit\u00e0 nella sicurezza open source 2020<\/a><\/noindex> il numero di vulnerabilit\u00e0 identificate nell'open source \u00e8 aumentato quasi di 1.5 volte nel 2019 rispetto all'anno precedente, mentre i componenti open source sono utilizzati in dal 60% all'80% dei progetti. Se consideriamo l'opinione di esperti, i processi SCA sono una pratica distinta secondo OWASP SAMM e BSIMM come indicatore di maturit\u00e0. Nella prima met\u00e0 del 2020, OWASP ha rilasciato un nuovo standard, l'OWASP Software Component Verification Standard (SCVS), che offre le migliori pratiche per la verifica dei componenti di terze parti nella catena di fornitura del software.<\/p>\n

\"DevSecOps:
\n<\/a><\/noindex>
\nUno dei casi pi\u00f9 significativi \u00e8 avvenuto<\/a><\/noindex> con la compagnia Equifax a maggio 2017. Sconosciuti hacker hanno ottenuto informazioni su 143 milioni di americani, comprese le loro nomi completi, indirizzi, numeri di previdenza sociale e patenti di guida. In 209.000 casi, erano presenti anche informazioni sulle carte di credito delle vittime. Questa violazione \u00e8 avvenuta a causa di un'importante vulnerabilit\u00e0 in Apache Struts 2 (CVE-2017-5638), mentre una patch era gi\u00e0 stata rilasciata a marzo 2017. L'azienda ha avuto due mesi per installare l'aggiornamento, ma nessuno se ne \u00e8 occupato.<\/p>\n

In questo articolo si discuter\u00e0 la scelta dello strumento per effettuare SCA dal punto di vista della qualit\u00e0 dei risultati dell'analisi. Verr\u00e0 inoltre 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 gamma di strumenti \u00e8 stata presentata da OWASP sul suo sito web<\/a><\/noindex>, ma in questo articolo ci concentreremo solo sugli strumenti open source pi\u00f9 popolari: Dependency Check, la piattaforma open source meno conosciuta Dependency Track e la soluzione Enterprise Sonatype Nexus IQ. Inoltre, analizzeremo come funzionano queste soluzioni e confronteremo i risultati ottenuti in termini di falsi positivi.<\/p>\n

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

Principio di funzionamento<\/h3>\n

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

Vediamo come appare una 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