Um cliente que se enquadra na obrigação de diligência da NIS2 deve ser capaz de demonstrar que conhece os riscos em sua própria cadeia. O software que você constrói para esse cliente faz parte dessa cadeia. Na prática, isso se traduz em requisitos contratuais que afetam duas coisas simultaneamente: o produto que você entrega e a forma como você o produz. Ambos aparecem no texto do acordo, frequentemente como anexo ao contrato de compra.
O núcleo é simples de lembrar: o cliente não pergunta apenas se o software funciona, mas também se você pode demonstrar como permanece seguro, quem pode acessá-lo e o que acontece se algo der errado. Esta é uma mudança em relação ao passado, quando a funcionalidade e o prazo de entrega eram frequentemente os únicos pontos de discussão.
Requisitos para o produto que você entrega
O requisito contratual mais comum refere-se à composição do próprio software. Os clientes solicitam cada vez mais uma lista das bibliotecas e componentes de código aberto utilizados, a chamada lista de componentes de software. O motivo é que uma vulnerabilidade em um componente subjacente é tão importante quanto um erro no seu próprio código, e um cliente deseja poder compreender esses riscos sem ler o código-fonte.
Além disso, há requisitos sobre como as vulnerabilidades no software são identificadas e remediadas, e dentro de qual prazo. Isso pode incluir verificações automatizadas de fraquezas conhecidas, um procedimento fixo para patches ou a questão de quem pode relatar uma vulnerabilidade e para onde ela deve ser encaminhada. Para software existente, às vezes também se pergunta pelo período de suporte: por quanto tempo uma versão continua a receber atualizações de segurança.
Requisitos para sua própria linha de desenvolvimento
Um segundo grupo de requisitos não se concentra no produto, mas no processo de sua fabricação: a linha de desenvolvimento. Pense em quem tem acesso ao código-fonte e ao ambiente no qual a construção e os testes ocorrem, como as alterações são revisadas antes de serem lançadas, e se há separação entre um ambiente de teste, um ambiente de aceitação e um ambiente de produção. O uso de autenticação multifator para desenvolvedores que têm acesso ao código-fonte ou sistemas de construção também aparece em contratos, assim como a questão de quem gerencia as chaves e as credenciais de acesso associadas à implantação de software.
Alguns clientes também perguntam sobre a origem do software que você usa para construir: o compilador, as ferramentas de construção, os pacotes que são obtidos durante a construção. Isso se alinha com uma consciência mais ampla de que um ataque não pode apenas vir através do produto final, mas também através da fábrica em que é fabricado.
Por que exatamente esses requisitos são formulados dessa forma
A obrigação de diligência que está na base de tudo isso obriga uma organização obrigada a avaliar e gerenciar riscos em sua própria cadeia. Como exatamente isso é implementado varia de país para país de acordo com a lei nacional baseada na diretiva europeia, e por setor em que o cliente opera. O que é um requisito obrigatório em um contrato é ainda uma questão facultativa em outro contrato. Se você quer saber como essa obrigação é estruturada em seu núcleo, leia isso em a explicação por obrigação em nossa base de conhecimento.
Importante lembrar: é o cliente que estabelece esses requisitos porque ele próprio está sob supervisão, não porque empresas de software, como tal, se enquadram na diretiva. Se e com que rigor isso será aplicado no seu caso depende do setor e do tamanho daquele cliente específico. Para sua situação específica, o texto da lei nacional ou o parecer de um jurista é o ponto de partida apropriado, não uma avaliação geral.
O que isso significa para sua preparação
A maioria destes requisitos pode ser respondida com algum trabalho prévio, e a resposta que você prepara uma vez pode ser reutilizada repetidamente com cada novo cliente. Uma lista dos componentes utilizados, uma breve descrição do seu controle de acesso e um procedimento fixo para correções não são documentos que você precise reinventar para cada contrato.
Quer ver primeiro se e como isso afeta sua empresa? a verificação que em algumas perguntas determina sua posição na cadeia de suprimentos oferece uma primeira orientação, sem que você precise de uma conta. Para as perguntas que os clientes colocam especificamente e a forma como ajudamos, leia mais em a página com perguntas frequentes ou veja como fundamentamos as informações na plataforma.
A base de conhecimento gratuita e a verificação lhe dão uma primeira visão sem compromissos. Se você quiser converter os requisitos contratuais em um dossier em andamento com provas e respostas prontas para questionários, esse é o momento de verificar o que uma assinatura adiciona.