SOC 2 · ISO 27001

Passar no SOC 2 ou na ISO 27001 cobre a divulgação de licenças?

Não. As certificações de segurança e a divulgação de licenças de terceiros respondem a perguntas diferentes, e ambas podem ser verdade ao mesmo tempo: pode ter um certificado válido e continuar a dever um registo de licenças revisto, ao nível do produto.

Última atualização: 2 de julho de 2026

01Para onde esta página aponta

Os pontos de falha esquecidos

Estes surgem em diligências e auditorias: as obrigações existem, a prova está em falta, e o artefacto que os compradores esperam está ausente.

As licenças open source são obrigações legais, não preferências
A MIT, a Apache, a GPL, a LGPL, e os acordos de SDK proprietários impõem condições: aviso, atribuição, copyleft, regras de distribuição. Não as cumprir é uma violação de licença, não uma lacuna de estilo. Os programas de SOC 2 e ISO não fazem essas obrigações desaparecer; perguntam se os seus controlos as detetam antes do lançamento.
ISO 27001: a propriedade intelectual é explícita
O controlo 5.32 do Anexo A exige procedimentos para cumprir os direitos de propriedade intelectual, incluindo licenças de software. Os auditores esperam prova, não apenas um PDF de política. Não incluir os textos de licença exigidos, onde as licenças o exigem, é simultaneamente uma violação de PI e uma falha de prova do SGSI, quando os seus controlos afirmam que o software de terceiros é gerido.
SOC 2: sem controlo de página de licenças, mas os auditores seguem pistas
Os Trust Services Criteria não mencionam “publicar todas as licenças num site”. Ainda assim, os auditores verificam a conformidade legal e a gestão de alterações. Lacunas sistémicas (avisos em falta, inventário não revisto, ausência de registo ao nível do produto) surgem como deficiências de controlo quando as amostras não correspondem à política.
O âmbito da certificação não é o âmbito do produto
Um certificado SOC 2 Type II ou ISO cobre o seu sistema e período, não automaticamente todas as dependências em todos os SKUs. Os compradores fazem perguntas específicas ao produto de qualquer forma. A sua certificação ajuda; não substitui a divulgação de licenças de terceiros para o produto em contrato.
Os conjuntos de provas ficam desatualizados entre auditorias
As equipas submetem à auditoria de vigilância da ISO a mesma folha de cálculo de OSS que submeteram no ano passado, enquanto a engenharia lançou doze versões. Os auditores de vigilância fazem amostragem de sistemas em produção. A discrepância entre a prova e a produção é um achado maior clássico, e a mesma discrepância acaba com renovações de compras.
A verificação de segurança não é revisão de licenças
Os scanners de vulnerabilidades e as ferramentas de SBOM identificam componentes e, por vezes, campos de licença. Não anexam texto integral de licença, não aprovam o risco de copyleft, nem publicam divulgação pronta para compradores. Equiparar o resultado das ferramentas de AppSec à conformidade de licenças cria falsa confiança, tanto na prova de SOC como nas respostas a RFPs.
As surpresas de copyleft também prejudicam organizações certificadas
GPL ou AGPL num produto lançado, sem oferta de código-fonte ou revisão de conformidade, é um problema legal e de auditoria, independentemente da certificação ISO 27001. Ser descoberto durante a diligência do comprador, e não numa revisão interna, é o caminho dispendioso.
Os compradores querem prova ao lado do seu relatório
Os clientes enterprise pedem o seu relatório SOC e um registo de licenças de terceiros para o produto: inventário, texto integral, processo de manutenção. O trust center cobre a postura de segurança; a divulgação de licenças cobre as obrigações de PI na base de código. Ambos aparecem em revisões de fornecedores maduras.

O SOC 2 e a ISO 27001 provam que gere um sistema de segurança e gestão: controlo de acessos, gestão de alterações, tratamento de risco, supervisão de fornecedores. Os auditores examinam o desenho dos controlos e a sua eficácia operacional. Por predefinição, nenhuma das duas certificações inventaria todas as obrigações de licenças open source em todos os produtos lançados.

Os compradores tratam a certificação como um requisito mínimo, e depois pedem separadamente divulgação de licenças de terceiros (texto integral, atribuição, inventário delimitado ao produto). Passar no SOC 2 não responde a “que componentes GPL estão no build que licenciámos”.

O que é que a ISO 27001 realmente exige sobre licenças open source?

A ISO/IEC 27001:2022 exige que opere procedimentos que garantam a conformidade com direitos de propriedade intelectual, incluindo os termos de licenças de software, ao abrigo do controlo 5.32 do Anexo A. Não prescreve uma página pública de licenças, mas um auditor pode pedir prova de que os termos de licença de terceiros no que lança são realmente cumpridos.

Um documento de controlo que diga “respeitamos as licenças OSS”, sem prova (inventário revisto, texto integral, alinhamento com os lançamentos), é um achado de auditoria à espera de acontecer. Especialmente quando os testes por amostragem encontram pacotes em produção que não estão em nenhuma lista.

Política para licenças aceitáveis e processos de aprovação.
Prova de que os produtos lançados cumprem os termos de licenças de terceiros.
Registos de revisão, não apenas resultados de verificações de deteção.
Alinhamento entre o que o SGSI afirma e o que a engenharia lança.
Tratamento de mudanças de licença quando as dependências são atualizadas.

O que é que os auditores de SOC 2 procuram, na prática, em conformidade de licenças?

Os auditores de SOC 2 não exigem uma página pública de licenças; verificam se os seus controlos dos Trust Services Criteria da AICPA para conformidade legal, gestão de fornecedores, e controlo de alterações, realmente detetam as obrigações de licenças de terceiros. Uma higiene de OSS descuidada aparece aí como prova fraca em relação a critérios que já afirma cumprir.

Os auditores fazem amostragem dos sistemas. Perguntam como sabe que o software de terceiros está corretamente licenciado. “Corremos o npm audit” não é uma resposta. Nem um selo de certificação no seu site, sem um inventário ao nível do produto.

Controlo	O que os auditores esperam	Prova que o satisfaz
ISO 27001 A 5.32	Procedimentos que garantam a conformidade com PI e licenças de software	Inventário revisto com texto integral de licença por produto lançado
SOC 2 CC2.2	Governação e supervisão das obrigações de conformidade	Registos de revisão que mostram quem aprovou que componentes, e quando
SOC 2 CC8.1	As alterações de dependências passam pela gestão de alterações	Registos de deriva que associam alterações de lockfile a novas revisões
SOC 2 CC9.2	O risco de software de terceiros e fornecedores é gerido	Registo de divulgação delimitado ao produto, atualizado à data do lançamento

Os achados de auditoria surgem quando existe uma política, mas não existe prova operacional.

Porque é que as certificações e a diligência dos compradores divergem

O âmbito da certificação é o ambiente de controlo: muitas vezes um trust center, um período, uma fronteira de sistema. O âmbito da diligência do comprador é o produto que compra (este SKU, este lançamento, estas obrigações hoje).

O seu relatório SOC 2 cobre como gere as alterações. A equipa jurídica deles pede o texto da licença MIT para a libfoo 2.4.1 no instalador que implementam. Perguntas diferentes; ambas precisam de respostas honestas.

Porque é que o inventário fica desatualizado em organizações certificadas?

O inventário fica desatualizado porque a certificação é periódica, enquanto as dependências mudam continuamente. O relatório Open Source Security and Risk Analysis da Black Duck encontrou código open source em 96% das bases de código auditadas, e que a maioria continha componentes com conflitos de licença ou sem licença identificável, pelo que um único conjunto de provas anual não consegue acompanhar o que cada lançamento realmente distribui.

As empresas certificadas integram atualizações de dependências entre ciclos de auditoria. Os programadores adicionam pacotes sem atualizar a folha de cálculo do conjunto de provas de ISO do ano passado. O certificado é válido; o inventário está desatualizado.

A conformidade operacional de licenças significa reimportar a cada lançamento, rever de novo, republicar. O mesmo ciclo de manutenção que a CRA e as compras exigem, dentro de um SGSI que já afirma que gere o risco de terceiros.

Prova que tanto os auditores como os compradores aceitam

Inventário de terceiros revisto, associado a tags de lançamento. Texto integral de licença guardado com cada componente aprovado. Snapshot de publicação ou exportação, com data e aprovador. Deteção de deriva quando os lockfiles mudam. Divulgação pública ou voltada para o cliente, quando os contratos o exigirem.

O formato varia (URL, exportação em PDF, pacote JSON). A prova é o registo revisto e o processo, não o tipo de ficheiro.

Importação a partir de lockfiles ou SBOMs, por lançamento.
Revisão humana antes de aprovar, especialmente para copyleft.
Registo de auditoria: quem aprovou o quê, e quando.
Exportações anexadas a provas de ISO ou a pedidos de auditores de SOC.
Repetição a cada alteração de dependências, não apenas anual.

Padrões de falha comuns em auditorias e negócios

Política sem inventário. Inventário sem texto integral de licença. Texto integral recolhido uma vez e nunca atualizado. Verificação de segurança confundida com revisão de licenças. Trust center que menciona privacidade e segurança, mas nada sobre OSS. GPL em produção descoberta pela verificação do comprador, não pela sua.

Cada padrão cria achados de ISO, exceções de SOC, ou atrasos em negócios. A solução é infraestrutura operacional para obrigações de licenças, em paralelo com os programas de certificação (não substituída por eles).

Como as equipas associam controlos ao trabalho de licenças

Associe o controlo 5.32 e os critérios de gestão de alterações do SOC a passos concretos: importar, rever, publicar, verificar deriva. Nomeie responsáveis na engenharia e na conformidade. Anexe exportações de divulgação às pastas de provas do SGSI. Faça amostragem de produtos durante a auditoria interna, da mesma forma que os auditores externos o farão.

A certificação prova a maturidade do processo. Os registos de licenças ao nível do produto provam que cumpre as obrigações no software que vende. Os compradores e os testes por amostragem da ISO esperam cada vez mais ver ambos juntos.

Fontes

Como o SourceTrust apoia prova respaldada por certificação

As certificações provam que tem um sistema de gestão. Os registos de licenças ao nível do produto provam o que foi lançado: revisto, com texto integral, atualizado quando as dependências mudam.

O SourceTrust importa ficheiros de pacotes e SBOMs, exige revisão antes da publicação, e produz um registo de divulgação mantido por produto, mais exportações para pastas de provas de ISO e questionários de compradores. As verificações de deriva alinham os registos de licenças com as mesmas alterações de dependências que os seus controlos de gestão de alterações já acompanham para o SOC 2.

Ver como a plataforma funciona

Importe a partir de repositórios, manifestos, e SBOMs. Cada linha é uma licença a satisfazer
Portões de revisão e publicação. Prova que os auditores podem amostrar em relação à produção
Registo de divulgação por produto. O que os compradores pedem para além do relatório SOC
Alertas de deriva quando as dependências ou licenças mudam entre ciclos de auditoria

O SourceTrust é infraestrutura de conformidade, não aconselhamento jurídico, e não substitui a sua empresa de auditoria ISO ou SOC. Ajuda a operacionalizar as obrigações de licenças; o seu advogado e os seus auditores continuam a ser a autoridade sobre o desenho dos seus controlos.