SOC 2 · ISO 27001

Dækker en bestået SOC 2- eller ISO 27001-certificering licensoplysning?

Nej. Sikkerhedscertificeringer og oplysning om tredjepartslicenser besvarer to forskellige spørgsmål, og begge dele kan være sande på samme tid: I kan sagtens have et gyldigt certifikat og stadig mangle en gennemgået licensregistrering på produktniveau.

Sidst opdateret: 2. juli 2026

01Hvad denne side peger på

De oversete svage punkter

Disse dukker op i due diligence og audits: Forpligtelserne findes, beviset mangler, og det artefakt, købere forventer, er fraværende.

Open source-licenser er juridiske forpligtelser, ikke præferencer
MIT, Apache, GPL, LGPL og proprietære SDK-aftaler pålægger betingelser: Notice, kildeangivelse, copyleft, distributionsregler. At mangle dem er licensbrud, ikke en stilistisk mangel. SOC 2- og ISO-programmer får ikke de forpligtelser til at forsvinde. De spørger, om jeres kontroller fanger dem, før levering.
ISO 27001: Immaterialret er eksplicit
Bilag A 5.32 kræver procedurer til overholdelse af immaterialrettigheder, herunder softwarelicenser. Revisorer forventer bevis, ikke kun en politik-PDF. At undlade at inkludere påkrævet licenstekst, hvor licenser kræver det, er både en IP-krænkelse og en ISMS-bevissvigt, når jeres kontroller påstår, at tredjepartssoftware håndteres.
SOC 2: Ingen kontrol for licensside, men revisorer følger spor
Trust Services Criteria nævner ikke “udgiv alle licenser på et website.” Revisorer sporer stadig juridisk compliance og change management. Systemiske huller (manglende notices, ikke-gennemgået oversigt, ingen registrering på produktniveau) viser sig som kontrolmangler, når stikprøver ikke matcher politikken.
Certificeringens omfang er ikke produktets omfang
Et SOC 2 Type II- eller ISO-certifikat dækker jeres system og periode, ikke automatisk hver eneste afhængighed i hvert eneste SKU. Købere stiller alligevel produktspecifikke spørgsmål. Jeres certificering hjælper. Den erstatter ikke oplysning om tredjepartslicenser for det produkt, kontrakten gælder.
Bevispakker bliver forældede mellem audits
Teams indsender det samme OSS-regneark til ISO-overvågningsaudit, som de indsendte sidste år, mens engineering har sendt tolv udgivelser i produktion. Overvågningsrevisorer stikprøvetester aktive systemer. Uoverensstemmelse mellem bevis og produktion er et klassisk alvorligt fund, og den samme uoverensstemmelse dræber fornyelser hos indkøb.
Sikkerhedsscanning er ikke licensgennemgang
Sårbarhedsscannere og SBOM-værktøjer identificerer komponenter og nogle gange licensfelter. De vedhæfter ikke fuld licenstekst, godkender ikke copyleft-risiko og udgiver ikke køberklar oplysning. At sætte lighedstegn mellem AppSec-værktøjers output og licens-compliance skaber falsk tryghed, både i SOC-bevis og RFP-svar.
Copyleft-overraskelser rammer også certificerede organisationer
GPL eller AGPL i et produkt i produktion uden kildekodetilbud eller compliance-gennemgang er et juridisk problem og et auditproblem, uanset ISO 27001-certificering. At det opdages under køberens due diligence, ikke ved intern gennemgang, er den dyre vej.
Købere vil have bevis ved siden af jeres rapport
Enterprise-kunder beder om jeres SOC-rapport og en tredjepartslicensregistrering for produktet: Oversigt, fuld tekst, vedligeholdelsesproces. Trust centeret dækker sikkerhedsstatus. Licensoplysning dækker IP-forpligtelser i kodebasen. Begge dele optræder i modne leverandørgennemgange.

SOC 2 og ISO 27001 beviser, at I driver et sikkerheds- og ledelsessystem: Adgangsstyring, change management, risikobehandling, leverandørtilsyn. Revisorer undersøger kontrollernes udformning og operationelle effektivitet. Ingen af certificeringerne laver som standard en oversigt over alle open source-licensforpligtelser i alle produkter i produktion.

Købere betragter certificering som en forudsætning og beder derefter separat om oplysning om tredjepartslicenser (fuld tekst, kildeangivelse, produktafgrænset oversigt). At bestå SOC 2 besvarer ikke “hvilke GPL-komponenter er der i den build, vi har fået licens til.”

Hvad kræver ISO 27001 egentlig om open source-licenser?

ISO/IEC 27001:2022 kræver, at I har procedurer, der sikrer overholdelse af immaterialrettigheder, herunder softwarelicensvilkår, under Bilag A-kontrol 5.32. Den foreskriver ikke en offentlig licensside, men en revisor kan bede om bevis for, at tredjepartslicensvilkårene i det, I sender i produktion, rent faktisk er opfyldt.

Et kontroldokument, der siger “vi respekterer OSS-licenser” uden bevis (gennemgået oversigt, fuld tekst, overensstemmelse med udgivelser), er et fund, der bare venter på at ske. Særligt når stikprøvetests finder pakker i produktion, der ikke står på nogen liste.

Politik for acceptable licenser og godkendelsesprocesser.
Bevis for, at produkter i produktion overholder tredjepartslicensvilkår.
Registreringer af gennemgang, ikke bare output fra et opdagelsesscan.
Overensstemmelse mellem det, ISMS'et påstår, og det, engineering sender i produktion.
Håndtering af licensændringer, når afhængigheder opdateres.

Hvad kigger SOC 2-revisorer efter på licens-compliance i praksis?

SOC 2-revisorer kræver ikke en offentlig licensside. De sporer, om jeres AICPA Trust Services Criteria-kontroller for juridisk compliance, leverandørstyring og change control rent faktisk fanger tredjepartslicensforpligtelser. Sjusket OSS-hygiejne viser sig der som svagt bevis mod kriterier, I allerede påstår at opfylde.

Revisorer stikprøvetester systemer. De spørger, hvordan I ved, at tredjepartssoftware er korrekt licenseret. “Vi kører npm audit” er ikke et svar. Det er et certificeringsmærke på jeres website heller ikke, uden en oversigt på produktniveau.

Kontrol	Hvad revisorer forventer	Bevis, der opfylder den
ISO 27001 A 5.32	Procedurer, der sikrer overholdelse af IP og softwarelicenser	Gennemgået oversigt med fuld licenstekst pr. produkt i produktion
SOC 2 CC2.2	Governance og tilsyn med compliance-forpligtelser	Gennemgangslogs, der viser, hvem der godkendte hvilke komponenter, hvornår
SOC 2 CC8.1	Ændringer i afhængigheder går gennem change management	Afvigelsesregistreringer, der knytter ændringer i lockfilen til gen-gennemgang
SOC 2 CC9.2	Risiko ved tredjeparts- og leverandørsoftware håndteres	Produktafgrænset oplysningsregistrering, ajour pr. udgivelsen

Fund opstår, når en politik findes, men operationelt bevis ikke gør.

Hvorfor certificeringer og køberes due diligence adskiller sig

Certificeringens omfang er kontrolmiljøet: Ofte et trust center, en periode, en systemgrænse. Køberens due diligence-omfang er det produkt, de køber (dette SKU, denne udgivelse, disse forpligtelser i dag).

Jeres SOC 2-rapport dækker, hvordan I håndterer ændringer. Deres jurateam beder om MIT-licensteksten for libfoo 2.4.1 i den installer, de udruller. Forskellige spørgsmål. Begge kræver ærlige svar.

Hvorfor bliver oversigten forældet i certificerede organisationer?

Oversigten bliver forældet, fordi certificering er periodisk, mens afhængigheder ændrer sig løbende. Black Ducks Open Source Security and Risk Analysis-rapport fandt open source-kode i 96 procent af de kodebaser, den reviderede, og at de fleste indeholdt komponenter med licenskonflikter eller ingen identificerbar licens, så én årlig bevispakke kan ikke følge med i, hvad hver udgivelse rent faktisk leverer.

Certificerede virksomheder merger opdateringer af afhængigheder mellem revisionscyklusser. Udviklere tilføjer pakker uden at opdatere regnearket fra sidste års ISO-bevispakke. Certifikatet er gyldigt. Oversigten er forældet.

Operationel licens-compliance betyder genimport ved udgivelse, gen-gennemgang, genudgivelse. Den samme vedligeholdelsesløkke, CRA og indkøb kræver, inde i et ISMS, der allerede påstår, at I håndterer tredjepartsrisiko.

Bevis, både revisorer og købere accepterer

Gennemgået tredjepartsoversigt knyttet til release-tags. Fuld licenstekst gemt sammen med hver godkendt komponent. Udgivelses- eller eksport-snapshot med dato og godkender. Afvigelsesdetektion, når lockfiles ændrer sig. Offentlig eller kunderettet oplysning, når kontrakter kræver det.

Formatet varierer (URL, PDF-eksport, JSON-pakke). Beviset er den gennemgåede registrering og processen, ikke filtypen.

Import fra lockfiles eller SBOM'er pr. udgivelse.
Menneskelig gennemgang før godkendelse, især ved copyleft.
Revisionsspor: Hvem godkendte hvad, og hvornår.
Eksporter vedhæftet til ISO-bevis eller SOC-revisoranmodninger.
Kør igen ved ændringer i afhængigheder, ikke kun årligt.

Almindelige fejlmønstre i audits og aftaler

Politik uden oversigt. Oversigt uden fuld licenstekst. Fuld tekst indsamlet én gang og aldrig opdateret. Sikkerhedsscan forvekslet med licensgennemgang. Trust center, der nævner privatliv og sikkerhed, men tier om OSS. GPL i produktion opdaget af køberens scan, ikke jeres eget.

Hvert mønster skaber ISO-fund, SOC-undtagelser eller forsinkede aftaler. Løsningen er operationel infrastruktur til licensforpligtelser, parallelt med (ikke erstattet af) certificeringsprogrammer.

Sådan kortlægger teams kontroller til licensarbejde

Kortlæg kontrol 5.32 og SOC's change-management-kriterier til konkrete trin: Import, gennemgang, udgivelse, afvigelsestjek. Navngiv ejere i engineering og compliance. Vedhæft oplysningseksporter til ISMS-bevismapper. Stikprøvetest produkter under den interne audit, ligesom eksterne revisorer vil gøre.

Certificering beviser modenhed i processen. Licensregistreringer på produktniveau beviser, at I opfylder forpligtelserne i den software, I sælger. Købere og ISO-stikprøvetests forventer i stigende grad begge dele samtidig.

Kilder

Sådan understøtter SourceTrust certificeringsunderbygget bevis

Certificeringer beviser, at I har et ledelsessystem. Licensregistreringer på produktniveau beviser, hvad der blev leveret: Gennemgået, med fuld tekst, opdateret når afhængigheder ændrer sig.

SourceTrust importerer pakkefiler og SBOM'er, kræver gennemgang før udgivelse, og producerer en vedligeholdt oplysningsregistrering pr. produkt plus eksporter til ISO-bevismapper og køberes spørgeskemaer. Afvigelsestjek holder licensregistreringer på linje med de samme ændringer i afhængigheder, som jeres change-management-kontroller allerede følger for SOC 2.

Se hvordan platformen fungerer

Importér fra repos, manifester og SBOM'er. Hver række er en licens, der skal opfyldes
Gennemgangs- og publish-gates. Bevis, revisorer kan stikprøvetjekke mod produktionen
Oplysningsregistrering pr. produkt. Det, købere beder om ud over SOC-rapporten
Afvigelsesvarsler, når afhængigheder eller licenser ændrer sig mellem revisionscyklusser

SourceTrust er compliance-infrastruktur, ikke juridisk rådgivning og ikke en erstatning for jeres ISO- eller SOC-revisionsfirma. Det hjælper jer med at operationalisere licensforpligtelser. Jeres advokat og revisorer forbliver autoriteten på jeres kontroldesign.