Verifieer wat de release binnenkomt

Vraag of de dependency nodig is

Een agent kan een pakket voorstellen dat een probleem lijkt op te lossen. De suggestie is een voorstel, geen bewijs dat het pakket bestaat of geschikt is. Verifieer vóór installatie de exacte registry, uitgever, pakketnaam en versie.

Voor een fictieve CSV-export kan de runtime het vereiste gedrag al bieden. Een nieuw pakket kan nog steeds passend zijn, maar voegt onderhoud en uitvoeringspaden toe. Vergelijk de implementatie-inspanning met de blijvende verantwoordelijkheden van de dependency.

Review de licentie en ondersteunde runtime. Inspecteer onderhoudsactiviteit en relevante beveiligingsberichten. Een bekende naam kan in een andere registry naar een ander pakket verwijzen. Een geslaagde installatie toont alleen dat de installatie is afgerond.

Inspecteer installatie- en buildgedrag

Dependencies kunnen tijdens installatie of build code uitvoeren. Beperk toegangsgegevens en netwerktoegang in die omgevingen. Stel productiesecrets niet beschikbaar aan een job die een onvertrouwde pull request verwerkt.

Gebruik een lockfile die in Git is vastgelegd als het ecosysteem dit ondersteunt. Vereis dat de build dat bestand respecteert. Review lockfilewijzigingen samen met de bronwijziging, inclusief onverwachte transitieve pakketten. Versies vastzetten verbetert reproduceerbaarheid, maar maakt een kwetsbare versie niet veilig.

NIST’s SSDF behandelt bescherming van software en ontwikkelpraktijken tijdens de hele levenscyclus. Gebruik dat bredere perspectief bij het ontwerpen van de buildomgeving. Lees het framework.

Scheid inventaris van herkomstbewijs

Een software bill of materials, SBOM, registreert componenten in software. Die helpt getroffen releases te vinden wanneer een component een aandachtspunt wordt. De SBOM toont niet zelfstandig aan dat de componenten veilig zijn.

Provenance beschrijft hoe een artefact is gemaakt. SLSA definieert een provenanceformaat voor informatie over de build en zijn invoer. Verificatie moet deze informatie koppelen aan een vertrouwde maker en het artefact dat u wilt gebruiken. Een bestand met de naam ‘provenance’ volstaat niet. SLSA-provenance.

Leg voor de exportdienst een inspecteerbare keten vast:

1. De gereviewde commit identificeert de geaccepteerde bron.
2. De build identificeert zijn invoer en uitvoeringsomgeving.
3. Het artefact heeft een stabiele digest.
4. De controles identificeren het onderzochte artefact of de bron.
5. De deployment registreert het artefact dat in de doelomgeving is geplaatst.

Bouw na goedkeuring niet op een andere manier opnieuw zonder een vastgesteld verificatieproces. Een veranderlijke tag zoals latest kan later naar een andere image verwijzen.

Bepaal wat een bevinding betekent

Een kwetsbaarheidsbevinding vraagt context: getroffen versie, bereikbaar gedrag, blootstelling, beschikbare correctie en gevolg. Leg het bewijs achter een tijdelijke uitzondering vast. Geef die een verantwoordelijke, vervaldatum en aanleiding voor herbeoordeling.

Schakel niet een volledige scanner uit omdat één bevinding niet van toepassing is. Claim geen schoon resultaat als de scan niet kon worden voltooid. Een timeout, niet-ondersteund pakket of onbeschikbare adviesfeed betekent ontbrekend bewijs.

Plan tot slot updates na de release. Nieuwe beveiligingsberichten kunnen het gisteren geaccepteerde artefact raken. De dienstverantwoordelijke heeft een inventaris, opvolgingsproces en capaciteit nodig om een gecorrigeerde release te maken.

Ga verder met doorlopend kwetsbaarhedenbeheer om herhaalde scans te koppelen aan geverifieerde productiecorrecties.