Iedereen die dacht dat computerbeveiligingsproblemen een of ander abstract probleem waren dat weinig met hun dagelijks leven te maken had, werd onlangs ruw wakker geschud. Bij de ransomwareaanval van de Colonial Pipeline werden gas- en olieleveringen in het zuidoosten stilgelegd. Cybersecurity-fouten waren al een groot probleem geworden met de supply chain-aanval van SolarWinds en de FBI moest ingrijpen om kapotte Microsoft Exchange-servers te repareren . Dus op 12 mei ondertekende president Joe Biden een uitvoerend bevel om de cyberdefensie van de federale overheid te versterken en om heel Amerika te waarschuwen dat technologische beveiliging nu een taak moet zijn. De Linux Foundation en zijn verwante organisaties werken aan betere Linux- en open-sourcebeveiliging.

De uitvoerende macht erkende het vitale belang van open-source software. Het luidt gedeeltelijk: “Binnen 90 dagen na publicatie van de voorlopige richtlijnen… zullen richtlijnen worden uitgegeven om praktijken te identificeren die de veiligheid van de softwaretoevoerketen verbeteren.” Open-source software wordt specifiek genoemd.

De overheid moet “voor zover praktisch uitvoerbaar, de integriteit en herkomst van open-source software die in enig deel van een product wordt gebruikt, waarborgen.” Concreet moet het proberen om een ​​Software Bill of Materials (SBOM) te verstrekken. “Dit is een formeel record met de details en supply chain-relaties van verschillende componenten die worden gebruikt bij het bouwen van software.” Het is een bijzonder belangrijk probleem met open-source software omdat:

Softwareontwikkelaars en -leveranciers maken vaak producten door bestaande open source- en commerciële softwarecomponenten samen te stellen. De SBOM somt deze componenten op in een product. Het is analoog aan een lijst met ingrediënten op voedselverpakkingen. Een SBOM is nuttig voor degenen die software ontwikkelen of vervaardigen, degenen die software selecteren of kopen en degenen die software gebruiken. Ontwikkelaars gebruiken vaak beschikbare open-source softwarecomponenten en softwarecomponenten van derden om een ​​product te maken; Met een SBOM kan de bouwer ervoor zorgen dat die componenten up-to-date zijn en snel reageren op nieuwe kwetsbaarheden. Kopers kunnen een SBOM gebruiken om kwetsbaarheids- of licentieanalyses uit te voeren, die beide kunnen worden gebruikt om risico’s in een product te evalueren. Degenen die software gebruiken, kunnen SBOM’s gebruiken om snel en eenvoudig te bepalen of ze een potentieel risico lopen op een nieuw ontdekte kwetsbaarheid. Een veelgebruikt, machinaal leesbaar SBOM-formaat biedt grotere voordelen door automatisering en toolintegratie. De SBOM’s krijgen meer waarde wanneer ze gezamenlijk worden opgeslagen in een repository die gemakkelijk kan worden opgevraagd door andere applicaties en systemen.

De open-sourcecommunity zelf pakt dit probleem al lang aan. Met name het Software Package Data Exchange (SPDX) -project heeft de afgelopen tien jaar gewerkt om softwaretransparantie en SBOM mogelijk te maken. SPDX bevindt zich in de laatste fase van de beoordeling om de ISO / IEC International Standard 5962 te worden , en wordt ondersteund door wereldwijde bedrijven met enorme toeleveringsketens, en heeft een groot open en gesloten source tooling-ondersteunend ecosysteem.

SPDX 2.2 ondersteunt al de huidige minimum SBOM-elementen van de National Telecommunications and Information Administration (NTIA) . Kortom, als uw open-source software een SPDX SBOM levert, voldoet deze al aan de eisen van de executive order. Zie voor voorbeelden van SPDX:

• Een NTIA “plugfest”  demonstreerde tien verschillende producenten die SPDX genereerden. SPDX ondersteunt het verwerven van gegevens uit verschillende bronnen (bijv. Broncode-analyse, uitvoerbare bestanden van producenten en analyse van derden).
• Er is een corpus van enkele LF-projecten met SPDX-bron-SBOM’s beschikbaar.
• Verschillende LF-projecten werken aan het genereren van binaire SBOM’s als onderdeel van hun builds, waaronder Yocto en Zephyr .
• Om te helpen bij verdere SPDX-acceptatie, betaalt de Linux Foundation om SPDX-plug-ins te schrijven voor grote pakketbeheerders.

Natuurlijk ondersteunen veel programma’s SPDX nog niet. Het is de enige manier om er zeker van te zijn dat u weet wat er werkelijk in uw open-sourceprogramma’s staat, en dat is een kwestie van nationaal belang geworden.
Dit is natuurlijk niet alleen een probleem met open-source software. Met open-source software kun je de code daadwerkelijk zien, zodat het gemakkelijker is om een ​​SBOM te maken. Propriëtaire programma’s, zoals de recentelijk massaal uitgebuite Microsoft Exchange-ramp , zijn zwarte dozen. Er is geen manier om echt te weten wat er in Apple- of Microsoft-software staat.
De grootste ramp met de beveiliging van de toeleveringsketen tot dusver, het catastrofale falen van Solarwinds om de toeleveringsketen van zijn software te beveiligen , was het gevolg van het falen van de eigen softwareketen.

Naast SPDX heeft de Linux Foundation onlangs een nieuwe open-source software-ondertekeningsservice aangekondigd: het sigstore-project . Sigstore probeert de beveiliging van de toeleveringsketen van software te verbeteren door de eenvoudige acceptatie van cryptografische software-ondertekening mogelijk te maken, ondersteund door transparantielogboektechnologieën. Ontwikkelaars zijn gemachtigd om software-artefacten, zoals releasebestanden, containerafbeeldingen en binaire bestanden, veilig te ondertekenen. Deze ondertekeningsrecords worden vervolgens bewaard in een fraudebestendig openbaar logboek. Deze service is gratis voor alle ontwikkelaars en softwareleveranciers. De sigstore-code en bewerkingshulpmiddelen die dit zullen laten werken, zijn nog in ontwikkeling.

Vóór sigstore hebben het eerdere Core Infrastructure Initiative (CII) van de Linux Foundation en de huidige Open Source Security Foundation (OpenSSF) gewerkt aan het beveiligen van open-source software, zowel in het algemeen als in de componenten ervan. De OpenSSF in het bijzonder is een brede industriecoalitie “die samenwerkt om het open-sourceecosysteem veilig te stellen”.

Om de integriteit van toeleveringsketens verder te waarborgen, eist het uitvoerend bevel dat agentschappen “geautomatiseerde tools of vergelijkbare processen gebruiken om betrouwbare toeleveringsketens voor broncode te onderhouden, waardoor de integriteit van de code” wordt gegarandeerd. Naast sigstore houdt de Linux Foundation toezicht op meerdere projecten om hierbij te helpen.

Het LF heeft veel projecten die SC-integriteit ondersteunen, met name:

• in-toto is een raamwerk dat specifiek is ontworpen om de integriteit van softwareleveringsketens te waarborgen.
• Het Update Framework (TUF) helpt ontwikkelaars de beveiliging van software-updatesystemen te handhaven en wordt in de productie gebruikt door verschillende technologiebedrijven en open source-organisaties.
• Uptane is een variant van TUF; het is een open en veilig ontwerp van het software-updatesysteem dat software beschermt die via de ether aan de geautomatiseerde eenheden van auto’s wordt geleverd.
• OpenChain (ISO 5230) is de internationale norm voor naleving van open source licenties. Toepassing van OpenChain vereist identificatie van OSS-componenten. Hoewel OpenChain op zichzelf meer focust op licenties, kan die identificatie gemakkelijk worden hergebruikt om andere aspecten van die componenten te analyseren zodra ze zijn geïdentificeerd (bijvoorbeeld om te zoeken naar bekende kwetsbaarheden).

De executive order vraagt ​​ook:

De minister van Handel [handelend via NIST] zal input vragen van de federale overheid, de particuliere sector, de academische wereld en andere geschikte actoren om bestaande of nieuwe normen, tools en best practices te identificeren of te ontwikkelen voor het voldoen aan de normen, procedures of criteria [ inclusief] criteria die kunnen worden gebruikt om softwarebeveiliging te evalueren, criteria op te nemen om de beveiligingspraktijken van de ontwikkelaars en leveranciers zelf te evalueren, en innovatieve tools of methoden te identificeren om conformiteit aan te tonen met veilige praktijken [en richtlijnen] voor het verbeteren van de beveiliging van de softwareleveringsketen.

Om dit aan te pakken, identificeert het CII Best Practices-badgeproject van OpenSSF specifiek best practices voor open-source software. Dit richt zich op beveiliging. Het bevat criteria om de beveiligingspraktijken van ontwikkelaars en leveranciers te evalueren. Tegenwoordig heeft het meer dan 3.800 deelnemende projecten. De Linux Foundation werkt ook samen met Supply-chain Levels for Software Artifacts (SLSA) om problemen met de toeleveringsketen verder op te lossen.

De Executive Order vereist ook dat agentschappen “versleuteling voor gegevens in rust en tijdens verzending” toepassen. Versleuteling tijdens verzending is al geïmplementeerd op internet met behulp van het Transport Layer Security (TLS) -protocol. Het open Let’s Encrypt- project van de Internet Security Research Group (ISRG) is ‘ s werelds grootste certificeringsinstantie voor TLS-certificaten .

Daarnaast is het LF Confidential Computing Consortium toegewijd aan het definiëren en versnellen van de acceptatie van vertrouwelijk computergebruik. Vertrouwelijk computergebruik beschermt gegevens die in gebruik, in rust en onderweg zijn door ze te testen in een op hardware gebaseerde Trusted Execution Environment. Deze veilige en geïsoleerde omgevingen voorkomen ongeautoriseerde toegang tot of wijziging van applicaties en gegevens.

Natuurlijk zullen er altijd bugs zijn. Om hieraan tegemoet te komen, moeten de criteria voor het voldoen aan de  CII Best Practices-badge dat OSS-projecten specifiek aangeven hoe kwetsbaarheden aan hen kunnen worden gemeld. Meer in het algemeen werkt de OpenSSF Vulnerability Disclosures Working Group eraan om “goed beheerde kwetsbaarheidsrapportage en communicatie” voor OSS te helpen “volwassen worden en bepleiten”.

Biden’s executieve bevel riep iedereen ook op om zich te concentreren op ‘kritieke software’. De Linux Foundation doet dit al een tijdje. De Linux Foundation en het Laboratory for Innovation Science aan Harvard (LISH) hebben onlangs de Vulnerabilities in the Core, een voorlopig rapport en Census II van open source-software vrijgegeven . Deze analyseerde, zoals de naam al zegt, kritische en kwetsbare open-source software. Dit rapport wordt bijgewerkt.

De CII identificeerde ook veel belangrijke projecten en hielp ze om veiliger te worden. Deze omvatten kleine maar vitale projecten – ook bekend als het allerbelangrijkste programma dat wordt ondersteund door één persoon die werkt vanuit hun boerderij in Nebraska, inclusief OpenSSL (naar Heartbleed), OpenSSH, GnuPG, Frama-C en de OWASP Zed Attack Proxy (ZAP). De OpenSSF-werkgroep voor het beveiligen van kritieke projecten heeft gewerkt om kritieke OSS-projecten beter te identificeren en middelen te richten op kritieke OSS-projecten die hulp nodig hebben. Er is al een eerste lijst van dergelijke projecten, samen met inspanningen om dergelijke hulp te financieren.

Denkend aan beveiligingsgrappen, erkent de uitvoerende macht dat de meeste beveiligingsfouten van het Internet of Things (IoT) nooit worden opgelost. Zoals de grap luidt: “S in IoT is voor beveiliging.” De verantwoordelijkheid daarvoor ligt bij IoT-leveranciers die soms niet eens opties bieden om hun software bij te werken, laat staan ​​dat ze daadwerkelijk beveiligingspatches uitgeven. Hoewel de Linux Foundation dat niet kan, kunnen Linux Foundation-leden wel veilige software en besturingssystemen leveren. Waaronder:

• De Linux-kernel zelf, die door veel IoT-apparaten wordt gebruikt.
• Het Yocto-project , dat op Linux gebaseerde systemen op maat maakt voor IoT en embedded systemen. Yocto ondersteunt volledig reproduceerbare builds.
• EdgeX Foundry , een flexibel open-source softwareframework dat de interoperabiliteit tussen apparaten en applicaties aan de IoT-edge mogelijk maakt, en dat miljoenen keren is gedownload.
• Het Zephyr-project , dat een realtime besturingssysteem (RTOS) biedt dat door velen wordt gebruikt voor IoT-apparaten met beperkte middelen en dat in staat is om automatisch SBOM’s te genereren tijdens het bouwen. Zephyr is een van de weinige open-sourceprojecten die een CVE Numbering Authority is.
• De seL4-microkernel , de meest betrouwbare kernel van het besturingssysteem ter wereld; het valt op door zijn uitgebreide formele verificatie.

Alles bij elkaar, en de Linux- en open-sourcecommunity zijn al goed op weg om aan de eisen van deze nieuwe beveiligingsopdracht te voldoen. Er moet nog veel meer worden gedaan, maar het kader is in ieder geval aanwezig.

Dit is essentieel werk. De Linux Foundation zou uw hulp hierbij op prijs stellen. Zoals David A. Wheeler, de directeur van Open Source Supply Chain Security van de Linux Foundation, zei: “We zouden dit niet kunnen doen zonder de vele bijdragen van tijd, geld en andere middelen van talloze bedrijven en individuen; we zijn ze allemaal dankbaar. We werken altijd graag met iedereen samen om de ontwikkeling en implementatie van open-source software te verbeteren. ”

Zoals de gebeurtenissen van de afgelopen maanden hebben aangetoond – inderdaad de afgelopen uren met de ransomwareaanval op het Ierse gezondheidssysteem – moet veiligheid niet alleen voor de federale overheid maar voor iedereen taak nummer één worden.