Riscos e boas práticas de segurança da cadeia de suprimentos de software

Em vez de criar aplicativos apenas com código próprio, as equipes de desenvolvimento modernas combinam código proprietário (o “segredo do negócio” da empresa) com muitos componentes de terceiros. Esses recursos — muitos dos quais são de código aberto — são valiosos para os desenvolvedores: economizam tempo e impulsionam inovações melhores. Mas, junto com as possibilidades quase ilimitadas do software de código aberto, surge um novo nível de risco: a segurança da cadeia de suprimentos de software.

Quais são os riscos de segurança na cadeia de suprimentos?

Mas por que as organizações de hoje precisam acompanhar de perto a cadeia de suprimentos de software? O mundo do desenvolvimento de software está sempre mudando. Todos os dias, os desenvolvedores da sua organização usam inúmeros componentes em seus aplicativos para não terem que reinventar a roda. Cada componente tem dependências, e essas dependências também têm dependências. Sua empresa corre riscos se algum elemento dessa cadeia contiver vulnerabilidades críticas conhecidas.

O incidente de segurança do SolarWinds Orion é um exemplo de como um risco cibernético na cadeia de suprimentos pode ter consequências duradouras.

Veja algumas ameaças comuns à cadeia de suprimentos:

• Pacotes ou contêineres de código aberto vulneráveis. Por exemplo, um pacote npm médio traz 79 pacotes de terceiros e 39 mantenedores para a sua cadeia de suprimentos de software. Ao baixar esse único componente, você introduz toda uma superfície de ataque.

• Typosquatting ou falsificação de marca. Essa técnica de ataque consiste em agentes mal-intencionados publicarem pacotes maliciosos em um registro, usando nomes parecidos com os de pacotes legítimos. Quem não verifica a segurança dos pacotes de código aberto corre o risco de baixar um desses recursos maliciosos por engano.

• Gerenciamento de dados. Muitas organizações simplesmente não sabem o que há em suas cadeias de suprimentos de software. Seus inventários de componentes de software (SBOMs) ficam desatualizados rapidamente porque não são atualizados quando um desenvolvedor adiciona um pacote ou contêiner de código aberto, novo ou atualizado.

• Direitos de acesso. As organizações concedem acesso excessivo a fornecedores ou componentes de terceiros. Assim, se esse terceiro for comprometido, ele poderá se tornar o elo mais fraco da cadeia de suprimentos.

• Erro humano ou negligência. Erros acontecem quando as equipes não consideram as boas práticas de segurança da cadeia de suprimentos de software. Um desenvolvedor pode baixar um pacote malicioso ou permitir que um fornecedor terceirizado acesse informações confidenciais. Há muitas maneiras de o erro humano colocar todo o ciclo de vida de desenvolvimento de software (SDLC) em risco.

Saiba mais sobre segurança da cadeia de suprimentos em nosso whitepaper recente sobre o tema.

Por que apenas criar um SBOM não é suficiente

Embora muitas organizações entendam os riscos do uso de componentes de terceiros, elas costumam adotar uma abordagem incompleta para proteger suas cadeias de suprimentos, o que pode levar a ataques. É comum presumir que criar um SBOM basta para proteger uma cadeia de suprimentos de software. É compreensível: hoje, os SBOMs estão no centro de muitas discussões sobre segurança (e também foram destacados em uma ordem executiva recente).

Mas, na verdade, um SBOM é basicamente uma “lista de ingredientes”. Assim como acontece com alimentos embalados, muitas vezes ele contém itens tão confusos e desconhecidos quanto o “polissorbato 80”. Você talvez reconheça o ingrediente, mas ele faz bem ou mal?

Para levar a analogia adiante, um ingrediente considerado inofensivo no passado pode se tornar algo a evitar no futuro (como o corante vermelho nº 5). O mesmo vale para os SBOMs. O fato de seu SBOM estar correto hoje não significa que continuará assim amanhã. Para evitar riscos de forma eficaz, sua organização precisa adotar outras práticas contínuas de segurança da cadeia de suprimentos.

Boas práticas de segurança da cadeia de suprimentos para sua organização

As equipes de desenvolvimento devem seguir cinco boas práticas de segurança da cadeia de suprimentos: analisar pacotes e contêineres de código aberto, usar os pacotes corretos (e evitar os maliciosos), manter um SBOM preciso, implementar políticas de RBAC e priorizar a capacitação e o treinamento da equipe.

Vamos analisar cada uma dessas práticas:

1. Analise seus pacotes e contêineres de código aberto em busca de vulnerabilidades e, em seguida, defina políticas

É inviável acompanhar manualmente todos os pacotes e contêineres de código aberto e verificar se têm vulnerabilidades. Em vez disso, invista em uma ferramenta que verifique continuamente sua cadeia de suprimentos de software. Evite proativamente que componentes vulneráveis avancem na cadeia definindo políticas que orientem os desenvolvedores a substituir esses softwares de código aberto arriscados por alternativas melhores desde o início do SDLC.

2. Garanta que você está usando os pacotes corretos

Como o typosquatting e a falsificação de marca são ameaças tão comuns à cadeia de suprimentos, é importante verificar cada pacote. Estabeleça pontos de verificação para pacotes de código aberto o quanto antes no ciclo de vida de desenvolvimento de software, usando uma ferramenta de análise da composição de software (SCA), como o Snyk Open Source. Para que sua equipe de desenvolvimento consiga seguir as orientações desses pontos de verificação, integre as análises de segurança aos fluxos de trabalho, por exemplo, à CLI das ferramentas do pipeline de CI/CD.

3. Mantenha registros do que há nos seus aplicativos (SBOM)

Os SBOMs são fundamentais para as boas práticas de segurança da cadeia de suprimentos de software de qualquer empresa. Como o SDLC moderno muda rapidamente, considere usar ferramentas de automação de SBOM.

Além disso, as equipes precisam controlar quem tem acesso aos SBOMs. Imagine que seu SBOM esteja amplamente disponível e que seu software contenha uma vulnerabilidade crítica recém-anunciada. Nesse caso, o próprio SBOM se torna uma ameaça à segurança da cadeia de suprimentos!

4. Implemente políticas abrangentes de RBAC

O controle de acesso baseado em função (RBAC) segue o princípio do menor privilégio: cada usuário recebe, por padrão, apenas o acesso mínimo necessário para realizar seu trabalho. Para estabelecer políticas de RBAC, sua equipe precisa saber quem tem acesso a quê e qual nível de acesso cada pessoa possui. O Policy as Code (PaC) permite que as equipes de segurança definam essas políticas de RBAC em código, usando uma linguagem declarativa de alto nível. Isso centraliza a gestão das políticas e as aplica de maneira uniforme em toda a organização.

5. Priorize a capacitação e o treinamento da equipe

Para evitar problemas causados por erros humanos ou negligência, capacite e treine sua equipe sobre possíveis ameaças à cadeia de suprimentos. A gamificação é uma ótima maneira de incentivar os desenvolvedores a aprender sobre as boas práticas de segurança da cadeia de suprimentos. Também é fundamental reconhecer quem contribui positivamente para os esforços de segurança da organização. A Snyk oferece lições gratuitas de segurança para desenvolvedores. Confira aqui.

Use a Snyk para proteger sua cadeia de suprimentos de software

As soluções da Snyk para segurança da cadeia de suprimentos ajudam as equipes de desenvolvimento e segurança a trabalhar juntas para proteger a cadeia de suprimentos de software. Ajudamos as organizações a proteger bibliotecas de código aberto, ferramentas de desenvolvimento, imagens de contêineres e infraestrutura de nuvem. Integrada às ferramentas e aos fluxos de trabalho de desenvolvimento já existentes, nossa plataforma de segurança que prioriza os desenvolvedores facilita a adoção das boas práticas de segurança da cadeia de suprimentos.