Wat is software supply chain-beveiliging?

De software supply chain omvat alles dat een product of applicatie beïnvloedt of een rol speelt tijdens de gehele softwareontwikkelingslevenscyclus (SDLC).

De afgelopen jaren komen aanvallen op de softwaretoeleveringsketen steeds vaker voor en worden ze geavanceerder. In hun rapport uit 2022 Gartner luidt als volgt: “Anticipeer op de voortdurende uitbreiding van het aanvalsoppervlak van ondernemingen en verhoog de investeringen in processen en hulpmiddelen voor detectie en herstel van identiteitsbedreigingen en integriteit van de digitale toeleveringsketen.”

Het is belangrijker dan ooit om alle componenten, activiteiten en SDLC-praktijken die betrokken zijn bij het maken en implementeren van software te beveiligen. Ontwikkelteams en softwareleveranciers moeten ervoor zorgen dat ze alleen codecomponenten gebruiken die vrij zijn van bekende kwetsbaarheden en manieren vinden om de integriteit van hun build te valideren, waarbij wordt gecontroleerd op ongeautoriseerde manipulatie.

Definitie van software supply chain-beveiliging

De software supply chain verwijst naar alles wat betrokken is bij de ontwikkeling van een applicatie gedurende de gehele levenscyclus van softwareontwikkeling (SDLC). Het maken en implementeren van software vereist het beveiligen van de activiteiten, processen en componenten van de toeleveringsketen. Er zijn in dit opzicht veel factoren waarmee rekening moet worden gehouden, waaronder aangepaste code (interne componenten), open source-afhankelijkheden en bibliotheken (componenten van derden), DevOps-tools en -infrastructuur die deel uitmaken van het CI/CD-proces, en ten slotte ontwikkelaars en DevOps ploegen.

Het is de verantwoordelijkheid van organisaties om deze beveiligingsactiviteiten uit te voeren en het bewijs van hun beveiligingsinspanningen aan consumenten te leveren.

 

 

Aanvallen op softwaretoeleveringsketens: waarom komen ze zo vaak voor?

Moderne softwarepijplijnen zijn geautomatiseerde omgevingen die afhankelijk zijn van een verscheidenheid aan tools voor continue integratie en continue levering. Een softwareproject kan uiteindelijk duizenden open source-afhankelijkheden omvatten.

Kwaadwillige actoren kunnen frauduleuze bibliotheken als legitiem laten doorgaan door misbruik te maken van 'logische fouten' in open-source pakketbeheerders. Pakketten met malware kunnen bijvoorbeeld zonder hun medeweten worden toegeschreven aan vertrouwde beheerders. Dergelijk misplaatst vertrouwen kan problematische en verborgen kwetsbaarheden in uw code introduceren. Deze kwetsbaarheden kunnen aanvallers toegang geven tot gevoelige gegevens of hen in staat stellen malware en controlesystemen in de hele toeleveringsketen te plaatsen.

De moderne ontwikkelomgeving heeft zijn eigen kwetsbaarheden, en een verscheidenheid aan aanvallen op de supply chain van software was gericht op de CI/CD-pijplijn om op een bepaald moment tijdens het ontwikkelingsproces kwaadaardige code in te voegen. Ook hier is een nulvertrouwensaanname de adequate aanpak om vertrouwen te winnen in het uiteindelijke softwareproduct: elke stap in de interne ontwikkelingsketen controleren, verifiëren en valideren.
De huidige CI/CD-pijplijnen ontberen zichtbaarheid en controles om het softwareontwikkelingsproces adequaat te beschermen. Ze hebben ook moeite om geknoei met code te detecteren, waardoor deze aanvalsvector nog aantrekkelijker wordt.

De SSDF (NIST 800-218) is afgerond en van kracht

Het SSDF-framework (NIST 800-218). vereist van leveranciers dat ze beveiligingspraktijken implementeren die de Software Development Life Cycle (SDLC) bestrijken. Het bevordert transparantie en fraudebestendige maatregelen in een poging beveiligingsproblemen en kwaadwillige inmenging te verminderen.

Concreet bevat het richtlijnen voor een op bewijs gebaseerde aanpak om de software zelf te beschermen tegen manipulatie.

De SSDF bestaat uit vier hoofdonderdelen:

01 /
Bereid de organisatie voor (PO):

Zorg ervoor dat mensen voorbereid zijn en dat er processen en technologie aanwezig zijn om veilige softwareontwikkeling uit te voeren op organisatieniveau en, in sommige gevallen, voor individuele ontwikkelingsgroepen of projecten.

02 /
Bescherm de software (PS):

Bescherm alle softwarecomponenten tegen ongeoorloofde toegang of manipulatie.

03 /
Produceer goed beveiligde software (PW):

Produceer goed beveiligde software met minimale beveiligingsproblemen in de releases.

04 /
Reageren op kwetsbaarheden (RV):

Identificeer resterende kwetsbaarheden in softwarereleases, reageer op passende wijze om deze kwetsbaarheden aan te pakken en voorkom dat soortgelijke kwetsbaarheden zich in de toekomst voordoen.

U moet de SSDF niet beschouwen als een checklist, maar eerder als een gids voor het plannen en implementeren van een op risico gebaseerde en op bewijs gebaseerde aanpak voor het ontwikkelen van veilige software.
Bedrijven moeten stappen ondernemen om hun beveiligingspositie te verbeteren om de naleving van opkomende veranderingen in de regelgeving te vergemakkelijken.

SLSA is een raamwerk waar u aan moet voldoen

Een raamwerk van Google, genaamd SLSA (Supply-chain Levels for Software Artifacts), biedt richtlijnen voor het bereiken van vier niveaus van software supply chain-bescherming. Het raamwerk richt zich op de integriteit van de constructie van de artefacten met de bedoeling manipulatie te voorkomen en artefacten veilig te stellen.

SLSA werkt op deze manier: u implementeert checklists met beveiligingscontroles die u in uw pijplijn moet implementeren, en deze controles bevinden zich in subdomeinen zoals broncontrolesystemen, bouwsystemen en afhankelijkheden die u in uw softwareprojecten inbrengt.

SLSA onderscheidt vier nalevingsniveaus met als doel niveau 4 te bereiken, dat de hoogste beveiligingswaarde zou hebben, maar een langere lijst met vereisten zou hebben.

Het SLSA-framework is gebaseerd op het concept van herkomst. Een document dat een 'keten van bewijsmateriaal' vertegenwoordigt die de oorsprong en het bouwproces van de artefacten aangeeft. Naarmate u de SLSA-niveaus stijgt, moet u het bewijsmateriaal zelf beter beschermen.

U moet SLSA beschouwen als een industriestandaard, een herkenbaar en overeengekomen niveau van bescherming en naleving waaraan u zich moet houden.

Hoe kunt u uw software supply chain beveiligen?

De verschillende raamwerken die we noemden definiëren de principes voor het beveiligen van de softwaretoeleveringsketen en vereisen uw aandacht.

Wij willen dit echter graag onderstrepen drie hoofdklassen van beveiligingscontroles:

1. Beveilig de configuratie van uw softwareontwikkelingslevenscyclus

Gecompromitteerde inloggegevens, onvoldoende controle over machtigingen en kwetsbare bouwsystemen creëren aanvalsoppervlakken die gevolgen hebben voor de softwareproducent. Aanvallers die deze kwetsbaarheden misbruiken, kunnen onbeveiligde geheimen stelen of met softwareartefacten knoeien. Een reeks commerciële en open source-oplossingen in deze klasse kunnen controles bieden om gaten in de beveiliging in kaart te brengen en deze te verhelpen.

2. Vertrouw niet op kwetsbare of kwaadaardige afhankelijkheden

Er zullen steevast nieuwe kwetsbaarheden worden ontdekt in open source en commerciële software. Softwareproducenten moeten dit risico beperken door kwetsbare open source-componenten te upgraden, te scannen op zelf toegebrachte kwetsbaarheden in hun eigen code, en softwareconsumenten te informeren over de software bill of materials (SBOM) en de daarmee samenhangende implicaties. Deze consumenten kunnen op hun beurt actie ondernemen.

Gekaapte open source-projectaccounts en kwaadaardige pakketten die zich voordoen als legitiem, brengen extra risico's met zich mee, die vooral gevolgen hebben voor geheime diefstal uit pijpleidingen. De open source-gemeenschap en enkele commerciële leveranciers werken eraan dit probleem aan te pakken door middel van verbeterde reputatie- en detectie van kwaadaardig gedrag.

3. Valideer de integriteit en de veilige constructie van de softwareartefacten

Cyberbeveiliging vereist diepgaande verdediging. Aanvallen kunnen door de mazen van het net glippen als gebruik wordt gemaakt van de traditionele benadering van bescherming tegen aanvalsoppervlakken, detectie en reputatie. Bovendien hebben downstream-softwaregebruikers tegenwoordig weinig invloed op deze controles. Ze kunnen hooguit vertrouwen op point-in-time beveiligingsaudits, zoals het scannen van codes die een momentopname van de kwetsbaarheid opleveren, van leveranciers die geen echt vertrouwen wekken dat het software-artefact goed beveiligd is en waartegen beschermd wordt tijdens de ontwikkelingslevenscyclus.

Er is nu een nieuwe, opkomende klasse van controles beschikbaar die voortdurend de integriteit en het veilige ontwikkelingsproces van elk software-artefact bevestigt. Deze attesten hebben geen goede reputatie en kunnen worden gedeeld tussen producenten en downstreamconsumenten die op zoek zijn naar validatie. Onweerlegbaarheid wordt bereikt door cryptografische methoden en verhoogt daarom de prijs aanzienlijk voor elke aanvaller die de toeleveringsketen infiltreert.

Deze aanpak wordt door experts op het gebied van software supply chain security als essentieel beschouwd. Hoewel er enkele open source-bouwstenen bestaan ​​om deze klasse van besturingselementen te ondersteunen, kunnen slechts enkele leveranciers een geïntegreerde oplossing bieden.

Een volledige software supply chain-oplossing moet het volgende omvatten:

Het verzamelen van bewijsmateriaal en het ondertekenen ervan als attesten van de softwareontwikkelings- en bouwprocessen. Meestal bestaat dit bewijs uit bestandshashes met metagegevens die worden vergeleken tussen relevante stappen in het proces, gebeurtenissen over beveiligingsgerelateerde stappen zoals de identiteit van de codecommitter, codebeoordelingen, automatische beveiligingstests, enzovoort. Het is ook noodzakelijk om een ​​attest te geven over de beveiligingsstatus van het bouwproces van de softwareproducent op het moment dat het softwareartefact werd gebouwd.

Een veilige attestopslag die zichtbaarheid mogelijk maakt en analyses ondersteunt, zoals het valideren van code-integriteit.

Een beleidsengine die deze attesten meet aan de hand van een door de organisatie gedefinieerd beleid of een op standaarden gebaseerd beleid voor validatie en demonstratie van naleving.

Een hub voor het delen van vertrouwensgerelateerde informatie tussen softwareproducenten of consumenten; dit kan inter- of intra-onderneming zijn).

Lees Verder

Het valideren van software-integriteit is een uitdaging

Theoretisch zou het controleren van de code-integriteit eenvoudig moeten zijn. Vergelijk gewoon bestanden, toch? In werkelijkheid komt er veel bij kijken. Om te beginnen compileert elke taal bestanden anders. Bovendien worden bestanden heel verschillend gebruikt, afhankelijk van hun doel. Sommige zijn bedoeld om te veranderen, terwijl andere worden verwijderd en andere worden gemaakt tijdens het compilatieproces.

Voeg daarbij het feit dat bedrijven hun eigen code niet aan elkaar willen overdragen.

Codeborging gedurende de gehele SDLC

Scribe streeft ernaar uw volledige SDLC voortdurend te beveiligen. Met bewijs verzameld uit verschillende delen van het ontwikkelings- en bouwproces, gebruikt Scribe digitale ondertekening om onvervalsbare attesten te creëren.

Na ondertekening kan elk bewijsstuk later worden geverifieerd om er zeker van te zijn dat alle processen volgens plan zijn verlopen en dat er geen ongeplande wijzigingen hebben plaatsgevonden.

Door de best practices uit de SSDF te volgen, kunt u met Scribe een beleid van gezond verstand hanteren om uw vertrouwen tijdens het ontwikkelingsproces te vergroten. Beleid zoals het vereisen van ondertekende commits, 2FA voor ontwikkelaars, codebeoordeling door twee personen, enz. helpen het vertrouwen te wekken dat elk stukje software is geproduceerd volgens de juiste beveiligingshouding.

Het verzamelen van al dit bewijsmateriaal op één enkele locatie, samen met een code-integriteitsrapport en een samenvatting van alle beleidsregels en attesten, zorgt voor een grotere zichtbaarheid en vertrouwen in het ontwikkelingsproces en de softwareartefacten die aan het eind worden geproduceerd, en is afgestemd op de SSDF-richtlijnen die gelden aan de basis van de nieuwe cyberregulering.

Door geselecteerde abonnees de mogelijkheid te bieden de naleving van de beleidsvereisten en integriteitsresultaten van het product te bekijken, krijgen gebruikers meer zichtbaarheid en vertrouwen in uw ontwikkelingspijplijnen en uiteindelijke softwareproduct.

Het eindresultaat is niet alleen het detecteren van manipulatie van code of pijplijn, maar ook de mogelijkheid om de tests en beveiligingsprocedures te bevestigen die hebben plaatsgevonden tijdens het ontwerp en de bouw van de software, evenals de integriteit van de broncode en de open-sourcepakketten. gebruikt bij het bouwen ervan.

Meer informatie

Beveiliging van de softwaretoeleveringsketen uitgelegd

Wat zit er in je code verborgen?

Hoe kan het vertrouwen in de softwaretoeleveringsketen worden verbeterd?

Wat zijn de implicaties van de definitieve versie van SSDF (NIST 800-218)?

Hoe zit het met Continuous Assurance en beveiliging van de softwaretoeleveringsketen?

Waarom is Continuous Assurance een integrale praktijk voor de beveiliging van de softwaretoeleveringsketen?

Hoe implementeer ik een geautomatiseerde SLSA-compliance-evaluatie?

Hoe kan SBOM de beveiliging van de softwaretoeleveringsketen verbeteren?

Hoe beveiligt u uw software met SBOM’s?

Automatisering van SLSA-nalevingsevaluatie

De veiligheid van dynamische pijpleidingen moet continu worden gemeten. SLSA (Supply-chain Levels for Software Artefacts) definieert vier beschermingsniveaus voor de supply chain van software, samen met richtlijnen over hoe deze te bereiken.

Een SLSA-nalevingsevaluatie kan worden geautomatiseerd om aan hun vereisten te voldoen. Maar hoe moet een organisatie er een aanschaffen? Zijn er specifieke best practices die u moet volgen?

Bekijk deze video waarin we best practices delen voor het implementeren van automatisering, met behulp van open-source tools zoals Sigstore en OPA in praktijkscenario's. Zowel conceptuele als technische best practices werpen licht op details uit de praktijk en uitdagingen bij het evalueren en automatiseren van SLSA-compliance.

Voordat u Scribe gebruikt Na het gebruik van Scribe
Trust Hub – Informatie delen

  • Een gegenereerde SBOM wordt lokaal per pijplijn opgeslagen, zonder de mogelijkheid om deze te beheren of te delen met belanghebbenden binnen de organisatie of extern.

  • Het delen en beheren van SBOM’s, zowel intern binnen de organisatie met andere stakeholders als extern met klanten of gebruikers
  • Intelligente SBOM met bruikbare inzichten
  • SBOM-inzichten kunnen worden gebruikt als go/no-go ‘poort’ op de pijplijn of het product, om te bepalen of het resulterende beeld overeenkomt met wat werd verwacht
  • Synchronisatie tussen verschillende teams en organisaties is nu mogelijk
Veilige SDLC – Beleid en naleving

  • Geen automatische of veerkrachtige manier om ervoor te zorgen dat het veilige SDLC-beleid werd gevolgd zoals vereist.

  • Een op bewijs gebaseerde, betrouwbare manier die garandeert dat veilig SDLC-beleid wordt gehandhaafd volgens de meest recente beveiligingsregels en -frameworks voor de toeleveringsketen van software (SLSA 3, SSDF)
Integriteits- en sabotagedetectie

  • Alleen wat u uit logboeken en API's kunt halen
  • Niet ondertekend tot het einde van het proces – vlak voor de oplevering (heeft alleen betrekking op 'final lag' MITM)

  • Door de codeborging voort te zetten met behulp van continue hashing en ondertekening van code in elke fase van het ontwikkelingsproces, kan worden gevalideerd dat het uiteindelijke artefact is wat het bedoeld is en dat er geen kwaadaardige code is ingevoegd door een slechte actor tijdens de ontwikkelings- en leveringsprocessen.
Zichtbaarheid

  • Wat u ook uit logboeken en API's kunt halen
  • Lokaal opgeslagen en niet ondertekend, waardoor de mogelijkheid bestaat dat kwaadwillende actoren ermee hebben geknoeid

  • Ondertekende attesten opgeslagen in een aparte, beveiligde bewijsopslag
Beveiligingshouding

  • Controleren op verkeerde configuraties van CI/CD-tools
  • Op zoek naar gelekte geheimen
  • Controleren op bekende kwetsbaarheden (CVE’s)

  • Controleren op SDLC-lacunes in uw CI/CD-toolchain.
  • Controleren op bekende kwetsbaarheden (CVE's) en de reputatie van OSS-repo's
  • Het registreren van fraudebestendige attesten dat de vereiste beveiligingsmaatregelen tijdig zijn genomen in elke fase van het proces volgens het SDLC-beleid van de organisatie.

Scribe Security - een nieuwe Software Supply Chain Security-standaard

Continuous Code Assurance bestaat uit processen en tools die:

Volg elk detail en elke gebeurtenis in het softwareontwikkelingsproces, evenals de integriteit van de softwarecomponenten en artefacten

Controleer of er in geen enkel onderdeel van het softwareontwikkelingsproces is geknoeid

Controleer de integriteit van de CI/CD-tools die zijn gebruikt om de code te bouwen

Bevestig de integriteit van het ontwikkelingsproces - zorg ervoor dat beveiligingsgerelateerde stappen zijn uitgevoerd in overeenstemming met het beleid van de organisatie en niet zijn omzeild

Door bewijs te verzamelen en te ondertekenen van alles wat er met de code gebeurt, maakt u het in elke fase van de ontwikkelingslevenscyclus moeilijker voor aanvallers om met bestanden, tools of het verwachte gedrag van uw CI/CD-pijplijn te knoeien.

Lees verder

Hoe kan HELP?

Ons unieke platform zorgt ervoor dat codeartefacten veilig zijn van Git tot productie gedurende de gehele levenscyclus van softwareontwikkeling, met behulp van de toonaangevende beveiligingsconcepten en -frameworks.

Onze klanten, verantwoordelijk voor het beveiligen van softwarebuilds en gebruikte software, vertrouwen op Scribe om ervoor te zorgen dat hun software veilig en betrouwbaar is.

Contact

Blijf op de hoogte

Continue zekerheid en beveiliging van de softwaretoeleveringsketen | Schrijver Beveiliging
Continue zekerheid: een integrale praktijk voor de beveiliging van de softwaretoeleveringsketen
Lees verder
SSDF DEFINITIEVE VERSIE
SSDF (NIST 800-218) definitieve versie – verschillen met het concept en hun implicaties voor u
Lees verder
IconBurst artikelafbeelding
IconBust, een nieuwe NPM-aanval
Lees verder

Aanvallen op de toeleveringsketen van software zijn de afgelopen jaren steeds gangbaarder en geavanceerder geworden. Volgens een Gartner rapportVerwacht wordt dat het aantal software supply chain-aanvallen tegen 2025 zal verdrievoudigen, waardoor bijna de helft van alle organisaties wereldwijd getroffen zal worden. Als gevolg van deze groeiende dreiging is het beveiligen van alle componenten, activiteiten en SDLC-praktijken belangrijker dan ooit.

Terwijl het moeilijk te voorkomen is software supply chain-aanvallen, zijn hier enkele dingen die u kunt doen om de impact ervan te beperken of de risico's ervan te verkleinen: Audit uw infrastructuur, houd een bijgewerkte inventaris bij van al uw softwaremiddelen, beoordeel leveranciers en pas een zero-trust-aanpak toe, gebruik beveiligingshulpmiddelen, beveilig uw eindpunten, enz.

Hoewel er geen garanties zijn in het leven, laat staan ​​op het gebied van veiligheid, zijn die er wel best practices voor beveiliging van de toeleveringsketen van software die ontwikkelaars en productorganisaties moeten volgen om hun softwaretoeleveringsketen te beveiligen. Binnen de verschillende fasen van uw softwarelevenscyclus kunt u deze richtlijnen gebruiken om de beveiligingspraktijken binnen uw organisatie te beschrijven, beoordelen en meten. De best practices spelen een rol in elke fase van de softwaretoeleveringsketen, inclusief aanschaf, ontwikkeling en implementatie.

Een stijging van het aantal risico's in de toeleveringsketen van software en een reeks spraakmakende inbreuken die daaruit voortvloeien, laten zien hoe ernstig het kwetsbaarheidsprobleem is. Er zijn verschillende bedreigingen voor de softwaretoeleveringsketen die kunnen worden veroorzaakt door software van derden. Aanvallers kunnen op verschillende manieren misbruik maken van kwetsbaarheden in systemen die afhankelijk zijn van software van derden. Tot deze aanvalsmethoden behoren het introduceren van kwaadaardige code in software, waardoor verwarring over afhankelijkheid en typosquatting ontstaat.

Supply chain-aanvallen verschuilen zich meestal achter legitieme processen om onbeperkte toegang te krijgen tot het software-ecosysteem van een organisatie. In de meeste gevallen beginnen aanvallers met het doorbreken van de beveiligingsmaatregelen van een leverancier of softwareleverancier. Zodra de supply chain-malware is geïnjecteerd, moet deze zich hechten aan een legitiem digitaal ondertekend proces. Software-updates worden vaak door aanvallers gebruikt om malware over de softwaretoeleveringsketen te verspreiden. Enkele van de meest voorkomende soorten software supply chain-aanvallen omvatten: gecompromitteerde tools voor het bouwen van software, gestolen code-sign-certificaten of ondertekende kwaadaardige apps met een gestolen identiteit, en gecompromitteerde code in hardware- of firmwarecomponenten.

Een SBOM (Software stuklijst), is een verzameling informatie over de vele componenten waaruit een softwareproduct of -applicatie bestaat. Het bevat meestal licentie-informatie, versienummers, componentdetails, leveranciers, enz. Een dergelijke gedetailleerde en formele lijst vermindert de risico's voor zowel de fabrikant als de gebruiker doordat anderen kunnen begrijpen wat er in hun software zit en dienovereenkomstig kunnen handelen.

SBOM's maken zichtbaarheid van productcomponenten mogelijk, maken eenvoudiger scannen op kwetsbaarheden mogelijk, maken gebruik van licentiebeheer en kunnen worden gebruikt om bedreigingen voor de integriteit te analyseren.

Continuous Assurance heeft tot doel de blinde vlek van de softwaretoeleveringsketen weg te nemen. Het omvat het verzamelen van ondertekend bewijsmateriaal over elke gebeurtenis in de ontwikkelingslevenscyclus die van invloed kan zijn op de veiligheid van het uiteindelijke softwareproduct, inclusief de bouw en implementatie van het product. Tegenwoordig gebruiken ondernemingen een verscheidenheid aan beveiligingstools om hun softwareproducten veiliger te maken. Ze stellen echter zelden een beleid op voor consistent gebruik van deze instrumenten.

Continue zekerheid zorgt ervoor dat er tijdens de ontwikkeling niet met softwareproducten is geknoeid en dat er beveiligingsgerelateerde tests zijn uitgevoerd.

Kleine wijzigingen in de code kunnen lange tijd onopgemerkt blijven. Ontwikkelteams vertrouwen op de eigenaar van de code als het gewijzigde product correct is ondertekend. Als gevolg hiervan kunnen pakketten met malware worden gemaakt en toegewezen aan vertrouwde, populaire beheerders zonder hun medeweten. Een geval van misplaatst vertrouwen kan een problematische kwetsbaarheid betekenen, of zelfs regelrecht kwaadaardige code verborgen in uw code.

Het is ook gebruikelijk dat ontwikkelaars code uit bestaande bibliotheken of StackOverflow kopiëren en plakken om in hun eigen code te gebruiken of om naar nieuwe bibliotheken te uploaden. Dit vergroot de kans dat ook onveilige en kwetsbare code wordt gekopieerd die nu feitelijk niet meer te traceren is. 

De definitieve versie van NIST SSDF 1.1 (Secure Software Development Framework) werd op 22 maart uitgebracht. In september 2021 is een conceptversie van het raamwerk gepubliceerd. Veel van de verschillen zijn gecentreerd rond de verschillende voorbeelden die worden gegeven, in plaats van op praktijken en taken op hoog niveau.

Bij het beslissen welke praktijken moeten worden geïmplementeerd, beveelt NIST aan om risico's af te wegen tegen kosten, haalbaarheid en toepasbaarheid. Om softwarebeveiliging te garanderen, is automatisering van zoveel mogelijk controles en processen een belangrijk kenmerk om te overwegen.

Het opbouwen van vertrouwen in uw software is een belangrijke taak, zeker gezien de nieuwe standaarden en best practices, zoals SSDF en SLSA. Binnenkort zullen verkopers die dit vertrouwen niet kunnen bewijzen, niet meer aan de Amerikaanse federale overheid kunnen verkopen.

Om vertrouwen op te bouwen, moet u de SBOM van uw producten behouden en delen met belanghebbenden, samen met bewijsmateriaal over hun veilige ontwikkeling en bouw.

Schrijfplatform, een echte end-to-end software-beveiligingsoplossing voor de toeleveringsketen, biedt u deze mogelijkheid. Het past continue codegarantie toe in de SDLC in een zero-trust-aanpak en genereert automatisch deelbare SBOMS, zodat u inzicht kunt krijgen in kwetsbaarheden en geknoei met code.

Dynamische pijpleidingen moeten continu worden gemonitord op veiligheid. In SLSA Cybersecurity-framework (Supply Chain Levels for Software Artefacts) zijn vier beschermingsniveaus voor softwaretoeleveringsketens gedefinieerd, samen met richtlijnen over hoe elk niveau kan worden bereikt.

U moet de best practices volgen voor het implementeren van automatisering, met behulp van open-sourcetools zoals Sigstore en OPA, om er maar een paar te noemen.