Best practices voor softwaretoeleveringsketenbeveiliging

De software-toeleveringsketen verwijst naar alles en iedereen die op de een of andere manier verbonden is met uw softwarecode gedurende de gehele ontwikkelingslevenscyclus. Elk stukje software bestaat uit verschillende componenten. Naast de eigen code die helemaal opnieuw is geschreven, vereist code ook externe software-infrastructuur, cloudservices en besturingssystemen om goed te kunnen werken. De registers, opslagplaatsen, codebases en zelfs de mensen die deze software hebben geschreven, maken allemaal deel uit van de softwaretoeleveringsketen.

Elk knooppunt in deze complexe keten is een potentieel kwetsbaarheidspunt dat op bepaalde manieren invloed kan hebben op de prestaties en veiligheid van uw software. Kwetsbaarheid die op enig punt in deze afhankelijkheidsketen wordt geïntroduceerd, heeft stroomafwaarts ernstige gevolgen. Dat komt omdat de complexiteit van de software-toeleveringsketen de risico's maskeert en het moeilijk maakt om te voorspellen en te identificeren zonder een gestandaardiseerd raamwerk voor het beveiligen van de toeleveringsketen. Daarom is het belangrijk dat ontwikkelaars en productorganisaties dit doen Ontdek wat software supply chain-beveiliging is.

Beveiliging van de softwaretoeleveringsketen verwijst naar de reeks gestandaardiseerde praktijken die zijn ingevoerd om uw software te beschermen tegen potentiële kwetsbaarheden gedurende de levenscyclus van softwareontwikkeling, vanaf het moment van applicatieontwikkeling en door middel van continue integratie en implementatie (CI/CD-pijplijn).

Het is belangrijk dat beveiligingsteams de lijst met best practices voor de beveiliging van de softwaretoeleveringsketen begrijpen en volgen om de softwaretoeleveringsketen van hun organisatie veilig te houden. In dit bericht worden de best practices voor de toeleveringsketen beschreven die u moet kennen.

Best practices om uw softwaretoeleveringsketen te beveiligen

In dit gedeelte wordt verwezen naar de standaardpraktijken die ontwikkelaars en productorganisaties moeten volgen om hun softwaretoeleveringsketen te beveiligen. U kunt deze richtlijnen gebruiken als basiskader voor het beschrijven, beoordelen en meten van beveiligingspraktijken voor uw organisatie binnen de verschillende fasen van uw softwarelevenscyclus. Deze best practices bestrijken de acquisitie-, ontwikkelings- en implementatiefase van de softwaretoeleveringsketen om de integriteit van uw ontwikkelomgeving, broncode en eindproduct te garanderen.

Schaf goed beveiligde componenten aan

Het opnemen van componenten van derden in software is een standaardpraktijk voor ontwikkelaars, omdat ze hierdoor bestaande API-mogelijkheden kunnen benutten om de gewenste functionaliteit te leveren in plaats van helemaal opnieuw te bouwen. Componenten van derden kunnen de vorm hebben van commerciële, eigen software of gratis open source-tools. Wanneer u een van deze componenten aanschaft, is het belangrijk dat u beveiliging beschouwt als een van de belangrijkste criteria waaraan de softwarecomponent moet voldoen.

Om de veiligheid van componenten van derden te bepalen, moet u mogelijk geavanceerde beveiligingsanalyses uitvoeren, zoals analyse van de veilige samenstelling, analyse van kwetsbaarheidsdatabases, broncode-evaluatie en risicobeoordelingsanalyse. Het resultaat van deze controles helpt bepalen of dit onderdeel veilig is en moet worden toegestaan ​​voor uw product

Bovendien moeten geselecteerde componenten continu worden gemonitord met behulp van een geautomatiseerde service voor het volgen van kwetsbaarheden om kwetsbaarheden zo snel mogelijk te identificeren en deze onmiddellijk te verwijderen.

Maak intern veilige softwarecomponenten die voldoen aan veilige coderingspraktijken

Hoewel externe softwarecomponenten die in uw software zijn opgenomen belangrijk zijn, zijn de veiligheid en integriteit van softwareproducten ook afhankelijk van de veilige codeerpraktijken die u intern volgt.

Elke organisatie heeft een alomvattend raamwerk voor de levenscyclus van softwareontwikkeling nodig dat veilige codeerpraktijken omvat om ervoor te zorgen dat de gecreëerde artefacten in overeenstemming zijn met de vastgelegde richtlijnen.

Om te beginnen hangt de integriteit van uw softwareproducten en de artefacten die u intern bouwt af van de kwaliteit van uw team. Uw ontwikkelingsteam moet bestaan ​​uit ontwikkelingsexperts, kwaliteitsborgingsprofessionals, cyberbeveiligingsprofessionals en bouwingenieurs met een goede kennis van standaard beveiligingspraktijken.

Het productmanagementteam moet ook beveiligingsarchitecten, productmanagers en productleiders omvatten die ervoor zorgen dat het veilige ontwikkelingsbeleid wordt nageleefd. Enkele van de basisstrategieën om ervoor te zorgen dat u intern veilige softwareartefacten maakt, zijn:

• Het genereren van ontwerp- en architectuurdocumenten voor elk artefact
• Het creëren van bedreigingsmodellen voor softwareproducten
• Het definiëren en implementeren van beveiligingstests
• Het instellen van specifieke vrijgavecriteria voor het evalueren van het product
• Het vaststellen van beleid voor de afhandeling van kwetsbaarheden voor elk product
• Documenteren en publiceren van beveiligingsprocedures voor elke softwarerelease

 Gebruik veilige softwaretoolketens en compatibiliteitsbibliotheken van derden

Veel Integrated Development Environments (IDE) die in het softwareontwikkelingsproces worden gebruikt, staan ​​op zichzelf. Dit betekent dat u met behulp van dezelfde tool verschillende stappen binnen het ontwikkelingsproces kunt uitvoeren, zoals coderen, compileren, verpakken en debuggen van code. Sommige IDE's hebben ook tools om een ​​bron aan een externe repository te koppelen. IDE's met deze functie ondersteunen meerdere compilertalen. Naast deze kernfuncties kunnen ontwikkelaars mogelijk de mogelijkheden van de IDE die ze gebruiken uitbreiden met plug-ins. Dit is een potentiële bron van kwetsbaarheid voor de lokale ontwikkelingsomgeving, vanwege de complexiteit van dit soort onbetrouwbare bronnen.

Om uw ontwikkelomgeving veilig te houden, moeten alle IDE's en plug-ins die in de omgeving worden gebruikt, worden gecontroleerd en vooraf goedgekeurd nadat ze zijn gescand op kwetsbaarheden en gevalideerd.

Naast plug-ins die de mogelijkheden van uw bouwomgeving uitbreiden, zijn softwaretoolketens en compatibiliteitsbibliotheken een andere categorie bouwtools van derden die u mogelijk op kwetsbaarheden moet controleren. Deze besturingssysteemtools van derden worden in de ontwikkelomgeving geïnstalleerd, zodat u specifieke hulpprogramma's en opdrachten kunt gebruiken die uniek zijn voor dat besturingssysteem. Een Windows-ontwikkelomgeving kan bijvoorbeeld tijdens het bouwproces enkele besturingssysteemopdrachten vereisen die uniek zijn voor het Linux-besturingssysteem om compatibiliteit tussen beide systemen tijdens het productieproces te bieden.

Op dezelfde manier helpen API-conversiebibliotheken u ook bij het creëren van een gemeenschappelijke codeeromgeving voor twee verschillende besturingssystemen. Deze API-toolchains zijn open-source en commerciële tools en er moet toegang tot worden verkregen om kwetsbaarheden op te sporen voordat ze voor uw bouwomgeving worden gebruikt en voor uw project worden gebruikt.

Beperk wijziging of exploitatie van de broncode door insiders

Volgens de Cybersecurity and Infrastructure Security Agency (CISA) is een insider elke persoon met geautoriseerde toegang tot of kennis van de bronnen van een organisatie. Personen die toegang hebben of hadden tot uw faciliteiten, netwerk, apparatuur en systemen kunnen mogelijk de integriteit van uw softwareproduct in gevaar brengen, zowel opzettelijk als onbewust.

Als onderdeel van de inspanningen om uw software te beveiligen, moet u ervoor zorgen dat het ontwikkelingsproces beleid hanteert om opzettelijke of onopzettelijke blootstelling aan kwaadaardige code in uw productiecode door insiders, zoals gecompromitteerd personeel, slecht opgeleide technici of inactieve werknemers, te voorkomen. Enkele van de maatregelen die u kunt nemen om dit te verzachten, zijn onder meer:

• Evenwichtig en geverifieerd incheckproces voor de broncode
• Geautomatiseerde beveiligingsscans op kwetsbaarheden
• Training voor veilige softwareontwikkeling
• Het verharden van de ontwikkelomgeving
• Prioriteit geven aan codebeoordelingen

Sla code of uitvoerbare bestanden op en bekijk alle wijzigingen voordat ze worden goedgekeurd

Versiebeheer is een van de standaardpraktijken die kunnen helpen de integriteit van uw software te behouden. Als onderdeel van uw continue integratie- en implementatieproces (CI/CD-pijplijn) moet u een opslagplaats onderhouden om uw code en uitvoerbare bestanden op te slaan. Dit biedt een werkgeschiedenis van uw code, zodat u gemakkelijk kunt volgen wat er tot dat moment in de ontwikkelingsstack is gegaan.

U hebt ook een continu goedkeuringssysteem nodig om alle wijzigingen die in uw software worden aangebracht te beoordelen voordat ze worden goedgekeurd. Dit is vooral handig bij het samenwerken met andere ontwikkelaars binnen teams. Het oplossen van problemen is in dit geval eenvoudiger, omdat u gemakkelijk wijzigingen kunt identificeren terwijl ze worden aangebracht en wie ze maakt.

Hoe eenvoudig of complex de software die u bouwt ook is, een bron- of versiebeheersysteem maakt het gemakkelijk om alle wijzigingen die in uw code worden aangebracht te zien en te volgen, de versiegeschiedenis bij te houden wanneer dat nodig is, of zelfs terug te keren naar een eerdere versie van uw code. coderen wanneer dat nodig is.

Creëer en onderhoud een SBOM voor elk gecreëerd softwarepakket

De Software stuklijst is essentiële documentatie waarin alle componenten van derden worden beschreven die in uw softwareproduct zijn opgenomen. Een SBOM maakt het gemakkelijk om alle goedgekeurde componenten van een stukje software te valideren en eventuele kwetsbaarheden of defecten eenvoudig te identificeren. Voor elk softwarepakket dat u maakt, moet u er ook een SBOM voor maken en onderhouden.

Een Software Bill of Materials kan worden opgesteld op basis van de specificaties die zijn gedefinieerd in standaardformaten zoals de Software Package Data Exchange (SPDX), CycloneDX en Software Identification (SWID) tags zoals gedefinieerd door respectievelijk Linux, OWASP en NIST.

Voor elk softwareproduct dat u bouwt, moeten de leveranciers of eigenaren van de componenten van derden die u gebruikt een uitgebreide Software Bill of Materials overleggen. De deliverables voor uw project en de SBOM’s die door de leverancier worden aangeleverd, kunnen ook worden gevalideerd met behulp van een compositieanalyse-tool (SCA).

Zelfs als de leverancier geen SBOM verstrekt, kan de SBOM die is gegenereerd met de softwarecompositie-analysetool nog steeds de vereiste informatie leveren om de componenten van de software van derden te beschrijven. Het proces van het genereren van SBOM’s geautomatiseerd zou moeten zijn. SBOM-automatisering is van vitaal belang omdat de externe leveranciers en ontwikkelaars elke keer dat software van derden wordt gewijzigd een nieuwe SBOM moeten genereren, en dit handmatig doen is onpraktisch. De bijgewerkte SBOM beschrijft alle verbeteringen of wijzigingen in de componentcode en hun relatie met het softwareproduct.

Verhard de bouwomgeving

Een van de manieren om de integriteit van uw software te garanderen, is door de ontwikkelomgeving te beschermen tegen mogelijke kwetsbaarheden. Dit omvat zowel de individuele ontwikkelaarsomgeving als de algehele productieomgeving.

Of uw bouwomgeving nu in de cloud of op locatie wordt gehost, u moet deze configureren en maatregelen nemen om de server en het netwerk te beveiligen, terwijl u ook bepaalt wie toegang heeft tot wat. Door op deze manier due diligence uit te voeren bij het optimaliseren en beveiligen van de bouwomgeving, wordt de integriteit van uw broncode en het eindproduct gegarandeerd.

Het beveiligen van de bouwpijplijn omvat het beveiligen van alle systemen die u gebruikt tijdens het bouwproces voor uw product. Dit omvat codeopslagplaatsen, ondertekeningsservers, technische werkstations, implementatieservers, enzovoort. Enkele van de maatregelen die u kunt nemen om de infrastructuur van uw aangelegde pijpleiding te beveiligen, zijn onder meer:

Sluit systemen af

Om uw systemen te beveiligen, moet u de systeembewerkingen beperken tot specifieke functies waarvoor het systeem bedoeld is. Uw bouwsysteem mag bijvoorbeeld alleen worden gebruikt voor bouwbewerkingen en niets anders.

Beperk externe netwerkactiviteiten en activiteiten buiten het LAN

Zowel inkomende als uitgaande netwerkactiviteiten kunnen uw systeem mogelijk blootstellen aan aanvallen. U moet alle externe en off-LAN-activiteiten blokkeren en externe verbindingen beperken tot de benodigde URL's.

Monitor systemen op datalekken

Om de integriteit van de broncode van uw product te garanderen, moet u uw cyberbeveiligingsverdediging instellen om uw repository, werkstation en andere delen van uw bouwomgeving te beschermen tegen exfiltratie en infiltratie van gegevens. Dit omvat het blokkeren van al het kwaadaardige gedrag, het isoleren van apps en het opzetten van detectiesystemen om indringers te detecteren zodra deze zich voordoen.

Configureer uw pijplijn voor versiebeheer

Uw codepijplijn moet versiebeheerd zijn. Bij het aanbrengen van wijzigingen aan uw product moeten updates worden aangebracht op de configuratiecode en niet op de daadwerkelijke systemen.

Multi-factor authenticatie

Elk systeem dat deel uitmaakt van uw bouwomgeving moet waar mogelijk worden geconfigureerd met meervoudige authenticatie. Er moeten ook aanvullende beveiligingsmaatregelen worden genomen, zoals op rollen gebaseerde toegang, minimale bevoegdheden, enzovoort. De NIST-richtlijn beveelt ook een dubbel autorisatiesysteem aan voor alle kritische of gevoelige systemen in uw bouwomgeving.

Segregeer uw technische netwerk

Uw bouwsysteem mag alleen toegankelijk zijn via een geïsoleerd technisch netwerk dat verschilt van de rest van het netwerk van uw organisatie. Indien mogelijk moet het engineeringnetwerk offline zijn.

Analyseer elke kwetsbaarheid om voldoende informatie te verzamelen om het herstel ervan te plannen

Bij het ontwikkelen van software moeten maatregelen worden genomen om ervoor te zorgen dat uw product en alle componenten ervan vrij zijn van bekende risicovolle kwetsbaarheden. Op dezelfde manier moet u onmiddellijk op het incident reageren als er nieuwe kwetsbaarheden worden ontdekt of gerapporteerd door een klant. In sommige gevallen zal dit vereisen dat u uw systeem bijwerkt om de risico's die gepaard gaan met de nieuw ontdekte kwetsbaarheid te beperken.

Softwareleveranciers moeten over een proces beschikken om updates of rapporten over potentiële kwetsbaarheden of defecten in hun producten te accepteren, hetzij van externe onderzoekers, hetzij van klanten. U hebt ook een geautomatiseerd systeem nodig dat u op de hoogte stelt van updates van kwetsbaarheden die zijn aangekondigd door vertrouwde organisaties zoals de Cybersecurity & Infrastructure Security Agency (CISA).

Elke organisatie heeft een intern beleid voor kwetsbaarheidsbeheer nodig dat voldoet aan de standaardrichtlijnen. Waarschuwingen over bedreigingen met een hoog risico moeten worden geëvalueerd op basis van de relatie tussen uw product en de onderdelen ervan die mogelijk zijn getroffen door de gerapporteerde kwetsbaarheid. Uw technische team moet ook beschikken over een uitgebreid systeem voor het beoordelen, diagnosticeren en mogelijk oplossen van problemen

Onderhoud van onderdelen

Een softwareproduct en zijn componenten zijn nooit statisch. Houd er rekening mee dat componenten van derden die in uw producten zijn geïntegreerd, periodiek door de leverancier kunnen worden gewijzigd of bijgewerkt. U moet deze wijzigingen in de gaten houden, vooral als ze verband houden met veelvoorkomende kwetsbaarheden en blootstellingen (CVE's).

Een groot deel van het onderhoud van uw softwarecomponenten bestaat uit het monitoren van standaard CVE-rapportagemechanismen en andere ondersteuningskanalen om te bepalen of nieuw geïdentificeerde kwetsbaarheden in een component van derden die in uw product zijn opgenomen de integriteit van uw eigen systemen aantasten en passende maatregelen nemen om de risico's te beperken ( indien aanwezig).

Wanneer u componenten van derden selecteert die in uw product moeten worden opgenomen, moet u het contract controleren om er zeker van te zijn dat de eigenaar van het onderdeel beleid heeft over hoe zij productorganisaties op de hoogte stellen van updates van hun systemen, de aanwezigheid van kwetsbaarheden en het tijdsbestek voor kwetsbaarheden. resolutie, evenals alle acties die u mogelijk aan uw kant moet uitvoeren om optimale beveiliging te garanderen.