Eșecul Auditului de Securitate din Cauza unei Pană a Registrului npm

Autorul detaliază o experiență frustrantă în care o corecție pentru un aviz de securitate al pachetului safari-mcp a cauzat, neintenționat, eșecul pipeline-ului său de Integrare Continuă (CI). După lansarea versiunii 2.18.0, autorul a descoperit un PR Dependabot deschis pentru actualizarea pachetului 'qs' din cauza unor avize de securitate. A fuzionat această actualizare și a lansat o nouă versiune, 2.18.1, cu intenția de a remedia avizele. Cu toate acestea, pipeline-ul CI pentru această nouă lansare a eșuat deoarece comanda `npm audit` nu a putut accesa endpoint-ul de audit al registrului npm, returnând o eroare 503 Service Unavailable. Acest eșec, apărut pe o versiune Node.js în matricea de testare, a declanșat setarea `fail-fast`, anulând alte joburi și indicând incorect o problemă de securitate unde nu exista niciuna. Autorul subliniază că depozitul nu avea avize deschise la momentul eșecului auditului, făcând starea CI roșie deosebit de problematică.

Din punct de vedere tehnic, pasul CI `npm audit --audit-level=high --omit=dev` este conceput să eșueze dacă sunt găsite vulnerabilități sau dacă auditul nu poate fi efectuat. Problema a apărut deoarece strategia `fail-fast` pe jobul matricei a contopit motive distincte de eșec într-un singur indicator roșu. Mai mult, eticheta de lansare a fost creată și publicată înainte ca pipeline-ul CI pentru acel commit specific să se finalizeze, transformând starea CI dintr-un gardian într-un indicator întârziat și, în acest caz, înșelător. Autorul menționează că depozitul nu avea avize deschise la momentul eșecului auditului, făcând starea CI roșie deosebit de problematică.

Pentru a rezolva această problemă, au fost implementate două modificări: dezactivarea `fail-fast` în strategia matricei pentru a permite fiecărei versiuni Node.js să-și raporteze propriul status și modificarea pasului de audit pentru a reîncerca comanda `npm audit` de până la trei ori pentru erori tranzitorii de rețea, cum ar fi 503. O vulnerabilitate reală va cauza în continuare un eșec imediat, dar indisponibilitatea temporară a registrului va fi acum gestionată cu reîncercări, iar ieșirea va diferenția între o descoperire reală și o problemă de rețea. Autorul recunoaște că problema fundamentală de ordonare, unde eticheta de lansare este publicată înainte ca CI să se finalizeze, rămâne nerezolvată.