Leverandørspørreskjemaer

Hvordan svarer du på lisensspørsmål i sikkerhetsspørreskjemaer?

Svar ut fra en gjennomgått, produktavgrenset oversikt knyttet til en navngitt utgivelse, ikke fra fjorårets regneark. Spørreskjemaer vil ha stabil, oppdatert offentliggjøring. Her er hvordan du svarer uten å overdrive.

Sist oppdatert: 2. juli 2026

Leverandørsikkerhetsspørreskjemaer, SIG Lite, CAIQ, egendefinerte RFP-regneark: De fleste inneholder en seksjon om open source, tredjepartsprogramvare eller lisensetterlevelse. Ordlyden varierer. Den som vurderer, vil vite at du har kontroll på tredjepartslisensforpliktelsene i produktet de evaluerer.

Disse spørsmålene dukker opp midt i en avtaleprosess, ofte besvart av noen som ikke skrev koden. Ingeniørene har kanskje aldri samlet oversikten sentralt. Juridisk har kanskje aldri sett avhengighetslisten. Denne guiden kobler typiske spørsmålstyper til ærlige svar når kodebasen din endres hver sprint.

Denne siden kobler spørreskjemaets spørsmålstyper. Svar-arbeidsflyten, steg for steg, finner du på guide-siden "Lisensforespørsel fra innkjøp".

Hvor lisensspørsmål dukker opp

Spørreskjemaer sprer lisensplikter på tvers av seksjoner. Du kan finne dem under immaterielle rettigheter, praksis for programvareutvikling, forsyningskjede, juridisk etterlevelse eller et eget open source-vedlegg. Søk i PDF-en etter: OSS, open source, tredjepart, lisens, SBOM, komponent, navngivelse, copyleft, GPL.

Bruker du open source-programvare i produktet som vurderes?
Oppgi en liste over open source-komponenter og lisenser.
Oppgi lisenstekster / tredjeparts-notice.
Har du retningslinjer for bruk av open source?
Hvordan følger du opp lisensetterlevelse?
Oppgi SBOM eller komponentoversikt.
Lenke til open source-/lisensoffentliggjøringsside.
Noen copyleft-komponenter (GPL, AGPL, LGPL)?

Hva sjekker vurderere egentlig i et lisensspørreskjema?

De som vurderer, sjekker operativ kontroll, ikke filosofi: Om du kan fremskaffe en gjennomgått, produktavgrenset lisensliste med fullstendig tekst, knyttet til en navngitt utgivelse, som vil holde etter neste driftsetting. Standardiserte spørreskjemaer som Shared Assessments SIG og CSA CAIQ bygger disse forventningene inn i navngitte kontrollrader.

Kan du fremskaffe en gjennomgått liste for dette produktet? Inneholder den fullstendig lisenstekst? Er den knyttet til en utgivelse de kan navngi? Vil den fortsatt være korrekt etter neste driftsetting?

Et ja uten dokumentasjon feiler ved stikkprøvekontroll: De velger fem komponenter og ber om tekst. En PDF med retningslinjer uten oversikt feiler fordi retningslinjer ikke leveres sammen med binærfilen. En SBOM uten gjennomgåtte lisenser feiler fordi identifikatorer ikke er offentliggjøring.

At det finnes en oversikt for det spesifikke produktet, ikke generelle påstander for hele selskapet.
Dokumentasjon på gjennomgang, ikke rå registermetadata.
Fullstendig lisenstekst, ikke sammendrag.
Prosess for oppdateringer, avgjørende når team merger endringer i avhengigheter daglig.
Ærlig omfang: SaaS versus installerbar versus innebygd kan variere.

Spørsmålstype	Ærlig svar	Dokumentasjon å legge ved
Bruker du open source-programvare?	Ja, med en gjennomgått oversikt per produkt	Lenke til den publiserte offentliggjøringsoversikten
Oppgi komponenter og lisenser	Den gjennomgåtte listen for produktet som vurderes	URL, PDF eller JSON-eksport fra ett godkjent øyeblikksbilde
Oppgi lisenstekster / notice	Fullstendig tekst følger med oversikten, ikke bare SPDX-ID-er	Lisenstekst per komponent i oversikten
Noen copyleft (GPL, AGPL, LGPL)?	Besvart ut fra en gjennomsøkt oversikt, aldri hukommelse	Søkeresultater og gjennomgangsstatus per treff
Hvordan følger du opp etterlevelse?	Import, gjennomgang og publisering ved hver utgivelse	Revisjonshistorikk og avviksflagg

De vanligste spørsmålstypene, sammen med det ærlige svaret og dokumentasjonen som holder ved stikkprøvekontroll.

Slik svarer du når oversikten er ufullstendig

Ikke kryss av ja og legg ved bunnteksten fra markedsføringssiden. Hvis du er i ferd med å bygge prosessen, si det: Hva du har i dag, hvilken utgivelse du kan dekke, og når full offentliggjøring vil være klar.

Delvis ærlighet redder avtaler. Overdrivelser feiler i juridisk gjennomgang og ødelegger tillit. Mange kjøpere aksepterer en tidslinje hvis navn fra ingeniørteamet og etterlevelsesteamet følger med.

Beskriv nåsituasjonen rett ut: Delvis oversikt, gjennomgang pågår, ingen publisering ennå.
Navngi produktet og utgivelsen du kan dekke i dag.
Oppgi en dato for full offentliggjøring og hold den.
Ikke kopier fjorårets svar hvis avhengighetene har endret seg.
Eskaler copyleft- eller GPL-spørsmål til juridisk. Avkrysningssvar er risikabelt.

Slik svarer du når oversikten finnes

Send fra det samme godkjente publiseringsøyeblikksbildet: URL, PDF-eksport eller JSON-pakke, avhengig av hva skjemaet tillater. Oppgi produktnavn, utgivelses-tag eller dato og én setning om hvordan du republiserer når avhengigheter endres.

Hvis spørreskjemaet ber om både SBOM og lisensoffentliggjøring, legg ved begge deler fra samme utgivelse, men behandle dem ikke som utskiftbare. SBOM dekker sikkerhetsradene; gjennomgått lisenstekst dekker de juridiske radene.

Match produktet som vurderes, ikke en beslektet SKU.
Inkluder utgivelsen eller datoen dataene gjenspeiler.
Legg ved fullstendig lisenstekst eller vis til gjennomgått offentliggjøring.
Beskriv vedlikeholdet: Import, gjennomgang, publisering ved hver utgivelse.
Navngi en ansvarlig: Kontakt i ingeniørteamet, etterlevelsesteamet eller juridisk.

Hvordan bør du svare på spørsmål om copyleft og høyrisikolisenser?

Svar på copyleft-spørsmål ut fra en gjennomsøkt, gjennomgått oversikt, aldri fra hukommelse eller antakelser, fordi et falskt "nei" er det dyreste svaret du kan gi. Betingelsene i GPL, AGPL, LGPL og SSPL avhenger av hvordan du lenker, distribuerer og tilbyr kildekode, så treff må som regel juridisk tolkes før du signerer.

Spørreskjemaer spør ofte spesifikt om GPL, AGPL, LGPL eller copyleft. Disse krever en nøyaktig oversikt, og ofte juridisk tolkning av hvordan du lenker, distribuerer og tilbyr kildekode.

Ikke svar nei fordi du ikke har søkt. Importer lockfiler, søk etter copyleft-identifikatorer, eskaler treff før du signerer spørreskjemaet. Et falskt nei er verre enn et flagget ja med en tiltaksplan.

Kjør et oversiktssøk etter GPL, AGPL, LGPL, SSPL og egendefinerte lisenser.
Dokumenter hvert treff: Versjon, brukskontekst, gjennomgangsstatus.
Involver juridisk i forpliktelser knyttet til distribusjon og tilbud om kildekode.
Svar på spørreskjemaet med fakta fra den gjennomgåtte oversikten.
Oppdater svarene når copyleft-komponenter legges til eller fjernes.

Spørsmål om retningslinjer versus spørsmål om dokumentasjon

Mange skjemaer ber om PDF-en med open source-retningslinjene dine. Retningslinjer betyr noe i SOC 2- og ISO-sammenheng. De beskriver hensikten. Kjøpere ber likevel om dokumentasjon: Den faktiske listen for produktet.

Svar på spørsmål om retningslinjer med retningslinjene dine. Svar på spørsmål om oversikten med den gjennomgåtte oversikten din, ikke bare retningslinjene. Hvis retningslinjene sier "vi overholder lisensene" men du ikke har noen publisert oversikt, feiler dokumentasjonsspørsmålet uansett.

Slik holder du svarene korrekte etter innsending

Svar på spørreskjemaer har en halveringstid. Uken etter du sender inn, kan noen merge en stor oppdatering av en avhengighet. Den signerte attestasjonen din ligger fortsatt i kjøperens fil, nå utdatert.

Operative team importerer på nytt ved utgivelse, gjennomgår endringer på nytt, republiserer offentliggjøringen og varsler nøkkelkunder ved vesentlige endringer i lisensstatus. Statiske svar uten en vedlikeholdssløyfe er en risiko ved fornyelser og revisjoner.

Det raskeste ærlige svaret

SourceTrust gjør denne sløyfen til standarden: Importer lockfilen, gjennomgå hver lisens én gang, publiser en produktavgrenset attestasjonsside med fullstendig lisenstekst og republiser ved hver utgivelse. Neste spørreskjema får en URL i stedet for panikk.