Den 19 mars 2026 tystnade larmen inte när Trivy, ett av världens mest använda skanningsverktyg för containersäkerhet, själv blev vapnet. En grupp som spåras som TeamPCP tryckte in skadlig kod direkt i projektets repo och vände sedan stulna autentiseringsuppgifter mot Checkmarx KICS och över 50 npm-paket. Händelsen fick beteckningen CVE-2026-33634 med CVSS-poäng 9,4, och den satte fingret på en obekväm sanning: verktygen du litar på för att hitta sårbarheter kan själva vara måltavlan. Den här guiden visar hur du använder OpenSSF Scorecard, ett gratis verktyg från Open Source Security Foundation, för att systematiskt granska om ett beroende eller en säkerhetskomponent följer grundläggande säkerhetspraxis innan du bygger in den i din pipeline.
Vi går igenom installation på tre olika sätt, hur du tolkar de tjugo underliggande kontrollerna, hur du automatiserar skanningen i GitHub Actions, hur du frågar OpenSSFs publika dataset istället för att skanna själv, och hur du bygger en policy-grind som stoppar riskabla paket innan de når produktion. På vägen tittar vi också på fem vanliga fallgropar, nio konkreta felsökningsscenarier och ett komplett, körbart projektupplägg du kan kopiera rakt av till ditt eget team.
Vad hände med Trivy i mars 2026 och varför det spelar roll
Kampanjen pågick mellan 19 och 27 mars 2026 enligt Cloud Security Alliance, som senare myntade termen “reflexiv leveranskedjeattack” för mönstret: angripare kompromitterar just de skanner, statiska analysverktyg eller pakethanterare som organisationer litar på för sitt eget försvar. Red Hats säkerhetsbulletin RHSB-2026-001, publicerad den 1 april 2026, listade Trivy, Checkmarx KICS, LiteLLM, Axios och Telnyx bland de drabbade projekten. Läs mer om själva attacken i vår genomgång av TeamPCP-kampanjen.
Cloud Security Alliance publicerade sin fördjupade analys av mönstret den 8 april 2026 och har därefter uppdaterat den löpande, senast den 25 september 2026, vilket visar att organisationen fortfarande bedömer frågan som aktuell ett halvår efter den ursprungliga händelsen. Det är ovanligt länge för en enskild säkerhetsincident att hållas levande i den formen, och det säger något om hur allvarligt branschen ser på att just förtroendet för säkerhetsverktygens egen kedja rubbades.
Problemet är inte unikt för en enskild incident. En granskning publicerad i augusti 2026 gick igenom 56 verkliga leveranskedjeattacker mellan augusti 2025 och augusti 2026, spridda över npm, PyPI, RubyGems, Composer och crates.io. Trenden pekar uppåt i både frekvens och skadeomfång. Samtidigt visade forskning från Georgia Tech i mars 2026 att AI-genererad kod bidrog till 35 nya CVE:er på en enda månad, upp från 6 i januari och 15 i februari, med forskare som bedömer att det verkliga antalet i hela ekosystemet kan vara fem till tio gånger högre. Den gemensamma nämnaren är enkel: ingen granskar längre koden manuellt i den takt den skrivs, vare sig den kommer från en människa eller en AI-assistent.
Det är här OpenSSF Scorecard fyller ett tomrum. Istället för att skanna din egen kod efter sårbarheter, som Trivy eller Semgrep gör, granskar Scorecard utvecklingspraxis hos projekten du bygger på. Frågan är inte “har den här koden en bugg just nu” utan “sköts det här projektet på ett sätt som gör framtida buggar och intrång mindre sannolika”.
En reflexiv leveranskedjeattack, förklarad
En vanlig leveranskedjeattack riktar in sig på en applikation, till exempel genom ett förgiftat npm-paket som läggs till i din package.json. En reflexiv leveranskedjeattack riktar istället in sig på själva försvaret. Enligt Cloud Security Alliance handlar det om att kompromissa “scanners, static analysis engines, package managers, AI gateways” så att verktyg som är byggda för att skydda dig istället blir en spridningsväg. Trivy-fallet är det tydligaste exemplet hittills, men rapporten pekar på att mönstret redan har observerats mot fler kategorier av utvecklarverktyg under 2026. En analys från februari 2026 av 64 öppna säkerhetsverktyg för applikationssäkerhet visade att just kategorin verktyg för beroendeanalys, Software Composition Analysis, hade det högsta genomsnittliga hälsobetyget av alla kategorier, 61,6 poäng, vilket speglar att investeringarna i den typen av verktyg redan var höga innan Trivy-incidenten. Det gjorde det extra uppseendeväckande att just ett sådant verktyg blev måltavlan.
Vad är OpenSSF Scorecard och varför ska du använda det
OpenSSF Scorecard är ett automatiserat verktyg som utvärderar ett antal säkerhetsheuristiker, kallade kontroller, för ett givet GitHub- eller GitLab-repo och tilldelar varje kontroll en poäng mellan 0 och 10. Projektet beskriver själva syftet såhär: “We created Scorecard to help open source maintainers improve their security best practices and to help open source consumers judge whether their dependencies are safe” (OpenSSF Scorecard project, github.com/ossf/scorecard).
Verktyget ägs och underhålls av Open Source Security Foundation (OpenSSF), samma organisation som står bakom Sigstore och SLSA-ramverket för byggkedjor. Scorecard lanserades i november 2020, och OpenSSF skrev då att målet var att “auto-generate a ‘security score’ for open source projects to help users as they decide the trust, risk, and security posture for their use case” (OpenSSF, openssf.org). Sex år senare är principen densamma, men omfattningen har vuxit kraftigt: projektet kör idag en veckovis skanning av de en miljon mest kritiska open source-projekten, rankade efter hur många andra projekt som beror på dem, och publicerar resultaten öppet.
Du kan också använda Scorecard för att, som projektet själva uttrycker det, “assess the risks that dependencies introduce, and make informed decisions about accepting these risks, evaluating alternative solutions, or working with the maintainers to make improvements” (OpenSSF Scorecard project, github.com/ossf/scorecard). Det är precis den arbetsgången den här guiden bygger på.
Scorecard jämfört med skanning av sårbarheter och signering
Det är lätt att blanda ihop Scorecard med andra verktyg i samma verktygslåda, men de svarar på olika frågor. En sårbarhetsskanner talar om vilka kända CVE:er som finns i koden just nu. En signeringslösning talar om huruvida artefakten du laddar ner faktiskt kommer från rätt avsändare. Scorecard talar om hur troligt det är att morgondagens sårbarhet upptäcks och åtgärdas snabbt, baserat på hur projektet faktiskt drivs. Tabellen nedan sammanfattar skillnaden mellan de vanligaste verktygen i en modern leveranskedjepipeline.
| Verktyg | Vad det svarar på | När du kör det |
|---|---|---|
| OpenSSF Scorecard | Följer projektet god säkerhetspraxis (kodgranskning, signering, branch-skydd)? | Innan du väljer ett nytt beroende, och löpande i CI |
| Trivy / OSV-Scanner | Finns det kända, publicerade CVE:er i koden just nu? | Vid varje build och container-push |
| Cosign / Sigstore | Kommer den här specifika artefakten verkligen från rätt pipeline? | Vid installation eller deploy av en byggd artefakt |
| SBOM (CycloneDX/SPDX) | Vad består mjukvaran faktiskt av, ner till varje transitivt beroende? | Vid release, och vid incidentutredning |
Ingen av raderna i tabellen ersätter de andra. Ett projekt kan ha noll kända CVE:er och ändå ha ett svagt Scorecard-betyg om det saknar kodgranskning och branch-skydd, vilket bara betyder att nästa sårbarhet troligen dröjer längre innan den upptäcks och patchas.
Förkunskaper: detta behöver du innan du börjar
Du behöver inte vara säkerhetsexpert för att följa den här guiden, men några saker bör finnas på plats innan du sätter igång. Räkna med cirka 90 minuter för att gå igenom samtliga 13 steg, inklusive att sätta upp automatiseringen.
| Krav | Detaljer |
|---|---|
| OpenSSF Scorecard | Version 5.5.0 (senaste stabila release, 23 april 2026) |
| Operativsystem | Linux, macOS eller Windows via WSL2 |
| Containermotor | Docker installerat och igång (rekommenderas, kräver ingen Go-installation) |
| Alternativ: Go | Installerat om du vill bygga från källkod istället för att använda Docker |
| GitHub-konto | Med behörighet att skapa Personal Access Token för repot du vill granska |
| Git | Installerat för att klona repon lokalt |
| CI/CD-plattform | GitHub Actions (för automatiseringsstegen senare i guiden) |
| Tid | Cirka 90 minuter för hela guiden |
Har du redan kört Trivy för containerskanning eller OSV-Scanner för sårbara beroenden i din pipeline sedan tidigare känner du redan igen mönstret. Scorecard kompletterar båda genom att titta på processen bakom koden snarare än koden själv.
Du behöver inte administratörsrättigheter i de repon du granskar. Scorecard läser enbart publik metadata och historik via GitHubs API, det skriver aldrig till repot du skannar, och det kräver ingen installation eller åtkomst hos underhållarna av projektet du granskar. Det gör verktyget lika användbart för en enskild utvecklare som vill kontrollera ett paket innan installation, som för ett säkerhetsteam som vill bygga en organisationsövergripande policy.
Steg 1 till 3: installera OpenSSF Scorecard
Det finns tre officiella installationsvägar: en fristående binär från releasesidan, Homebrew, eller Docker. Vi går igenom alla tre så du kan välja det som passar din miljö bäst.
Steg 1: Installera via Homebrew (macOS och Linux). Det snabbaste sättet om du redan har Homebrew installerat.
brew install scorecard
scorecard versionSteg 2: Installera via Docker. Från och med version 5.5.0 flyttade projektet sina officiella containeravbildningar till GitHub Container Registry. Det här alternativet kräver varken Go eller Homebrew, bara en fungerande Docker-installation.
docker pull ghcr.io/ossf/scorecard:v5.5.0
docker run -e GITHUB_AUTH_TOKEN=DIN_TOKEN \
ghcr.io/ossf/scorecard:v5.5.0 \
--show-details --repo=https://github.com/ossf/scorecardSteg 3: Fristående binär. Ladda ner rätt arkiv för ditt operativsystem från projektets releasesida på GitHub och lägg binären i din GOPATH/bin. Det här alternativet passar dig som vill bygga in Scorecard i egna skript utan ett containerlager emellan. Om du hellre bygger från källkod behöver du ha Go installerat enligt projektets officiella installationsanvisningar på golang.org.
Oavsett väg, verifiera installationen innan du går vidare. Kör scorecard version (eller motsvarande docker run ... version) och kontrollera att utskriften visar 5.5.0 eller senare.
Vilken metod du bör välja beror på var du tänker köra verktyget. Homebrew passar bäst för lokal, manuell användning på din egen maskin där du redan har paketverktyget installerat sedan tidigare. Docker är det säkraste valet i CI/CD, eftersom du slipper hantera Go-beroenden i byggmiljön och kan pinna en exakt image-tagg, vilket gör att alla körningar i teamet garanterat använder samma version. Den fristående binären är rätt val om du bygger egna verktyg ovanpå Scorecard, till exempel ett internt dashboard som anropar kommandot direkt utan ett containerlager i vägen.
Steg 4 och 5: skapa GitHub-token och kör din första skanning
Steg 4: Skapa en Personal Access Token. Scorecard använder GitHubs API för att hämta information om branch-skydd, granskningshistorik och workflows, vilket kräver autentisering för att undvika hastighetsbegränsningar. Gå till GitHubs inställningar för utvecklare, skapa en klassisk token med enbart läsbehörighet (public_repo räcker för publika repon), och spara den säkert. Sätt aldrig in tokenet direkt i kod som checkas in.
I CI/CD ska tokenet alltid ligga som en krypterad hemlighet i plattformens egen secret-hantering, till exempel GitHub Actions secrets, aldrig som en vanlig miljövariabel i klartext i workflow-filen. Ge tokenet enbart läsbehörighet, aldrig skrivrättigheter, eftersom Scorecard aldrig behöver ändra något i repot du granskar. Det är samma minimibehörighetsprincip som kontrollen Token-Permissions själv mäter hos andra projekt, så det är rimligt att applicera samma standard på sin egen pipeline.
export GITHUB_AUTH_TOKEN="din_token_har"Steg 5: Kör din första skanning. Testa mot ett repo du redan känner till, till exempel ett eget projekt eller ett beroende du använder ofta.
scorecard --repo=github.com/dittkonto/ditt-projekt --show-detailsKör mot ett repo med god säkerhetshygien ger dig ett facit att jämföra med senare. Testa gärna mot github.com/ossf/scorecard självt, det ger ett exempel på hur ett väl underhållet projekt brukar se ut i utskriften.
Ett bra första test är att köra samma kommando mot tre olika typer av repon: ditt eget interna projekt, ett stort och väletablerat open source-ramverk, och ett litet, mindre aktivt underhållet paket som du ändå har som beroende. Skillnaden i utskrift brukar bli tydlig direkt. Det stora ramverket landar oftast högt på Code-Review och Branch-Protection eftersom flera underhållare granskar varandras ändringar rutinmässigt, medan det mindre paketet ofta får låga poäng på Maintained och Security-Policy helt enkelt för att en enda person sköter allt på fritiden. Ingen av delarna är automatiskt farlig, men det ger dig underlag för att prioritera vilka beroenden som förtjänar en närmare manuell genomgång.
Steg 6: så tolkar du Scorecard-poängen från 0 till 10
Varje kontroll får en egen poäng mellan 0 och 10, och det sammanlagda värdet, aggregatpoängen, är ett viktat snitt av samtliga tillämpliga kontroller. Projektets egen dokumentation visar ett exempel med aggregatpoängen “7.9 / 10” för ett repo där de flesta kontroller klarade sig bra men där enstaka poster, som branch-skydd, drog ner snittet. En utskrift kan se ut ungefär så här:
Aggregate score: 7.9 / 10
Check scores:
10 / 10 Binary-Artifacts inga binärer hittades i repot
9 / 10 Branch-Protection grenskydd är inte fullt konfigurerat
8 / 10 Signed-Releases signaturer hittades i utgivna paket
3 / 10 Fuzzing ingen fuzzing-konfiguration hittades
0 / 10 Security-Policy ingen SECURITY.md hittades i repotPoängsättningen är inte binär. Vid kontrollen Signed-Releases ger till exempel en vanlig kryptografisk signatur på utgivna filer 8 poäng, medan en fullständig SLSA-provenienceattestering, som bevisar exakt hur och var paketet byggdes, ger maxpoäng 10. Ett lågt betyg på en enskild kontroll betyder inte automatiskt att projektet är farligt, men det ger dig en konkret riskyta att undersöka eller diskutera med underhållarna innan du drar in beroendet i din kodbas.
Steg 7: de 20 kontrollerna och vad de faktiskt mäter
Scorecard körde ursprungligen 19 samlade kontroller, men version 5.0 bröt upp dem i enskilda heuristiker så att team kan välja precis vilka de bryr sig om. Idag dokumenterar projektet 20 namngivna kontroller, indelade efter risknivå. Tabellen nedan täcker de mest centrala för en leveranskedjegranskning.
| Kontroll | Risknivå | Vad den mäter |
|---|---|---|
| Dangerous-Workflow | Kritisk | Osäkra mönster i GitHub Actions-workflows som kan leda till repo-kompromiss |
| Webhooks | Kritisk | Om webhooks kräver autentiseringstoken eller är öppna för tredje part |
| Branch-Protection | Hög | Om standard- och release-grenar skyddas mot direkta pushar och kräver granskning |
| Code-Review | Hög | Om ändringar kräver mänsklig granskning innan de mergas |
| Maintained | Hög | Aktivitetsnivå, en indikation på hur snabbt sårbarheter faktiskt patchas |
| Signed-Releases | Hög | Kryptografiska signaturer eller SLSA-provenience på utgivna artefakter |
| Token-Permissions | Hög | Om CI/CD-tokens följer principen om minsta möjliga behörighet |
| Vulnerabilities | Hög | Kända, opatchade sårbarheter i själva projektet |
| Binary-Artifacts | Hög | Förekomst av binärfiler som inte kan granskas i klartext |
| Dependency-Update-Tool | Hög | Automatiska verktyg som Dependabot eller Renovate för beroendeuppdateringar |
| Pinned-Dependencies | Medel | Om beroenden är låsta till specifika versioner eller hashar |
| SAST | Medel | Förekomst av statisk kodanalys i utvecklingsprocessen |
| SBOM | Medel | Om projektet publicerar en materialförteckning för sina beroenden |
| Fuzzing | Medel | Om projektet kör fuzz-testning för att hitta okända buggar |
Resterande sex kontroller, License, CI-Tests, CII-Best-Practices, Contributors, Packaging och Security-Policy, klassas som lågrisk men bidrar ändå till helhetsbilden. Kombinerar du resultatet med data från din egen SBOM-process får du en betydligt tydligare bild av vilka beroenden som faktiskt utgör en risk.
Kritiska kontroller du aldrig bör ignorera
Om du bara har tid att granska ett fåtal kontroller manuellt, börja med de två som är klassade som kritiska: Dangerous-Workflow och Webhooks. Båda pekar direkt mot precis den typ av svaghet som utnyttjades i Trivy-fallet, där angriparna fick skrivrättigheter i repot och kunde trycka in kod utan granskning. Ett projekt som saknar branch-skydd på sin huvudgren, kombinerat med ett svagt resultat på Code-Review, är i praktiken ett repo där vem som helst med rätt autentiseringsuppgifter kan ändra koden utan att någon annan ser det förrän i efterhand. Lägg därtill Token-Permissions: ett workflow som kör med skrivrättigheter det inte behöver är en extra dörr in, helt oavsett hur välskriven koden i övrigt är.
Steg 8 och 9: automatisera skanning med GitHub Actions
Steg 8: Lägg till den officiella Scorecard-actionen. Istället för att köra kommandot manuellt varje gång bör du schemalägga skanningen så att den körs automatiskt vid varje push och en gång i veckan. Skapa filen .github/workflows/scorecard.yml:
name: Scorecard analysis
on:
push:
branches: [main]
schedule:
- cron: '0 6 * * 1'
permissions: read-all
jobs:
analysis:
runs-on: ubuntu-latest
permissions:
security-events: write
id-token: write
contents: read
issues: read
pull-requests: read
checks: read
steps:
- uses: actions/checkout@v4
with:
persist-credentials: false
- uses: ossf/scorecard-action@v2
with:
results_file: results.sarif
results_format: sarif
publish_results: true
- uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: results.sarifSteg 9: Publicera och läs resultaten i GitHubs Security-flik. Med publish_results: true skickas resultatet till projektets publika API, vilket kräver behörigheten id-token: write så att GitHubs OIDC-token kan verifiera avsändaren. Ladda upp resultatet som SARIF, och det dyker automatiskt upp under fliken Security > Code scanning alerts i ditt repo, sida vid sida med resultat från exempelvis Gitleaks eller andra scanners du redan kör.
Steg 10: fråga det publika BigQuery-datasetet
Du behöver inte skanna varje beroende själv. OpenSSF kör en veckovis batch-skanning av de en miljon mest kritiska open source-projekten och publicerar allt i ett öppet BigQuery-dataset, openssf:scorecardcron.scorecard-v2, med en separat vy för de senaste resultaten, openssf:scorecardcron.scorecard-v2_latest. CISA bekräftar samma sak i sin egen beskrivning av verktyget: resultaten görs tillgängliga publikt som ett Google Cloud BigQuery-dataset.
Det gör det möjligt att slå upp poängen för ett beroende utan att köra en egen skanning, vilket sparar tid när du behöver granska tiotals eller hundratals paket på en gång.
SELECT repo.name, score, date
FROM `openssf.scorecardcron.scorecard-v2_latest`
WHERE repo.name LIKE '%trivy%'
ORDER BY date DESC
LIMIT 5;Byt ut sökordet mot namnet på beroendet du vill kontrollera. Får du inga träffar betyder det oftast att projektet ligger utanför de en miljon mest beroende-tunga paketen och behöver skannas manuellt med kommandot från steg 5.
Den här genvägen är särskilt användbar när du gör en engångsgranskning av ett helt beroendeträd, till exempel innan en större release eller vid en säkerhetsrevision. Istället för att köra scorecard hundratals gånger i följd, med risk för att stöta i GitHubs hastighetsgränser även med token, kan du exportera hela din package-lock.json eller go.sum, matcha paketnamnen mot BigQuery-tabellen i en enda fråga, och få tillbaka en färdig lista sorterad efter lägst poäng. De beroenden som saknar träff i datasetet är per definition mindre använda i det bredare ekosystemet, en detalj som kan vara relevant men inte i sig en varningsflagga.
Steg 11 och 12: bygg en policy-grind som blockerar riskabla beroenden
Steg 11: Sätt ett tröskelvärde. Ett Scorecard-resultat är bara användbart om det faktiskt påverkar vad som får byggas och deployas. Bestäm ett minimivärde för aggregatpoängen, till exempel 5 av 10, under vilket bygget ska stoppas. Var extra sträng på kritiska kontroller som Dangerous-Workflow och Webhooks, oavsett vad totalpoängen visar. Ett vanligt misstag är att sätta ett enda globalt tröskelvärde för hela organisationen. Ett betalningssystem eller en autentiseringstjänst förtjänar en strängare gräns än ett internt admin-verktyg som bara nås från kontorsnätverket, eftersom konsekvenserna av ett lyckat intrång skiljer sig kraftigt åt.
Steg 12: Implementera grinden i pipelinen. Nedan är ett enkelt bash-skript som läser Scorecards JSON-utdata och avbryter bygget om poängen understiger tröskeln.
#!/bin/bash
set -euo pipefail
TROSKEL=5.0
REPO="$1"
RESULTAT=$(scorecard --repo="$REPO" --format=json)
POANG=$(echo "$RESULTAT" | jq '.score')
if (( $(echo "$POANG < $TROSKEL" | bc -l) )); then
echo "STOPP: $REPO fick $POANG av 10, under troskeln $TROSKEL"
exit 1
fi
echo "GODKANT: $REPO fick $POANG av 10"Lägg skriptet som ett steg innan deploy-jobbet i din pipeline. Kombinera gärna gränsen med undantagslistor för väletablerade projekt som av historiska skäl har lägre poäng på enstaka kontroller men i övrigt är pålitliga. En hård gräns utan undantag riskerar annars att blockera legitima, välkända beroenden i onödan.
Dokumentera varje undantag med en kort motivering och ett datum för nästa omprövning. Ett undantag som läggs till i all hast under en pressad release-deadline har en tendens att bli permanent om ingen äger uppgiften att gå tillbaka och kontrollera om skälet fortfarande gäller sex månader senare.
Steg 13: kombinera Scorecard med SBOM och Cosign-signering
Scorecard är starkast tillsammans med andra kontroller i leveranskedjan, inte som ensam vaktpost. Bygg en fullständig SBOM enligt principerna i vår SBOM-guide så vet du exakt vilka transitiva beroenden som ärver riskerna från ett lågt Scorecard-betyg. Signera sedan dina egna byggartefakter med Cosign enligt stegen i vår Cosign-guide, så att nästa länk i kedjan kan verifiera att just din pipeline, och ingen annan, producerade artefakten.
Tillsammans bildar de tre verktygen ett triangelskydd: Scorecard granskar processen bakom ett beroende, SBOM ger dig fullständig insyn i vad som faktiskt ingår, och Cosign garanterar att det du bygger inte har manipulerats efter att det lämnat din pipeline. Ingen av delarna ersätter sårbarhetsskanning av kända CVE:er, de kompletterar den.
Ordningen spelar roll om du bygger upp allt från grunden. Börja med SBOM, eftersom du inte kan granska eller signera det du inte vet att du har. Lägg sedan till Scorecard-skanning av de beroenden SBOM:en avslöjar, för att prioritera vilka som faktiskt behöver en närmare titt. Avsluta med Cosign-signering av era egna byggartefakter, så att nästa steg i kedjan, oavsett om det är en kollega eller en kund, kan lita på att det som levereras faktiskt kommer från er pipeline och inget annat håll.
Håll koll på förändringar i poängen över tid
Ett engångsresultat säger mindre än en trend. Ett projekt som tappar tre poäng på Maintained över några månader signalerar ofta att en underhållare har slutat, vilket är precis den typen av tyst risk som är lätt att missa om du bara tittar på en enda skanning. Eftersom det publika BigQuery-datasetet uppdateras varje vecka kan du bygga en enkel historik genom att spara resultatet från varje körning i din egen pipeline, istället för att bara logga det senaste värdet.
scorecard --repo=github.com/dittkonto/ditt-beroende --format=json \
>> historik/$(date +%Y-%m).jsonlMed några månaders historik i en enkel JSON-loggfil kan du plotta trenden i valfritt verktyg, eller helt enkelt skriva ett litet skript som varnar om aggregatpoängen för ett kritiskt beroende sjunker mer än en poäng mellan två på varandra följande körningar. Det fångar upp gradvisa försämringar långt innan de blir akuta, och det ger säkerhetsteamet ett konkret underlag när frågan kommer upp om varför ett visst beroende plötsligt flaggas i en granskning. Kombinerat med larmen från er befintliga CISA KEV-patchhantering byggs en betydligt mer heltäckande bild av var de verkliga riskerna i kodbasen ligger, snarare än att förlita sig på en enda ögonblicksbild.
Vanliga fallgropar när du inför OpenSSF Scorecard
De flesta problem som uppstår när team börjar använda Scorecard handlar inte om verktyget i sig, utan om hur resultaten tolkas och rullas ut i organisationen. Här är de sex fallgropar vi ser oftast, i ungefärlig ordning efter hur vanliga de är.
- Att sätta tröskeln för hårt från start. Många väletablerade projekt, inklusive stora ramverk, landar under 6 av 10 på grund av enstaka kontroller som Fuzzing. Börja med att logga poängen utan att blockera bygget, och skärp reglerna gradvis.
- Att glömma bort GITHUB_AUTH_TOKEN. Utan token begränsar GitHubs API antalet anrop kraftigt, vilket gör att skanningar av stora beroendeträd misslyckas eller tar orimligt lång tid.
- Att blanda ihop kod-sårbarheter med processrisk. Ett högt Scorecard-betyg garanterar inte frånvaro av kända CVE:er. Kombinera alltid med en riktig sårbarhetsskanner.
- Att bara skanna direkta beroenden. De flesta allvarliga incidenter, inklusive Trivy-kompromissen i mars 2026, sprids via transitiva beroenden flera led ner. Granska hela trädet, inte bara toppnivån, annars missar du precis den typen av spridning som gjorde att över 50 npm-paket drogs in i TeamPCP-kampanjen efter det inledande intrånget i Trivy.
- Att ge
id-token: writetill fel jobb. Behörigheten behövs bara i jobbet som faktiskt publicerar resultat, inte i hela workflowet. Onödigt breda tokens är i sig en risk som Scorecards egen Token-Permissions-kontroll varnar för. - Att inte uppdatera Scorecard-versionen. Nya kontroller och förbättrad logik för Branch-Protection och Dangerous-Workflow tillkom i version 5.5.0. En gammal binär kan missa sådant helt.
Felsökning: vanliga fel och hur du löser dem
De flesta fel du stöter på handlar om autentisering, versionsskillnader eller behörigheter, snarare än buggar i själva verktyget. Nedan är de nio problem vi oftast ser rapporteras i team som just börjat rulla ut Scorecard i sin pipeline.
| Problem | Trolig orsak | Lösning |
|---|---|---|
| "rate limit exceeded" vid körning | GITHUB_AUTH_TOKEN saknas eller är felaktigt satt | Kontrollera med echo $GITHUB_AUTH_TOKEN och exportera på nytt i samma skal |
Kommandot scorecard hittas inte | Binären ligger inte i PATH | Lägg till GOPATH/bin i PATH eller kör via Docker istället |
| Skanningen hänger sig på stora repon | Många kontroller kräver flera API-anrop per fil | Begränsa med --checks till de kontroller du faktiskt behöver |
| Alla poäng visar -1 | Repot är privat och tokenet saknar rätt scope | Skapa en token med repo-scope istället för enbart public_repo |
| GitHub Action misslyckas på "id-token" | Permissions-blocket saknar id-token: write | Lägg till behörigheten i jobbets permissions-block, inte bara workflowets |
| SARIF-filen laddas inte upp till Security-fliken | Repot är privat utan GitHub Advanced Security | Publicera resultatet som artefakt istället, eller aktivera Advanced Security |
| BigQuery-frågan returnerar inga rader | Projektet ingår inte i den veckovisa skanningen av en miljon repon | Kör en egen lokal skanning med kommandot från steg 5 |
| Docker-kommandot ger "permission denied" | Användaren saknar rättighet att köra Docker utan sudo | Lägg till din användare i gruppen docker och logga in på nytt |
| Poängen skiljer sig mellan lokal körning och CI | Olika Scorecard-versioner eller olika omfattning på token-behörigheter | Pinna exakt samma version i båda miljöerna, till exempel v5.5.0 |
Avancerade tips för team och CI/CD i stor skala
När du väl har grunderna på plats finns det flera sätt att skala upp användningen utan att det blir en flaskhals för utvecklingsteamen. För det första: kör inte Scorecard mot varje beroende varje gång ett bygge triggas. Cacha resultat lokalt i minst 24 timmar, eftersom de flesta projekt inte ändrar sin säkerhetsprofil dagligen, och luta dig istället mot det publika BigQuery-datasetet för beroenden som redan täcks där. Det sparar både byggtid och API-anrop, samtidigt som du fortfarande fångar upp verkliga förändringar inom rimlig tid.
För det andra: differentiera tröskelvärden efter riskexponering. Ett internt verktyg som bara körs i en isolerad testmiljö tål ett lägre betyg än ett paket som hamnar direkt i en produktionsbyggd container. För det tredje: koppla ihop Scorecard-larm med samma process du redan använder för CVE-bevakning, så hamnar processrisker och kända sårbarheter i samma triageflöde istället för i separata system som ingen har helhetsbild över.
Slutligen: dela dina egna Scorecard-resultat öppet. Ett projekt som publicerar sin poäng, och aktivt jobbar för att höja den, signalerar till hela ekosystemet att det tar leveranskedjesäkerhet på allvar. Det är samma logik som ligger bakom SLSA-nivåer och signerade releaser, öppenhet gör det svårare för en attack som TeamPCP-kampanjen att gå obemärkt förbi i flera dagar innan den upptäcks.
Ett femte tips gäller stora organisationer med hundratals repon: bygg en central instrumentpanel som drar data direkt från BigQuery-datasetet istället för att låta varje team köra egna, isolerade skanningar. Det ger säkerhetsteamet en samlad bild av var i organisationen riskerna faktiskt ligger, utan att belasta varje enskilt utvecklarteam med ansvaret att tolka rådata på egen hand. Kombinera gärna instrumentpanelen med samma triagerutin ni redan har för incidenthantering, så att ett kraftigt sjunkande Scorecard-betyg på ett kritiskt beroende utlöser samma process som ett nytt CVE-larm.
Komplett projekt: färdig pipeline att kopiera
Sätt ihop allt från guiden i en enda mapp så har du ett färdigt, körbart exempel att utgå från i ett riktigt projekt.
mitt-projekt/
├── .github/
│ └── workflows/
│ └── scorecard.yml # Steg 8-9: automatisk veckovis skanning
├── scripts/
│ └── policy-gate.sh # Steg 11-12: blockerar bygget under tröskeln
├── sbom.json # Genereras enligt SBOM-guiden
└── cosign.pub # Publik nyckel för att verifiera signerade byggenKör ./scripts/policy-gate.sh github.com/dittkonto/dittprojekt lokalt innan varje release, låt GitHub Actions-workflowet sköta den kontinuerliga övervakningen, och luta dig mot BigQuery-datasetet när du snabbt vill kontrollera ett nytt beroende innan du lägger till det i package.json eller go.mod. Bygg gradvis ut mappen med SBOM- och Cosign-stegen när grunden känns stabil.
En rimlig utrullningsordning för ett team som börjar från noll är att först lägga till workflowet i observationsläge, utan att blockera några byggen, under två till tre veckor. Under den perioden samlar ni statistik på var era befintliga beroenden faktiskt ligger poängmässigt, vilket ger ett underlag för var tröskelvärdet i policy-gate.sh bör sättas. Först därefter aktiverar ni grinden på riktigt, med undantagslistan redan ifylld för de beroenden som av goda skäl ligger under tröskeln men som teamet ändå valt att lita på. Den ordningen minskar risken att en alltför sträng grind stoppar en release i onödan samma dag den införs.
Vanliga frågor om OpenSSF Scorecard
Är OpenSSF Scorecard gratis att använda?
Ja. Scorecard är ett öppet källkodsprojekt under Open Source Security Foundation, och både verktyget och det publika BigQuery-datasetet med resultat för en miljon projekt är kostnadsfria att använda.
Fungerar Scorecard mot privata repon?
Ja, men du behöver en Personal Access Token med bredare behörighet (scope repo istället för public_repo), och resultaten publiceras inte automatiskt till det publika datasetet.
Fungerar Scorecard med GitLab och andra plattformar än GitHub?
Verktygets huvudsakliga stöd och de flesta kontroller är byggda kring GitHubs API. Vissa grundläggande kontroller fungerar mot andra plattformar, men täckningen är betydligt smalare än för GitHub-repon. Om huvuddelen av era beroenden hostas på GitHub, vilket gäller de allra flesta stora open source-projekt, påverkar den begränsningen i praktiken sällan resultatet av en genomsnittlig leveranskedjegranskning.
Hur ofta bör jag köra en skanning?
En schemalagd veckovis körning i CI, som i exemplet i steg 8, räcker för de flesta team. Kritiska beroenden i produktionskritiska system kan med fördel skannas oftare, till exempel vid varje deploy.
Skulle Scorecard ha upptäckt Trivy-kompromissen i mars 2026 i förväg?
Inte med säkerhet. Scorecard mäter processrisk, som svaga branch-skydd eller saknad kodgranskning, snarare än att upptäcka en pågående attack i realtid. Ett lågt betyg på Branch-Protection eller Code-Review hade dock varit en tidig varningssignal om just de kontrollerna varit svaga innan angreppet.
Vad är skillnaden mellan Scorecard och en vanlig sårbarhetsskanner?
En sårbarhetsskanner som Trivy eller OSV-Scanner letar efter kända CVE:er i din kod eller dina beroenden just nu. Scorecard granskar istället de utvecklingsvanor, som kodgranskning, signering och branch-skydd, som avgör hur sannolikt det är att framtida sårbarheter upptäcks och åtgärdas snabbt.
Kan jag lita blint på ett högt aggregatbetyg?
Nej. Ett högt snittbetyg kan dölja en enskild kritisk brist om den kontrollen väger lätt i totalen. Titta alltid på enskilda kontroller, särskilt Dangerous-Workflow, Webhooks och Vulnerabilities, snarare än enbart aggregatpoängen.
Kostar det något att köra Scorecard mot väldigt många repon i CI?
Verktyget i sig är gratis, men GitHubs API har hastighetsgränser även med en autentiserad token. Kör du skanningar mot hundratals repon dagligen bör du i första hand luta dig mot det publika BigQuery-datasetet, som redan täcker en miljon projekt, och spara egna live-skanningar för interna repon och beroenden som inte finns i datasetet.
