Vad inköp faktiskt efterfrågar

Eftersom produkter inte är låsta vid en version: Utvecklare mergar beroendeuppdateringar, lägger till SDK:er, byter typsnitt och uppdaterar transitiva paket, ofta utan att en enda person har koll på hela skyldighetsbilden. Du kan inte tillförlitligt säga “det här är allt som körs i produktion just nu” utifrån ett kalkylblad du byggde för månader sedan.

En PDF, zip-fil eller SBOM-bilaga är en ögonblicksbild. I samma stund någon levererar en release med nya paket blir den ögonblicksbilden historisk. Inte felaktig med avsikt, bara inaktuell. Inköp arkiverar den, antar att den är aktuell, och upptäcker gapet månader senare vid en revision eller förnyelse.

Det egentliga kravet är inte “skicka en URL istället för en PDF”. Du behöver en granskad förteckning kopplad till det du levererar, uppdaterad när beroenden ändras, och delad först efter att publiceringsgrindarna passerats. En offentlig licenssida är ett sätt att hosta den redovisningen så att båda sidor ser samma version. Länkar är ingen magi. Redovisningen bakom dem är tänkt att uppdateras.

De vill ha bevis på att du har operativ kontroll över tredjepartslicensskyldigheter, inte att du en gång körde npm list på en laptop. Olika frågeformulär använder olika ord (open source-licenssida, lista över tredjepartsmjukvara, OSS-redovisning, materialförteckning för programvara plus licenstext), men avsikten är densamma.

En materialförteckning för programvara (SBOM) räcker ofta inte på egen hand för att uppfylla begäran. En SBOM:s minimikrav, så som de definieras av amerikanska NTIA, kretsar kring komponentidentitet för sårbarhets- och förteckningsändamål, inte granskad licensredovisning. Inköps- och juridikgranskare vill fortfarande ha fullständig licenstext och en bekräftelse på att listan hålls i linje med releaserna.

• Granskad förteckning över tredjeparts- och open source-komponenter för produkten som granskas.
• Fullständig licenstext eller tillförlitliga länkar, inte SPDX-identifierare utan text.
• Attribuering och meddelande där licenserna kräver dem.
• Tydlighet kring vilken produkt, release eller datum redovisningen speglar.
• Ofta en URL, export eller bilaga, beroende på vad deras process anger.
• Allt oftare: Hur du håller redovisningen aktuell när beroenden ändras.

Skicka inte sidfoten om licenser från din marknadsföringssajt om köparen utvärderar din API-produkt, mobilapp eller on-prem-installerare. Varje levererad produkt kan behöva sin egen redovisning, eller ett tydligt avgränsat avsnitt.

Fråga vilket SKU, produktnamn, version eller releasedatum granskningen omfattar. Licensefterlevnad är produktspecifik. Att skicka dokumentation för fel produkt skapar mer omarbete än att inte skicka något alls.

• Vilken produkt eller SKU granskas?
• Vilken version, releasetagg eller datum ska redovisningen spegla?
• Vill de ha en URL, en exportfil, eller båda?
• Gäller granskningen SaaS, installerbar mjukvara, inbyggda system, eller alla leveransmodeller?
• Vem är mottagaren: Inköp, juridik, säkerhet, eller alla tre?

Innan du svarar, bekräfta att redovisningen matchar det bygge kunderna får. Inte main-branchen, inte en utvecklares lokala dator, inte en förteckning ingen har granskat sedan förra kvartalet.

I ett team med flera personer förändras beroenden utan central avisering. En utvecklare uppdaterar en patch-version, en annan lägger till en analys-SDK, ett transitivt paket ändrar licensmetadata i registret. Utan import-, gransknings- och publiceringsgrindar vet ingen att redovisningen är inaktuell förrän en köpare frågar.

Jämför din redovisning med lockfilen, SBOM:en eller exporten från releasen som granskas. Stickprovskontrollera copyleft-komponenter, kommersiella SDK:er och allt märkt som “väntar på granskning”. Om du inte kan verifiera varje rad, åtgärda gapet eller var ärlig om tidsplanen.

• Importera från release-branchen eller CI-artefakten, inte en inaktuell manuell lista.
• Bekräfta att varje komponent inom omfånget har godkänd licenstext.
• Lös oreviderade rader innan du står bakom redovisningen externt.
• Kontrollera att produktnamnet på redovisningen matchar det köparen köper.
• Notera releasetaggen eller datumet förteckningen speglar, och ange det i ditt svar.

Skicka det de bad om (URL, PDF-export, JSON-paket) från samma godkända publiceringsögonblicksbild. Ange vilken produkt och release den omfattar. Beskriv kort hur du uppdaterar redovisningen när beroenden ändras: importera igen, granska igen, publicera igen.

Antyd inte juridiskt godkännande om inte en jurist godkänt det. Säg inte “det här är allt i vår stack för alltid”. Säg vad som granskades, för vilken produkt, från och med vilken release, och att du underhåller redovisningen i takt med att kodbasen ändras.

Om redovisningen inte är klar, ge ett realistiskt datum. Inköp föredrar ärlighet framför en ögonblicksbild som faller vid granskning för att någon mergade fem beroendeuppdateringar sedan du genererade den.

• Inled med produktnamnet och “redovisning av tredjepartslicenser” eller “open source-licensefterlevnad”.
• Ange releasen, taggen eller datumet förteckningen speglar.
• Tillhandahåll URL:en eller bilagan de begärde, från samma granskade data.
• En mening om underhåll: Hur du återpublicerar när beroenden ändras.
• Erbjud exporter om frågeformuläret kräver dem, genererade från samma ögonblicksbild.

Att exportera en lista en gång och återanvända den över flera releaser. Att anta att ingen lagt till paket sedan senaste RFP:n. Att skicka en rå SBOM utan granskad licenstext. Att skicka en trustcenter-PDF om säkerhet som aldrig listar tredjepartslicenser.

Att påstå att SOC 2 eller ISO 27001 täcker open source-licensskyldigheter (det gör de oftast inte). Att behandla “vi använder open source” som redovisning. Vart och ett av dessa faller när köparen jämför ditt svar med det som faktiskt levereras, eller det som levererades två sprintar efter att du svarade.

Lösningen är operativ: Förteckning från byggunderlag, mänsklig granskning före extern delning, uppdatering vid beroendeändring. Inte ett bättre filformat.