docs: improve swedish translation of concise guide

Co-authored-by: Thomas Nyman <[email protected]>
Signed-off-by: Josef Andersson <[email protected]>

Author: janderssonse

docs/sv/Concise-Guide-for-Evaluating-Open-Source-Software.md

@@ -8,8 +8,8 @@ Innan du använder beroenden eller verktyg som är öppen källkod, bör du, som
 
 | Regel | Beskrivning | Genomfört |
 |------|-------------|:--------:|
-| **Överväg behov** | Utvärdera om beroendet kan undvikas genom att använda befintliga komponenter. Varje nytt beroende ökar attackytan (en förvanskning av det nya beroendet, eller dess transitiva beroenden, kan förvanska systemet). |   |
-| **Verifiera äkthet** | Verifiera att programvaran som utvärderas är den autentiska versionen från den auktoriserade källan, inte en personlig eller angriparkontrollerad gren (fork). Detta för att motverka den vanliga "typosquatting"-attacken (där en angripare skapar ett "nästan korrekt" namn). Kontrollera beroendets namn och länken för projektets webbplats. Verifiera fork-förhållandet på GitHub/GitLab. Kontrollera om projektet är knutet till en stiftelse. Kontrollera projektets skapelsetid och popularitet. |   |
+| **Överväg behov** | Utvärdera om beroendet kan undvikas genom att använda befintliga komponenter. Varje nytt beroende ökar attackytan (ett skadligt nytt beroendet, eller skadliga transitiva beroenden, kan skada systemets säkerhet). |   |
+| **Verifiera äkthet** | Verifiera att programvaran som utvärderas är en äkta version från en trovärdig källa, inte en personlig eller angriparkontrollerad gren (fork). Detta motverkar vanliga "typosquatting" attacker (där en angripare skapar skadliga versioner av vanliga beroenden med "nästan korrekta" namn). Kontrollera beroendets namn och länken för projektets webbplats. Verifiera fork-förhållandet på GitHub/GitLab. Kontrollera om projektet är knutet till en stiftelse. Kontrollera när projektet skapats och dess popularitet. |   |
 
 ## Underhåll och hållbarhet
 
@@ -31,19 +31,19 @@ Innan du använder beroenden eller verktyg som är öppen källkod, bör du, som
 | **Certifiering av bästa praxis** | Avgör om projektet har förtjänat (eller är på god väg till) ett [Open Source Security Foundation (OpenSSF) Best Practices-märke](https://www.bestpractices.dev/). |   |
 | **Hantering av beroenden** | Verifiera att projektets paketberoenden är (relativt) uppdaterade. |   |
 | **Kodförrådsäkerhet** | Bekräfta att utvecklarna använder säkerhetsfunktioner i kodsamverkansplattformen där tillämpligt (t.ex. om de använder GitHub eller GitLab, använder de grenskydd(branch-protection)). |   |
-| **Säkerhetsrevisioner** | Identifiera befintliga säkerhetsrevisioner och verifiera att identifierade sårbarheter har åtgärdats. Säkerhetsrevisioner är relativt ovanliga, se exempelvis OpenSSF:s "[Säkerhetsgranskningar](https://github.com/ossf/security-reviews)". |   |
+| **Säkerhetsgranskninar** | Identifiera om programvaran säkerhetsgranskats och verifiera att upptäckta sårbarheter har åtgärdats. Säkerhetsgranskningar är relativt ovanliga, se exempelvis OpenSSF:s "[Security reviews](https://github.com/ossf/security-reviews)". |   |
 | **Säker utveckling** | Bekräfta att projektet tillämpar bästa praxis för säker programvaruutveckling enligt [Concise Guide for Developing More Secure Software](https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software) eller [OpenSSF Open Source Security Baseline](https://baseline.openssf.org/). |   |
 | **Säkerhetsdokumentation** | Verifiera att det finns dokumentation som förklarar varför projektet är säkert (även kallat "assurans"). |   |
 | **Säkerhetsrespons** | Bedöm om projektet åtgärdar fel (särskilt säkerhetsfel) i tid, om de släpper säkerhetsuppdateringar för äldre utgåvor, och om de har en LTS-version (Long Term Support). |   |
 | **Säkerhetspoäng** | Granska information på [https://deps.dev](https://deps.dev/), inklusive dess [OpenSSF Scorecards](https://github.com/ossf/scorecard)-poäng och eventuella kända sårbarheter. |   |
 | **Testpraxis** | Utvärdera om det finns automatiserade tester i dess CI-pipeline och vad projektets testtäckning är. |   |
-| **Sårbarhetsstatus** | Bekräfta om den aktuella versionen är fri från kända viktiga sårbarheter (särskilt äldre). Organisationer kan vilja implementera [OpenChain](https://www.openchainproject.org/) [Security Assurance Specification 1.1](https://github.com/OpenChain-Project/Security-Assurance-Specification/tree/main/Security-Assurance-Specification/1.1/en) för att systematiskt kontrollera kända sårbarheter vid införande och när nya sårbarheter avslöjas offentligt. |   |
+| **Sårbarhetsstatus** | Bekräfta om den aktuella versionen är fri från kända viktiga sårbarheter (särskilt äldre). Organisationer kan överväga att implementera [OpenChain](https://www.openchainproject.org/) [Security Assurance Specification 1.1](https://github.com/OpenChain-Project/Security-Assurance-Specification/tree/main/Security-Assurance-Specification/1.1/en) för att systematiskt kontrollera kända sårbarheter vid införande och när nya sårbarheter avslöjas offentligt. |   |
 
 ## Användbarhet och säkerhet
 
 | Regel | Beskrivning | Genomfört |
 |------|-------------|:--------:|
-| **Gränssnittsdesign** | Verifiera att gränssnittet/API:et är designat för enkel användning på ett säkert sätt (t.ex. om gränssnittet implementerar ett språk, stöder det parametriserade frågor). |   |
+| **Gränssnittsdesign** | Verifiera att gränssnittet/API:et är designat för enkel användning på ett säkert sätt.  Exempelvis om gränssnittet implementerar ett programmeringsspråk som SQL, stöder det parameterfrågor (eng. *structured queries*). |   |
 | **Gränssnittsstabilitet** | Verifiera att gränssnittet/API:et är stabilt eller att projektet har en policy för att undvika och/eller hantera ändringar av gränssnitt/API:er som bryter kompatibilitet. Ett instabilt API är ett betydande hinder för att uppgradera till nyare versioner (t.ex. för att åtgärda sårbarheter). |   |
 | **Säkra standardinställningar** | Bekräfta att standardkonfigurationen och "enkla exempel" är säkra (t.ex. kryptering påslagen som standard i nätverksprotokoll). Om inte, undvik det. |   |
 | **Säkerhetsvägledning** | Verifiera om det finns vägledning om hur man använder det säkert. |   |
@@ -69,14 +69,14 @@ Licensramverk har en betydande påverkan på säkerhets- och hållbarhetsställn
 
 ## Kodutvärdering
 
-Även en snabb granskning av programvaran (av dig, anställd eller annan), tillsammans med senaste ändringarna, kan ge dig insikt. Överväg:
+Även en snabb granskning av programvaran (av dig, en anställd eller någon annan), tillsammans med senaste ändringarna, kan ge dig insikt. Överväg:
 
 | Regel | Beskrivning | Genomfört |
 |------|-------------|:--------:|
-| **Kodfullständighet** | Utvärdera om det finns bevis på osäker/ofullständig programvara (t.ex. många TODO-uttalanden). |   |
-| **Kontroll av skadlig kod** | Analysera om det finns bevis på att programvaran är skadlig. Enligt [*Backstabber's Knife Collection*](https://arxiv.org/abs/2005.09535), kontrollera installationsskript/rutiner för skadlighet, kontrollera dataexfiltrering från **~/.ssh** och miljövariabler, och leta efter kodade/fördolda värden som exekveras. Undersök de senaste commit:sen för misstänkt kod (en angripare kan ha lagt till dem nyligen). |   |
-| **Sandlådetestning** | Överväg att köra programvaran i en sandlåda(sandbox) för att försöka utlösa och upptäcka skadlig kod. |   |
-| **Säkerhetsimplementationer** | När du granskar källkoden, finns det bevis i koden på att utvecklarna försökt att utveckla säker programvara (som rigorös indata validering av opålitliga indata samt användning av parametriserade frågor)? |   |
+| **Kodfullständighet** | Utvärdera om det finns bevis på osäker/ofullständig programvara (t.ex. många TODO-kommentarer). |   |
+| **Kontroll av skadlig kod** | Analysera om det finns bevis på att programvaran är skadlig. Enligt [*Backstabber's Knife Collection*](https://arxiv.org/abs/2005.09535) bör installationsskript/rutiner granskas för skadlig kod, kontrollera dataexfiltrering från **~/.ssh** och miljövariabler, och leta efter kodade/fördolda värden som kan exekveras. Undersök de senaste committerna för misstänkt kod (en angripare kan ha lagt till dem nyligen). |   |
+| **Sandlådetestning** | Överväg att köra programvaran i en sandlåda (eng. *sandbox*) för att försöka utlösa och upptäcka skadlig kod. |   |
+| **Säkerhetsimplementationer** | När du granskar källkoden, finns det bevis i koden på att utvecklarna försökt att utveckla säker programvara (som rigorös inmatningsvalidering av utomstående data som inte är betrodd samt användning av parameterfrågor)? |   |
 | **Säkerhetsgranskningar** | Se [OpenSSF:s lista över säkerhetsgranskningar](https://github.com/ossf/security-reviews/blob/main/Overview.md#readme). |   |
 | **Statisk analys** | Vilka är de "främsta" problemen som en statisk kodanalys rapporterar? |   |
 | **Testvalidering** | Överväg att köra alla definierade testfall för att säkerställa att programvaran klarar dem. |   |