Como empresa de software, você recebe cada vez mais frequentemente um questionário de segurança de um cliente sujeito à Lei de Cibersegurança. O mesmo dever de cuidado que obriga seu cliente em relação a você também o obriga a algo: avaliar quais de seus próprios fornecedores têm influência na segurança do que você constrói e entrega. Uma política de fornecedores é a forma de tornar essa avaliação repetível, em vez de reinventar a cada vez em quem você realmente confia.
Resposta curta: você começa com um inventário de quem está em seu pipeline de desenvolvimento e em seu software entregue, você classifica esses fornecedores de acordo com o risco que representam, e você documenta por categoria quais requisitos você impõe e como você verifica isso. Esse inventário e essa classificação juntos formam a política de fornecedores.
Dois tipos de fornecedores, um ponto cego
No desenvolvimento de software, duas cadeias se entrelaçam, e isso torna uma política de fornecedores mais complexa do que em uma empresa que apenas adquire bens físicos.
A primeira cadeia é seu pipeline de desenvolvimento: o gerenciador de código-fonte, o pipeline de CI/CD, o ambiente em nuvem em que você constrói, as ferramentas para teste e implementação. Um ponto fraco ali afeta em primeiro lugar suas próprias operações.
A segunda cadeia é o que entra em seu produto: bibliotecas de código aberto, APIs de terceiros, componentes adquiridos. Um ponto fraco ali não afeta apenas você, mas também cada cliente que usa seu software. Essa distinção é precisamente onde muitas políticas de fornecedores ficam aquém: a atenção vai para a primeira cadeia porque é visível no trabalho diário, enquanto a segunda cadeia geralmente só se torna visível quando algo dá errado.
Inventariar: comece com o que já está em execução
Uma política de fornecedores não começa com um modelo, mas com uma lista. Para desenvolvimento de software, isso significa no mínimo: quais provedores de nuvem você usa, quais gerenciadores de pacotes e registros seu processo de compilação obtém, quais APIs externas seu produto chama, e quais dessas partes podem acessar código, segredos ou dados de produção.
Para cada fornecedor, a pergunta não é apenas o que eles fazem, mas o que acontece se eles saírem do ar ou forem comprometidos. Um gerenciador de pacotes de onde centenas de dependências vêm pesa diferentemente de um pacote de faturamento que funciona independentemente do pipeline de desenvolvimento.
Classificação de risco: nem todo fornecedor merece a mesma atenção
Após o inventário vem uma classificação, geralmente em dois ou três níveis. Fornecedores com acesso a código-fonte, segredos ou ambientes de produção exigem os requisitos mais rigorosos: autenticação forte, logging, um ponto de contato fixo para incidentes. Fornecedores que trabalham apenas indiretamente, como uma ferramenta de planejamento de projetos, exigem menos.
A diretiva e a lei nacional não prescrevem uma classificação fixa; os supervisores observam se as medidas são proporcionais ao risco. Isso significa que a classificação que você escolher deve ser explicável: por que esse fornecedor está na categoria pesada e aquele outro não.
O que você pergunta e o que você mesmo já responde
Uma política de fornecedores funciona em duas direções. Para o exterior, você a usa para fazer perguntas a seus próprios fornecedores: como eles lidam com vulnerabilidades, eles têm um processo de verificação múltipla, com que rapidez eles reportam um incidente a você. Para o interior, ela forma a base para o que você mesmo responde aos questionários de seus clientes, pois um cliente que o avalia frequentemente quer saber se você tem sua própria cadeia mapeada.
Os dois aspetos estão relacionados: uma política de fornecedores que você escreve apenas para si mesmo geralmente não se alinha com as perguntas que recebe de clientes. Quem estabelece a política desde o início com atenção ao que um cliente solicita não precisa rescrevê-la mais tarde.
Documentar: da política à prova
Uma política que existe apenas num documento de texto é difícil de fundamentar no momento em que um cliente ou autoridade reguladora a questiona. Uma alternativa mais prática é um registo dinâmico: por fornecedor a categoria de risco, a última avaliação, a prova documental como uma declaração, um certificado ou uma resposta ao seu próprio questionário, e quem na sua organização monitoriza esse fornecedor.
Um registo deste tipo não precisa ser abrangente para ser útil. Para uma empresa de software com uns quantos fornecedores críticos, uma tabela com algumas colunas é frequentemente suficiente, desde que seja mantida actualizada quando um fornecedor muda ou um contrato é renovado.
Gostaria de saber primeiro se a sua organização está sujeita à obrigação de devido cuidado, ou é apenas afectada através dos seus clientes? faça a verificação gratuita com algumas perguntas e leia em a página com todos os tópicos como a avaliação de fornecedores se relaciona com as outras obrigações. Curioso sobre a origem das informações nesta plataforma e quão actuais são? Isso está explicado em a página sobre como funciona. Quem quiser converter o registo de fornecedores num dossier com provas documentais e proprietários, encontra em a página com subscrições o que é necessário para isso.