Bronnen · 16
Software supply chain assurance: componenten voor release
Koppel componenten, provenance, builds, kwetsbaarheden en updates aan elke daadwerkelijk geïmplementeerde release.
Bijgewerkt · 2 min
Wat deze handleiding helpt bereiken
- Ken de daadwerkelijk geleverde afhankelijkheden
- Verifieer de oorsprong van het artefact
- Prioriteer kwetsbaarheden in context
- Test vervanging en terugdraaien
Snelle controle
- Komt de stuklijst overeen met de geïmplementeerde versie?
- Zijn transitieve afhankelijkheden opgenomen?
- Wie mag een release ondertekenen?
- Is een kwetsbaarheid bereikbaar in uw gebruik?
- Kan een kritieke component worden verwijderd zonder improvisatie?
Stapsgewijze methode
- 1
Breng geleverde releases in kaart
Identificeer repositories, directe en transitieve afhankelijkheden, buildtools, images, externe services en eigenaren. Verbind ze allemaal met een verifieerbare release.
Resultaat: kaart van product, component, versie en eigenaar.
- 2
Een bruikbare stuklijst genereren
Een SBOM genereren voor elke release en deze vergelijken met de daadwerkelijk verzonden artefacten. Onjuiste namen, ontbrekende versies en interne componenten corrigeren.
Resultaat: gedateerde en gevalideerde SBOM.
- 3
De build beschermen
Publicatierechten beperken, gevoelige fasen isoleren en herkomst, samenvattingen en handtekeningen bewaren. Dit bewijsmateriaal verifiëren vóór implementatie.
Resultaat: buildrecord en verificatiebeleid.
- 4
Waarschuwingen prioriteren
Elke kwetsbaarheidsmelding koppelen aan de component, versie, blootstelling en het daadwerkelijke gebruik. Een eigenaar, deadline, beslissing en bewijs van afsluiting toewijzen.
Resultaat: contextuele triage-wachtrij.
- 5
Wijziging oefenen
Een kritieke component vervangen in een testomgeving, bedrijfsprocessen controleren en terugdraaien oefenen. Afhankelijkheden meten die de wijziging blokkeren.
Resultaat: rapport over de vervangings- en terugvaloefening.
- 6
Bewijsmateriaal bewaren
Componenten en leveranciers beoordelen bij grote releases en na incidenten. Gegevens bewaren gedurende een periode die onderzoek en correctie ondersteunt.
Resultaat: beoordelingskalender en releasegeschiedenis.
Managementindicatoren
| Indicator | Wat het meet | Eerste actie |
|---|---|---|
| SBOM-dekking | Verzonden releases met een gecontroleerde componenteninventaris | Discrepanties oplossen vóór publicatie |
| Herkomst geverifieerd | Artefacten gecontroleerd vóór implementatie | Releases blokkeren die het verwachte bewijs missen |
| Triagetijd | Tijd tussen relevante melding en gedocumenteerde beslissing | Blootgestelde componenten escaleren |
| Omkeerbaarheid | Kritieke vervangingen getest met rollback | Blokkerende afhankelijkheden verwijderen |
Veelvoorkomende fouten
- Verwarring tussen repository-inventaris en geïmplementeerde componenten
- Een SBOM bewaren zonder deze bij te werken
- Een fout alleen rangschikken op basis van score
- Een artefact ondertekenen zonder de herkomst van de build te verifiëren
Veelgestelde vragen
Is een SBOM voldoende?
Nee. Het helpt bij het identificeren van componenten, maar herkomst, integriteit, blootstelling en updatemogelijkheid moeten ook worden geverifieerd.
Moet elke kwetsbaarheid de release blokkeren?
Bepaal de beslissing op basis van daadwerkelijk gebruik, blootstelling, compenserende maatregelen en bedrijfskritische factoren, en documenteer de redenering.
Welk referentiekader is nuttig?
Het NIST Secure Software Development Framework biedt veilige ontwikkelings- en softwarebeveiligingspraktijken gedurende de gehele levenscyclus.
Officiële referenties
Referenties ondersteunen de methode. Pas controles aan uw context aan; ze zijn geen certificering. Originele referentietitels en brondocumenten kunnen in een andere taal zijn.
