Hva innkjøp faktisk ber om

Fordi produkter ikke er fastfrosset ved én versjon: Ingeniører merger oppdateringer av avhengigheter, legger til SDK-er, bytter fonter og oppdaterer transitive pakker, ofte uten at én person følger med på hele forpliktelsesbildet. Du kan ikke pålitelig si "dette er alt som kjører i produksjon akkurat nå" fra et regneark du laget for flere måneder siden.

En PDF, zip-fil eller SBOM-vedlegg er et øyeblikksbilde. I det øyeblikket noen leverer en utgivelse med nye pakker, er det øyeblikksbildet historie. Ikke feilaktig med vilje, bare utdatert. Innkjøp arkiverer det, antar at det er oppdatert og oppdager gapet måneder senere ved en revisjon eller fornyelse.

Det egentlige kravet er ikke "send en URL i stedet for en PDF". Du trenger en gjennomgått oversikt knyttet til det du leverer, oppdatert når avhengigheter endres og delt kun etter at publiseringssperrene er passert. En offentlig etterlevelsesside er én måte å være vert for den oversikten på, slik at begge parter ser samme versjon. Lenker er ingen magi; oversikten bak dem skal holdes oppdatert.

De vil ha bevis på at du har operativ kontroll over tredjepartslisensforpliktelsene, ikke at du en gang kjørte npm list på en bærbar PC. Ulike spørreskjemaer bruker ulike ord (open source-lisensside, liste over tredjepartsprogramvare, OSS-offentliggjøring, komponentoversikt (SBOM) pluss lisenstekst), men hensikten er den samme.

En komponentoversikt (SBOM) alene tilfredsstiller ofte ikke forespørselen. Minimumselementene i en SBOM, slik de er definert av det amerikanske NTIA, dreier seg om komponentidentitet for sårbarhets- og oversiktsformål, ikke gjennomgått lisensoffentliggjøring. Innkjøp og juridiske saksbehandlere ønsker fortsatt fullstendig lisenstekst og en viss bekreftelse på at listen holder seg på linje med utgivelsene.

• Gjennomgått oversikt over tredjeparts- og open source-komponenter for produktet som vurderes.
• Fullstendig lisenstekst eller pålitelige lenker, ikke bare SPDX-identifikatorer uten tekst.
• Navngivelse og notice der lisensene krever det.
• Klarhet i hvilket produkt, hvilken utgivelse eller dato offentliggjøringen gjenspeiler.
• Ofte en URL, eksport eller vedlegg, avhengig av hva deres prosess spesifiserer.
• I økende grad: Hvordan du holder oversikten oppdatert når avhengigheter endres.

Ikke send bunnteksten med lisensinfo fra bedriftens markedsføringsnettsted hvis kjøperen vurderer API-produktet, mobilappen eller on-prem-installasjonsprogrammet deres. Hvert leverte produkt kan trenge sin egen offentliggjøringsoversikt eller en tydelig avgrenset seksjon.

Spør hvilken SKU, hvilket produktnavn, hvilken versjon eller utgivelsesdato gjennomgangen dekker. Lisensetterlevelse er produktspesifikk. Å sende dokumentasjon for feil produkt skaper mer ekstraarbeid enn å ikke sende noe i det hele tatt.

• Hvilket produkt eller hvilken SKU vurderes?
• Hvilken versjon, utgivelses-tag eller dato skal offentliggjøringen gjenspeile?
• Vil de ha en URL, en eksportfil eller begge deler?
• Gjelder gjennomgangen SaaS, installerbar programvare, innebygde systemer eller alle leveringsmodeller?
• Hvem er mottakeren: Innkjøp, juridisk, sikkerhet eller alle tre?

Før du svarer, bekreft at oversikten stemmer med byggeversjonen kundene mottar. Ikke main-branchen, ikke en utviklers lokale maskin, ikke en oversikt ingen har gjennomgått siden forrige kvartal.

I et team med flere personer endrer avhengigheter seg uten sentralt varsel. Én ingeniør oppdaterer en patch-versjon; en annen legger til en analyse-SDK; en transitiv pakke endrer lisensmetadata i registeret. Uten import-, gjennomgangs- og publiseringssperrer vet ingen at offentliggjøringen er utdatert, før en kjøper spør.

Sammenlign offentliggjøringen din med lockfilen, SBOM-en eller eksporten fra utgivelsen som vurderes. Ta stikkprøver av copyleft-komponenter, kommersielle SDK-er og alt merket trenger gjennomgang. Hvis du ikke kan verifisere hver linje, tett gapet eller vær ærlig om tidslinjen.

• Importer fra utgivelsesbranchen eller CI-artefakten, ikke en utdatert manuell liste.
• Bekreft at hver komponent innenfor omfanget har godkjent lisenstekst.
• Avklar ikke-gjennomgåtte rader før du fremstiller oversikten eksternt.
• Sjekk at produktnavnet i offentliggjøringen stemmer med det kjøperen kjøper.
• Noter utgivelses-taggen eller datoen oversikten gjenspeiler og opplys om det i svaret ditt.

Send det de ba om (URL, PDF-eksport, JSON-pakke) fra det samme godkjente publiseringsøyeblikksbildet. Oppgi hvilket produkt og hvilken utgivelse det dekker. Beskriv kort hvordan du oppdaterer oversikten når avhengigheter endres: Re-importer, gjennomgå på nytt, publiser på nytt.

Ikke antyd juridisk godkjenning med mindre juridisk faktisk har godkjent det. Ikke si "dette er alt i stacken vår for alltid." Si hva som ble gjennomgått, for hvilket produkt, per hvilken utgivelse, og at du vedlikeholder oversikten etter hvert som kodebasen endres.

Hvis oversikten ikke er klar, oppgi en realistisk dato. Innkjøp foretrekker ærlighet fremfor et øyeblikksbilde som feiler ved gjennomgang fordi noen merget fem oppdateringer av avhengigheter etter at du genererte det.

• Start med produktnavnet og "offentliggjøring av tredjepartslisenser" eller "open source-lisensetterlevelse."
• Oppgi utgivelsen, taggen eller datoen oversikten gjenspeiler.
• Oppgi URL-en eller vedlegget de ba om, fra samme gjennomgåtte data.
• Én setning om vedlikehold: Hvordan du republiserer når avhengigheter endres.
• Tilby eksporter hvis spørreskjemaet krever det, generert fra samme øyeblikksbilde.

Å eksportere en liste én gang og gjenbruke den på tvers av utgivelser. Å anta at ingen har lagt til pakker siden forrige RFP. Å sende en rå SBOM uten gjennomgått lisenstekst. Å sende en trust center-PDF om sikkerhet som aldri lister tredjepartslisenser.

Å hevde at SOC 2 eller ISO 27001 dekker open source-lisensforpliktelser (det gjør de som regel ikke). Å behandle "vi bruker open source" som offentliggjøring. Alt dette svikter når kjøperen sammenligner svaret ditt med det som faktisk leveres eller det som ble levert to sprinter etter at du svarte.

Løsningen er operativ: Oversikt fra byggegrunnlaget, menneskelig gjennomgang før ekstern deling, oppdatering ved endring i avhengigheter. Ikke et bedre filformat.