Open source-sikkerhed: Google har en ny plan for at stoppe angreb på softwareforsyningskæden

0
125

 Liam Tung

Af Liam Tung | 17. juni 2021 – 09:49 GMT (10:49 BST) | Emne: Sikkerhed

For at tackle den voksende trussel om angreb på softwareforsyningskæden har Google foreslået Supply chain Levels for Software Artifacts-rammen eller SLSA, der udtages som “salsa”.

Sofistikerede angribere har fundet ud af, at softwareforsyningskæden er soft soft-industriens bløde underliv. Ud over det spilskiftende SolarWinds-hack peger Google på det nylige Codecov-forsyningskædeangreb, som stak cybersikkerhedsfirmaet Rapid7 via en plettet Bash-uploader.

Mens angreb på forsyningskæden ikke er nyt, bemærker Google, at de er eskaleret i det forløbne år og har skiftet fokus fra udnyttelse af kendte eller nul-dages softwareproblemer.

SE: Netværkssikkerhedspolitik (TechRepublic Premium)

Google beskriver SLSA som “en ende-til-ende-ramme for at sikre integriteten af ​​softwareartifakter i hele softwareforsyningskæden. “

Det tager sin føring fra Googles interne “Binary Authorization for Borg” (BAB) – en proces, som Google har brugt i mere end otte år til at kontrollere kodens herkomst og implementere kodeidentitet.

Målet med BAB er at reducere insiderrisikoen ved at sikre, at produktionssoftware, der er implementeret hos Google, gennemgås korrekt, især hvis koden har adgang til brugerdata, bemærker Google i en hvidbog.

“Målet med SLSA er at forbedre branchens tilstand, især open source, for at forsvare sig mod de mest presserende integritetstrusler. Med SLSA kan forbrugerne træffe informerede valg om sikkerhedsstillingerne for den software, de bruger,” sagde Kim Lewandowski fra Googles open source-sikkerhedsteam og Mark Lodato fra BAB-teamet.

SLSA ser ud til at låse alt i softwarebygningskæden, fra udvikleren til kildekoden, byggeplatformen og CI/CD-systemerne, pakkeopbevaringsstedet og afhængigheder.

Afhængigheder er et stort svagt punkt for open source-softwareprojekter. I februar foreslog Google nye protokoller til kritisk open source-softwareudvikling, der ville kræve kodevurderinger fra to uafhængige parter, og som vedligeholdere bruger tofaktorautentificering.

Det regner med, at de højere SLSA-niveauer ville have bidraget til at forhindre angrebet på SolarWinds 'softwarebygningssystem, som var kompromitteret for at installere et implantat, der injicerede en bagdør under hver nybygning. Det hævder også, at SLSA ville hjælpe i CodeCov-angrebet, fordi “herkomst af artefakten i GCS-skovlen ville have vist, at artefakten ikke blev bygget på den forventede måde fra det forventede kildeanvisning.”

SE: GDPR: Bøder steg med 40% sidste år, og de er ved at blive meget større

Mens SLSA-rammen kun er et sæt retningslinjer for nu, forestiller Google sig at dens endelige form vil gå ud over bedste praksis via håndhævelighed.

“Det understøtter automatisk oprettelse af audible metadata, der kan føres ind i politikmotorer for at give” SLSA-certificering “til en bestemt pakke eller opbygningsplatform,” sagde Google.

Ordningen består af fire niveauer af SLSA, hvor fire er den ideelle tilstand, hvor alle softwareudviklingsprocesser er beskyttet, som vist nedenfor.

screen-shot-2021-06-14-at-10-51-35-am.png

Google

Sikkerhed

De bedste browsere til beskyttelse af personlige oplysninger: Gennemse sikkert på det store dårlige internet Cybersikkerhed 101: Beskyt dit privatliv fra hackere, spioner og regeringen De bedste antivirussoftware og apps De bedste VPN'er til forretnings- og hjemmebrug De bedste sikkerhedsnøgler til tofaktorautentificering Ransomware: Gør disse tre ting for at beskytte dit netværk mod angreb (ZDNet YouTube)

Relaterede emner:

Google Security TV Data Management CXO-datacentre  Liam Tung

Af Liam Tung | 17. juni 2021 – 09:49 GMT (10:49 BST) | Emne: Sikkerhed