Att hitta en sårbarhet är den enkla delen. Säkerhetsarbetet handlar om att få korrigeringen mergad och driftsatt. För sårbara beroenden öppnar därför Coroid själv en uppgraderings- pull request, som ditt team granskar och mergar.
När Coroid öppnar en
När Åtgärda sårbara beroenden är aktiverat öppnas en åtgärdsuppgift i projektet för ett beroendefynd med allvarlighetsgrad som motsvarar eller överstiger åtgärdsgränsen (hög som standard):
- En uppgift och en pull request per paket, som omfattar alla säkerhetsmeddelanden som berör paketet.
- Kritiska fynd först, därefter allvarliga.
- Högst 5 öppna åtgärds-pull requests per projekt som standard (upp till 50). Nästa åtgärd väntar tills en plats blir ledig.
Ägare och administratörer kan också välja Åtgärda för alla öppna beroendefynd där säkerhetsmeddelandet är offentligt. Om ingen korrigerad version har släppts erbjuder Åtgärda i stället en åtgärdsuppgift: ta bort eller ersätt paketet, lås fast en korrigerad fork eller skydda det sårbara anropet.
Automatiska uppgraderingar fungerar för npm-projekt i nuläget. För andra ekosystem står det i fyndet ”Ingen automatisk korrigering finns ännu för det här ekosystemet”, och Åtgärda erbjuder åtgärdsuppgiften.
Vad som bekostar arbetet
Åtgärdsuppgifter följer en AI-modell och förbrukar därför agenttimmar, precis som annat arbete. De körs under det inbyggda Säkerhetskorrigeringar -mandatet, som finns för alla organisationer:
- Omfattning: uppgraderingar av beroenden och säkerhetsåtgärder, inget annat.
- Budget: endast agenttimmar, som standard en fjärdedel av planens agenttimmar per månad. Ägare ändrar antalet timmar och om de räknas per vecka eller månad under Säkerhet → Inställningar → Åtgärda sårbara beroenden.
- Ingen granskningstid går ut. Det är en permanent standardinställning, inte något som behöver förnyas.
- Prioritet: säkerhetskorrigeringar tas in före annat arbete som startas på eget initiativ.
Om du inaktiverar Åtgärda sårbara beroenden som standardinställning för organisationen pausas mandatet. Mandatet visas tillsammans med de andra under Kvalitetskontroll → Mandat.
När en organisation som redan har anslutna repositoryn får Säkerhet får dess ägare ett meddelande under klockikonen: ”Säkerhetskorrigeringar startar om sju dagar”. Åtgärdsarbetet startar sju dagar efter att meddelandet har levererats, så att en ägare hinner inaktivera det innan den första pull request skapas. Nya organisationer startar direkt.
Varför en åtgärd kan behöva vänta
I avsnittet om åtgärder för ett fynd står det vad som väntas på. Vanliga orsaker:
- gränsen för öppna pull request i projektet har nåtts;
- mandatets budget eller planens agenttimmar är förbrukade (detekteringen fortsätter);
- agentarbete är pausat i Mission Control, eller så finns ingen ledig agentplats;
- meddelandeperioden på sju dagar har inte löpt ut;
- ingen kompatibel korrigering har släppts, eller så finns ingen automatisk korrigering för ekosystemet;
- Åtgärda sårbara beroenden är inaktiverat.
Så väljs uppgraderingen
För varje plats där ett sårbart paket är installerat väljer Coroid den lägsta versionen över den installerade versionen som åtgärdar alla säkerhetsmeddelanden som berör paketet, och håller sig om möjligt inom det angivna versionsintervallet och huvudversionen. En nedgradering görs aldrig. Om en workspace behöver en huvudversion och en annan workspace behöver en annan får de var sin korrigerad version i samma pull request. Ett transitivt paket uppgraderas via sin förälders uppgradering eller pakethanterarens override. Om en huvudversion ändras eller flera versioner slås ihop till en anges skälet i pull request. Om ingen enskild uppgradering åtgärdar allt korrigerar pull requesten det som går och listar resten som ej åtgärdat.
Vad pull request innehåller
- Säkerhetsmeddelandena som åtgärdas, med deras allvarlighetsgrad.
- Projektets paketförteckning före och efter ändringen, som visar att den sårbara versionen har försvunnit.
- Projektets kontroller: om projektets Delivery-graf innehåller kontroller som kan köras måste de få statusen GO AHEAD för den pushade ändringen innan Coroid öppnar pull request; annars avslutas uppgiften med en förklaring. Om projektet inte har några konfigurerade kontroller öppnas ändå pull request. Där står det att Coroid inte körde några projektkontroller, att projektets egen CI körs på pull request och var du konfigurerar kontroller i Kvalitetskontroll.
- Skälen till eventuella ändringar av huvudversion eller versionsintervall.
- Eventuella säkerhetsmeddelanden som inte kunde åtgärdas, listade som ej åtgärdade.
Den avslutas med: ”Människor granskar och mergar. Driftsättningsstatus avgörs endast genom en skanning av den driftsatta revisionen.” Fyndet markeras som åtgärdat i koden efter nästa fullständiga inventering och som åtgärdat i respektive miljö efter en skanning av den revision som miljön kör. Se Fynd och deras livscykel.
Kodfynd
För ett kodfynd Åtgärda skapar en uppgift för att åtgärda det i projektet. Ägare och administratörer kan använda funktionen för alla öppna kodfynd. Uppgiften ber utvecklaren att beskriva korrigeringen, inte attacken, i commit-meddelanden och i pull request, samt att lägga till ett regressionstest. Den följer samma regler som andra uppgifter och förbrukar agenttimmar.
I ett offentligt repository, eller ett vars synlighet Coroid inte kan bekräfta, committas inte en korrigering för ett fynd som ännu inte är offentligt där. Coroid sparar den förberedda ändringen privat så att en ägare eller administratör kan publicera den. Se Offentliggörande.
Läckta hemligheter
En läckt autentiseringsuppgift åtgärdas genom att byta ut den, vilket Coroid inte kan göra åt dig. Om du väljer Åtgärda för ett hemlighetsfynd skapas i stället en uppgift med en checklista. Se Läckta hemligheter.