Security håller en inventering av alla paket som varje projekt installerar och matchar dem mot publicerade säkerhetsråd. Då upptäcks en sårbar version när den läggs till i en pull request och på nytt när ett nytt säkerhetsråd gäller en version som du redan använder.
Inventeringen
Vid varje ny commit på standardgrenen och minst en gång om dagen läser Coroid projektets lockfiler med OSV-Scanner, låst till en version och verifierad mot dess publicerade kontrollsumma. Skannern får bara beroendefilerna och en konfiguration som Coroid skapar. Den har ingen nätverksåtkomst och inga inloggningsuppgifter. En repos egen osv-scanner.toml påverkar inte detta.
Security → Dependencies visar inventeringen för varje projekt: paketen och deras installerade versioner, vilket manifest som anger varje paket, vilka som är sårbara, täckningen för varje fil och när säkerhetsrådsdata senast lästes in. Exportera CycloneDX laddar ned inventeringen som en CycloneDX 1.5-fil. Den listar sårbarheter endast för fynd som redan är offentliga. Se Hantering av sårbarhetsinformation.
Vad Coroid läser fullständigt
Täckningen gäller per lockfil, inte per repo. I ett monorepo är varje lockfil en egen grupp med egen täckning. Resultaten från en fullständigt läst lockfil gäller alltså även om ett annat manifest bara har delvis täckning.
| Fil | Ekosystem | Exakta versioner | Fullständiga transitiva beroenden | Täckning |
|---|---|---|---|---|
package-lock.json | npm | Ja | Ja | Fullständig |
npm-shrinkwrap.json | npm | Ja | Ja | Fullständig |
pnpm-lock.yaml | npm | Ja | Ja | Fullständig |
yarn.lock | npm | Ja | Ja | Fullständig |
requirements.txt | PyPI | Ja | Nej | Delvis |
go.mod | Go | Ja | Nej | Delvis |
Tabellen genereras genom att skannern körs på testfixturerna i Coroid egna tester. Den ändras därför bara när testerna ändras.
- npm workspaces, pnpm och Yarn: en workspaces
package.jsonutan egen lockfil täcks av rotens lockfil. Enpackage.jsonsom inte längre stämmer överens med sin lockfil har delvis täckning tills lockfilen genereras på nytt. - npm-lockfiler måste ha version 2 eller 3. Poster i pnpm och Yarn som kommer från git, en lokal fil eller en patch ger delvis täckning.
requirements.txttäcker endast versioner som är låsta med==.- Andra beroendefiler (
package.jsonutan lockfil,pyproject.toml,poetry.lock,Pipfile,Cargo.lock,Gemfile.lock,pom.xml, Gradle, Composer, NuGet och andra) identifieras och visas med delvis täckning och filnamn. Därmed visas aldrig ett projekt som täckt när det inte är det.
Säkerhetsråd
Coroid hämtar säkerhetsråd från OSV, som även innehåller GitHubs säkerhetsråd, för varje ekosystem som dina projekt använder. Varje timme hämtas nytt eller ändrat innehåll sedan den senaste hämtningen, och en gång om dagen hämtas allt. Matchningen använder de sparade inventeringarna och behöver därför inte åtkomst till ditt repo.
Coroid har som mål att matcha 95 % av nya säkerhetsråd mot varje inventering inom 60 minuter från att de publiceras i de säkerhetsrådsdata som läses in. Tiden för varje matchning mäts. Ingen tidsgräns kan utlovas från det att en sårbarhet först offentliggörs, eftersom det beror på när ett säkerhetsråd publiceras.
Om säkerhetsrådsdata är mer än 90 minuter gamla eller den senaste hämtningen misslyckades visas ”Fördröjning i säkerhetsrådsflödet sedan …” under Översikt och Dependencies. Ingen projektöversikt visar då fullständig täckning.
När ett säkerhetsråd dras tillbaka räknar Coroid om vad som fortfarande gäller utifrån återstående säkerhetsråd för samma sårbarhet. Ett fynd stängs som ”Gäller inte längre” endast om inget av säkerhetsråden gäller, aldrig som åtgärdat.
På pull requests
Kontrollen Coroid Security skannar de lockfiler som en pull request ändrar, både på dess bas och på dess head, och räknar bara sårbara versioner som ändringen introducerar:
- Observera: kontrollen godkänns eller rapporterar neutralt vad den hittade.
- Tillämpa: en ändring som introducerar en känd sårbar version med vald allvarlighetsgrad eller högre (hög som standard) gör att kontrollen misslyckas. Även delvis täckning för en lockfil som ändringen berör gör att kontrollen misslyckas. Den anger då orsaken och hur du kör den igen.
Samma kontroll körs på Coroids egna pull requests för korrigeringar och nya funktioner innan de öppnas. Läs om hur kontrollen fungerar, hur du gör den obligatorisk och hur du kör den igen i behörigheter för GitHub och kontrollen Coroid Security.
Aviseringar
Den första fullständiga inventeringen av ett repo blir en tyst baslinje: fynden visas i Security och ingen får någon avisering. Därefter meddelas organisationens ägare och administratörer en gång när ett nytt kritiskt beroendefynd upptäcks: via klockikonen, via e-post om e-postaviseringar är aktiverade och i Slack om Slack är anslutet. För ett offentligt säkerhetsråd anger aviseringen paketet och säkerhetsrådet. Om informationen ännu inte är offentlig står det bara att ett kritiskt fynd behöver uppmärksammas. Se Hantering av sårbarhetsinformation.