Hvad indkøb egentlig beder om

Fordi produkter ikke er fastfrosset ved én version: Udviklere merger opdateringer af afhængigheder, tilføjer SDK'er, udskifter skrifttyper og opdaterer transitive pakker, ofte uden at én person følger med i hele billedet af forpligtelser. I kan ikke pålideligt sige “det er alt, der kører i produktion lige nu” ud fra et regneark, I byggede for måneder siden.

En PDF, en zip-fil eller en SBOM-vedhæftning er et øjebliksbillede. I samme øjeblik nogen sender en udgivelse med nye pakker, er det øjebliksbillede historisk. Ikke forkert med vilje, bare forældet. Indkøb arkiverer det, går ud fra, at det er aktuelt, og opdager hullet måneder senere ved en audit eller fornyelse.

Det reelle krav er ikke “send en URL i stedet for en PDF.” I har brug for en gennemgået oversigt knyttet til det, I sender i produktion, opdateret når afhængigheder ændrer sig, og kun delt efter publish-gates er bestået. En offentlig compliance-side er én måde at hoste den registrering på, så begge parter ser den samme version. Links er ikke magi. Registreringen bag dem er beregnet til at blive opdateret.

De vil have bevis for, at I har operationel kontrol over tredjepartslicensforpligtelser, ikke at I engang kørte npm list på en bærbar. Forskellige spørgeskemaer bruger forskellige ord (open source-licensside, liste over tredjepartssoftware, OSS-oplysning, software bill of materials plus licenstekst), men hensigten er den samme.

En software bill of materials alene opfylder ofte ikke anmodningen. En SBOM's minimumselementer, som defineret af det amerikanske NTIA, centrerer sig om komponentidentitet til brug for sårbarheds- og oversigtsformål, ikke gennemgået licensoplysning. Indkøb og jura vil stadig have fuld licenstekst og en form for bekræftelse af, at listen forbliver på linje med udgivelserne.

• Gennemgået oversigt over tredjeparts- og open source-komponenter for det produkt, der gennemgås.
• Fuld licenstekst eller pålidelige links, ikke SPDX-id'er uden tekst.
• Kildeangivelse og notice, hvor licenser kræver dem.
• Klarhed om, hvilket produkt, hvilken udgivelse eller hvilken dato oplysningen afspejler.
• Ofte en URL, en eksport eller en vedhæftet fil, alt efter hvad deres proces angiver.
• I stigende grad: Hvordan I holder registreringen ajour, når afhængigheder ændrer sig.

Send ikke jeres virksomheds marketingside-licensfooter, hvis køberen evaluerer jeres API-produkt, mobilapp eller on-prem-installer. Hvert produkt i produktion kan have brug for sin egen oplysningsregistrering, eller et klart afgrænset afsnit.

Spørg, hvilket SKU, produktnavn, version eller udgivelsesdato gennemgangen dækker. Licens-compliance er produktspecifik. At sende dokumentation for det forkerte produkt skaber mere ekstraarbejde end slet ikke at sende noget.

• Hvilket produkt eller SKU gennemgås?
• Hvilken version, release-tag eller dato skal oplysningen afspejle?
• Vil de have en URL, en eksportfil eller begge dele?
• Gælder gennemgangen SaaS, installerbar software, embedded eller alle leveringsmodeller?
• Hvem er målgruppen: Indkøb, jura, sikkerhed eller alle tre?

Før I svarer, så bekræft, at registreringen matcher den build, kunder modtager. Ikke main-branchen, ikke en udviklers lokale maskine, ikke en oversigt, ingen har gennemgået siden sidste kvartal.

I et team med flere personer skifter afhængigheder uden central besked. Én udvikler opdaterer en patch-version, en anden tilføjer en analytics-SDK, en transitiv pakke ændrer licensmetadata i registret. Uden gates til import, gennemgang og udgivelse ved ingen, at oplysningen er forældet, før en køber spørger.

Sammenlign jeres oplysning med lockfilen, SBOM'en eller eksporten fra den udgivelse, der gennemgås. Stikprøvekontrollér copyleft-komponenter, kommercielle SDK'er og alt markeret skal gennemgås. Hvis I ikke kan verificere hver linje, så ret hullet, eller vær ærlige om tidsplanen.

• Importér fra release-branchen eller CI-artefaktet, ikke en forældet manuel liste.
• Bekræft, at hver omfattet komponent har godkendt licenstekst.
• Afklar rækker, der ikke er gennemgået, før I repræsenterer registreringen eksternt.
• Tjek, at produktnavnet i oplysningen matcher det, køberen køber.
• Notér den release-tag eller dato, oversigten afspejler, og angiv det i jeres svar.

Send det, de bad om (URL, PDF-eksport, JSON-pakke), fra det samme godkendte udgivelses-snapshot. Angiv, hvilket produkt og hvilken udgivelse det dækker. Beskriv kort, hvordan I opdaterer registreringen, når afhængigheder ændrer sig: Genimport, gen-gennemgang, genudgivelse.

Antyd ikke juridisk godkendelse, medmindre en advokat har godkendt det. Sig ikke “dette er alt i vores stack for evigt.” Sig, hvad der blev gennemgået, for hvilket produkt, pr. hvilken udgivelse, og at I vedligeholder registreringen, efterhånden som kodebasen ændrer sig.

Hvis registreringen ikke er klar, så giv en realistisk dato. Indkøb foretrækker ærlighed frem for et øjebliksbillede, der ikke består gennemgangen, fordi nogen har merget fem opdateringer af afhængigheder, siden I genererede det.

• Start med produktnavnet og “oplysning om tredjepartslicenser” eller “open source-licens-compliance.”
• Angiv den udgivelse, tag eller dato, oversigten afspejler.
• Lever den URL eller vedhæftede fil, de bad om, fra de samme gennemgåede data.
• Én sætning om vedligeholdelse: Hvordan I genudgiver, når afhængigheder ændrer sig.
• Tilbyd eksporter, hvis spørgeskemaet kræver dem, genereret fra det samme snapshot.

At eksportere en liste én gang og genbruge den på tværs af udgivelser. At antage, at ingen har tilføjet pakker siden sidste RFP. At sende en rå SBOM uden gennemgået licenstekst. At sende en trust center-PDF om sikkerhed, der aldrig lister tredjepartslicenser.

At påstå, at SOC 2 eller ISO 27001 dækker open source-licensforpligtelser (det gør de som regel ikke). At behandle “vi bruger open source” som oplysning. Hver af disse fejler, når køberen sammenligner jeres svar med det, der rent faktisk leveres, eller det, der blev leveret to sprints efter, I svarede.

Løsningen er operationel: Oversigt ud fra build-input, menneskelig gennemgang før ekstern deling, opdatering ved ændringer i afhængigheder. Ikke et bedre filformat.