Best practices voor ketenbeveiliging van software

Broncode

• Eis sterke authenticatie. Gebruik multifactorauthenticatie voor elk codehostingaccount.
• Bescherm de hoofdbranch. Eis een review vóór de merge, en laat niemand rechtstreeks naar een releasebranch pushen.
• Houd secrets uit de code. Scan erop bij elke push, en roteer alles wat is blootgesteld.
• Behandel workflowbestanden als code. Een wijziging aan een pipeline kan uw secrets bereiken, dus verplicht een review door de eigenaren.

Afhankelijkheden

• Commit een lockfile en installeer daaruit. Gebruik npm ci en de equivalenten ervan, zodat builds niet per ongeluk nieuwe versies oppikken. Een lockfile heeft grenzen, maar het is de plek om te beginnen.
• Voeg een wachttijd toe voor nieuwe versies. Kwaadaardige releases worden vaak kort na hun verschijnen ontdekt, dus door een versie niet op de dag van publicatie over te nemen, geeft u die ontdekking de kans.
• Beperk installatiescripts. Schakel ze waar mogelijk uit. Scripts die bij de installatie draaien, zijn de manier waarop npm-wormen zich verspreiden.
• Beoordeel nieuwe afhankelijkheden. Controleer de naam op typosquatting, en kijk naar onderhoud en populariteit. OpenSSF Scorecard automatiseert een deel hiervan.
• Bescherm interne pakketnamen. Gebruik scopes en registryconfiguratie, zodat een openbaar pakket niet via dependency confusion de plaats van een intern pakket kan innemen.
• Schrap wat u niet nodig hebt. Elke afhankelijkheid is weer iets om te monitoren.

Build en CI/CD

• Pin GitHub Actions vast op een volledige commit-hash. Tags kunnen worden verplaatst, zoals het tj-actions-incident liet zien.
• Beperk wat elke job kan doen. Geef het workflowtoken de minste rechten die het nodig heeft, en gebruik kortlevende inloggegevens in plaats van langlevende secrets.
• Beperk uitgaand verkeer. Een build heeft pakketten nodig uit bekende bronnen en publiceert naar bekende plekken. Blokkeer al het andere, en gestolen secrets kunnen nergens heen. Zie egressbeleid voor GitHub Actions.
• Laat elke job draaien in een nieuwe, geïsoleerde omgeving. Er mag niets van de ene job naar de volgende meegaan, en al helemaal niet uit een pull request van een externe bijdrager.
• Behandel caches als invoer. Een vergiftigde cache blijft tussen builds bestaan, en wat hij terugzet, wordt makkelijk over het hoofd gezien. Zie GitHub Actions-cache.

Zie voor de volledige lijst de beveiligingschecklist voor CI/CD-pipelines en runnerbeveiliging vergeleken.

Release

• Genereer voor elke release een SBOM, vanuit de build. Bewaar hem bij het artefact. Zie best practices voor SBOM's.
• Onderteken artefacten en publiceer herkomstgegevens. Afnemers kunnen dan controleren waar een release vandaan komt. SLSA beschrijft de niveaus.
• Bouw releases alleen in CI. Achter een release vanaf een laptop staat geen betrouwbaar record.
• Gebruik één artefact van test tot productie. Promoot wat u hebt getest in plaats van het opnieuw te bouwen, zodat het record blijft kloppen.

Na de release

• Monitor wat u hebt geleverd. Blijf de SBOM's van ondersteunde releases toetsen aan nieuwe kwetsbaarheden.
• Prioriteer met meer dan CVSS. Gebruik CISA KEV, EPSS en context. Zie hoe u kwetsbaarheden prioriteert.
• Weet hoe lang u kwetsbaar was. De buildgeschiedenis toont welke releases een pakket bevatten, en vanaf wanneer.
• Zorg voor een plan voordat u het nodig hebt. Bepaal wie triage doet, wie het oplost en wie met klanten praat. Zie de levenscyclus van kwetsbaarheidsbeheer.
• Oefen met een echt scenario. Vraag hoe lang het zou duren om elke release met een bepaald pakket te vinden. Is het antwoord dagen, begin dan daar.

Wat u eerst doet

Wanneer	Doe dit
Deze week	Multifactorauthenticatie, lockfiles in CI, vastgepinde GitHub Actions, workflowtokens met minimale rechten
Deze maand	SBOM uit elke releasebuild, meldingen voor afhankelijkheden met een eigenaar, secret scanning
Dit kwartaal	Regels voor uitgaand verkeer van builds, monitoring van geleverde releases, een getest responsplan
Daarna	Ondertekende herkomstgegevens, een formele beoordeling van de dekking van SLSA of NIST SSDF, SBOM's van leveranciers

Wat CRACI hiervan afhandelt

CRACI dekt de build en alles wat daarna komt. Als uw GitHub Actions-runner laat het elke job draaien in een eigen geïsoleerde virtuele machine, legt het elk pakket dat de job ophaalt vast in een SBOM, markeert het pakketten die uit CI-caches zijn teruggezet en handhaaft het een egressbeleid dat verbindingen blokkeert die uw build niet nodig heeft. Daarna blijft het controleren wat is geleverd, laat het zien welke builds een kwetsbaar pakket bevatten en kan het builds blokkeren met policy gates.

De rest blijft bij uw andere tools: CRACI scant geen broncode of secrets, detecteert geen nieuwe kwaadaardige pakketten op basis van gedrag en ondertekent geen SBOM's of herkomstgegevens. Zie tools voor ketenbeveiliging van software vergeleken voor wat elk hiaat opvult.

Best practices voor ketenbeveiliging van software: veelgestelde vragen

Hoe beveiligt u een softwareketen?

Weet wat u levert met een SBOM uit elke releasebuild, bepaal wat er binnenkomt met lockfiles en beoordeling, bescherm de build door secrets en uitgaand verkeer te beperken, en blijf monitoren wat u hebt uitgebracht.

Wat moet een klein team als eerste doen?

Zet multifactorauthenticatie aan, installeer in CI vanuit lockfiles, pin GitHub Actions vast op commit-hashes en geef workflowtokens de minste rechten die ze nodig hebben. Die stappen kosten enkele dagen en sluiten veelvoorkomende aanvalspaden af.

Hoe voorkomt u kwaadaardige pakketten?

Dat lukt niet met één stap. Stel het overnemen van nieuwe versies uit, beperk installatiescripts en beoordeel nieuwe afhankelijkheden. Door uitgaand verkeer van builds te begrenzen, beperkt u de schade als er toch een kwaadaardig pakket doorheen komt.

Waarom GitHub Actions vastpinnen op een commit-hash?

Omdat een versietag naar andere code kan worden verplaatst. Een volledige commit-hash verwijst altijd naar dezelfde code, dus een gekaapte tag bereikt uw pipeline niet.

Hoe vaak moet u uw softwareketen evalueren?

Monitoring hoort doorlopend te zijn. Evalueer uw afhankelijkheidsbeleid, workflowrechten en responsplan minstens jaarlijks, en na elk incident in uw stack.