A integridade das cadeias de fornecimento de software tornou-se um grande tema de debate nos últimos anos, com os ataques às cadeias de fornecimento de software a tornarem-se mais frequentes nos últimos dois anos. Tornou-se imperativo que os desenvolvedores escolham cuidadosamente software e produtos externos para incluir em seus sistemas de software, ao mesmo tempo que implementam medidas para garantir a integridade de seus artefatos de software.
O processo de construção e implantação de software é bastante complicado, com muitos pontos potenciais de vulnerabilidade em toda a cadeia. Em vez de depender de correções específicas para cada vulnerabilidade, faz mais sentido que os desenvolvedores adotem uma estrutura ponta a ponta mais abrangente que possa ajudar a mitigar ameaças durante a fase de desenvolvimento.
Um desses quadros é o Níveis da cadeia de suprimentos para artefatos de software (SLSA). Esta estrutura é uma lista de verificação abrangente de controles e padrões de segurança que garantem a integridade dos pacotes de software e da infraestrutura.
O SLSA recentemente introduzido estrutura de segurança é um produto de uma colaboração entre OpenSSFGenericName, Google e outras partes interessadas em segurança cibernética. Ele serve como um padrão industrial acordado que pode ser adotado por desenvolvedores, empresas e empresas para ajudá-los a fazer escolhas informadas sobre a segurança do software que estão construindo ou consumindo e proteger todo o ciclo de vida de desenvolvimento de software.
Como SLSA ajuda na defesa contra ataques à cadeia de suprimentos de software
Mais do que um conjunto de regras, a estrutura de segurança SLSA é uma estrutura padrão que pode fortalecer potencialmente a integridade dos componentes de um artefato de software. Esta diretriz ponta a ponta atua como um conjunto de medidas defensivas que previne gradativamente a adulteração ou qualquer tipo de modificação não autorizada nos pacotes de software que compõem um produto de software. A adoção da estrutura SLSA pode ajudar a proteger seu software contra ataques à cadeia de abastecimento como o seguinte:
Ataques maliciosos ao repositório de commits do PHP
Em março de 2021, Nikita Popov anunciou que atores mal-intencionados tentaram atacar o código-fonte do PHP criando um backdoor que lhes permitiria obter acesso não autorizado à plataforma de código. Se tivesse sucesso, o ataque teria sido devastador, já que o PHP alimenta cerca de 80% dos sites na internet. Felizmente, o ataque foi detectado a tempo, mas este incidente ainda ilustra como os controles SLSA podem ajudar a prevenir ataques como este no futuro. Seguir os protocolos SLSA, como revisão de duas pessoas e autenticação de dois fatores, teria protegido a plataforma do código-fonte e tornado-a um alvo muito mais difícil para os invasores.
Violação do compilador malicioso da Apple
Em 2015, desenvolvedores de software que criavam aplicativos para produtos Apple baixaram uma versão do Xcode (uma ferramenta de escrita de código para dispositivos Apple) de uma plataforma de hospedagem não verificada. A versão do Xcode conhecida como XcodeGhost foi infectada com código malicioso que foi secretamente transferido para aplicativos desenvolvidos com ele. Ele criou um backdoor para vários aplicativos que escaparam do processo de revisão de código da Apple e dos aplicativos oferecidos na app store. A estrutura SLSA contém protocolos de segurança relacionados à construção que teriam evitado um ataque como esse ou dificultado. Uma dessas medidas é o requisito de construção hermética que teria forçado os desenvolvedores a declarar todas as suas fontes, incluindo a ferramenta construída que usaram.
Artefatos maliciosos carregados
Em 1º de abril de 2021, a equipe Codecov descobriu ataques que afetavam seus Bash Uploaders, que incluíam Codecov GitHub Action, The Codecov CircleCI Orb e Codecov Bitrise Step. O invasor obteve acesso não autorizado extraindo uma chave HMAC que fornecia acesso à conta de serviço do Google Cloud Storage de uma camada intermediária de uma das imagens públicas do Docker auto-hospedadas da Codecov. Essa chave permitiu que eles modificassem o Bash Uploader para enviar códigos maliciosos diretamente aos usuários finais. A estrutura SLSA teria capturado essa ação mostrando quando os artefatos são construídos de maneira diferente da forma esperada em seu repositório de origem.
Dependência ruim do fluxo de eventos
Em 2018, hackers publicaram um pacote malicioso flatmap-stream para npm e este foi posteriormente adicionado como uma dependência ao pacote event-stream amplamente utilizado da plataforma. Após adicionar a dependência, os invasores a atualizaram com comportamento malicioso. Como a atualização não correspondia ao código enviado ao GitHub, a estrutura SLSA teria capturado o ataque e evitado o vetor. Rastrear a origem do código malicioso teria revelado que ele não veio do GitHub ou do construtor adequado. De qualquer forma, o ataque poderia ter sido evitado.
Os quatro níveis de segurança da estrutura de segurança cibernética SLSA
A estrutura SLSA é um protocolo incremental e acionável. Consiste em quatro níveis, sendo que o Nível 4 representa o estado final ideal de um sistema seguro. Os artefactos ao mais alto nível cumprem todos os requisitos para ganhar a confiança do consumidor de que não foram adulterados de forma alguma e de que todos os seus componentes podem ser rastreados até às suas fontes. Os artefactos nos níveis mais baixos são aqueles que também alcançaram marcos incrementais com garantias de integridade específicas, dependendo da sua classificação.
Nível 1 – lançando as bases
Você pode considerar o Nível 1 da estrutura SLSA como uma espécie de base para toda a estrutura criar software seguro. Nesta fase, os desenvolvedores ou organizações que adotam o SLSA precisam fazer duas coisas. Primeiro, eles precisam automatizar totalmente o processo de construção. Isso pode ser feito de diferentes maneiras, mas a maneira convencional de automatizar compilações é usando um makefile. GitHub Actions também podem ser usadas para obter os mesmos resultados.
A segunda parte para alcançar o SLSA Nível 1 é gerar documentação completa de proveniência. São metadados que mostram como um artefato de software foi construído. Deve detalhar todo o processo de construção, todas as dependências e fontes de nível superior usadas na construção.
Criar scripts do processo de construção e mostrar a origem de um artefato de software dessa maneira torna mais fácil para os consumidores tomarem decisões informadas sobre o uso de um produto de software. Embora a verificação SLSA 1 não signifique que o software esteja totalmente protegido contra adulterações, facilita a identificação dos componentes do software. Este é o primeiro estágio no gerenciamento de vulnerabilidades.
Nível 2 – Certifique-se de que seu processo de construção seja resistente a violações
O nível 2 da estrutura SLSA é onde você começa a implementar medidas para garantir que seu processo de construção seja o mais resistente possível a violações. Alcançar o Nível 2 da estrutura SLSA também dá ao consumidor mais confiança sobre a origem do software.
Novamente, isso é feito em duas etapas, a primeira usando o controle de versão e a segunda envolvendo o uso de um serviço de construção hospedado para autenticar a procedência. Para a primeira etapa, GitHub, GitLab ou qualquer outro serviço semelhante é usado para armazenar o código e registrar quaisquer alterações feitas nele. Rastrear quaisquer alterações de versão dessa forma facilita a compreensão de quaisquer alterações realizadas no artefato no processo de construção.
Embora o Nível 2 exija documentação de proveniência assim como o Nível 1, a diferença aqui é que o artefato de software deve ser autenticado por um serviço de construção hospedado. O serviço hospedado atua como um terceiro confiável que pode confirmar se o processo de construção detalhado no documento de procedência inicial é preciso. GitHub Actions é um tipo de serviço de hospedagem que pode fornecer proveniência autenticada.
Nível 3 – controles de segurança do SLSA
O nível 3 é onde você começa a implementar o controle de segurança específico conforme destacado na estrutura SLSA. Para atingir esse nível, as plataformas de origem e de construção de seus artefatos de software devem atender a padrões específicos que garantam que a origem seja auditável e que a origem do código seja confiável. SLSA Nível 3 oferece uma garantia muito mais forte de que o artefato está bem protegido contra adulterações e classes específicas de ameaças.
Alguns dos requisitos específicos do Nível 3 incluem:
- Histórico e retenção verificados pelo código-fonte—Um histórico verificado do código-fonte garante que qualquer alteração feita no código-fonte do software seja acompanhada por uma identidade autenticada do autor, revisor ou uploader que fez a alteração com carimbos de data/hora específicos da alteração. Este histórico de alterações também deve ser armazenado por pelo menos 18 meses.
- Builds isoladas em ambientes efêmeros—Para atender a esse requisito, as construções de software devem ser implementadas em ambientes efêmeros onde sejam completamente independentes de quaisquer outras instâncias de construção. Você pode usar um serviço como o GitHub Actions, que usa uma máquina de compilação virtual para produzir sua compilação sob demanda, para conseguir isso.
- Constrói como código—Esses critérios exigem que você trate seus arquivos de construção como código. Isso significa que eles devem ser armazenados em um sistema de controle de versão que possibilite recriar processos de construção quando necessário.
- Procedência não falsificável—O objetivo deste requisito é evitar que os usuários adulterem a documentação de procedência gerada pelo serviço de construção.
Nível 4 – Confiança do consumidor
O nível 4 da estrutura SLSA destina-se a garantir que o software não foi adulterado de forma alguma. Somente artefatos de software que atendem aos seguintes requisitos podem atingir o Nível 4 da estrutura:
Revisão por duas pessoas de todas as alterações
Este critério exige que as organizações designem dois revisores qualificados para revisar minuciosamente quaisquer alterações propostas no código e nos componentes do software. Esse processo de revisão por duas pessoas garante que apenas desenvolvedores confiáveis e autenticados possam fazer alterações nos artefatos de software.
Um processo de construção hermético e reproduzível
Diz-se que um processo de construção é hermético quando todas as entradas são especificadas antecipadamente e fora do processo de construção. Esta regra se aplica ao código-fonte, bem como a todos os compiladores, bibliotecas e ferramentas usadas na construção. Isto ajuda a garantir a integridade de todas as importações de terceiros. Os critérios de construção reproduzíveis não são um requisito obrigatório, mas também são recomendados. Os critérios exigem que o processo de construção produza a mesma saída, independentemente de onde ou quando for executado.
Requisitos técnicos para atender aos níveis SLSA
A estrutura SLSA possui requisitos técnicos específicos para os diferentes níveis. Esses requisitos são classificados em cinco categorias principais: requisitos de origem, requisitos de processo de construção, requisitos comuns, requisitos de conteúdo de proveniência e requisitos de geração de proveniência. Cada uma dessas categorias de requisitos é destacada abaixo.
Requisitos de origem
Refere-se aos requisitos que visam garantir a integridade do seu código-fonte. Seguir esses conjuntos de protocolos evita adulterações e alterações maliciosas em seu código. Também garante que quaisquer ações nefastas não passem despercebidas. Os requisitos de origem estão definidos na tabela abaixo.
| Requisitos de origem | Descrição | Nível SLSA |
| Controle de versão | Todas as alterações no código-fonte devem ser rastreadas. | 2 |
| Histórico verificado | Deve ser registrado um histórico abrangente detalhando “quem”, “o quê” e “quando” de cada revisão de versão. | 3 |
| Retido indefinidamente | Todas as alterações de versão e informações de histórico devem ser armazenadas indefinidamente e não devem ser excluídas. | 4 |
| Revisado por duas pessoas | Duas pessoas confiáveis e altamente autenticadas devem autorizar qualquer alteração de versão. | 4 |
Requisitos de construção
A estrutura SLSA destaca os requisitos de construção destinados a melhorar a segurança da plataforma de construção e manter a integridade do processo de construção.
| Requisitos de construção | Descrição | Nível SLSA |
| Construção com script | Todas as etapas do processo de construção devem ser totalmente automatizadas. | 1 |
| Construir serviço | Todas as etapas do processo de construção devem ser executadas em um serviço de construção dedicado. | 2 |
| Ambiente efêmero e isolado | O processo de construção deve ser executado em um ambiente temporário fornecido especificamente para a construção. As etapas também devem ser executadas em um ambiente isolado, livre de outras instâncias de build.
|
3 |
| Sem parâmetros e hermético | O processo de construção deve depender inteiramente do script de construção em vez de parâmetros do usuário. Todas as etapas transitivas de construção devem ser herméticas, o que significa que todas as fontes e dependências devem ser totalmente declaradas antecipadamente e fora do processo de construção. | 4 |
Requisitos de geração de proveniência
Esses requisitos têm como objetivo verificar a origem de todos os componentes de um ativo de software. Os requisitos de geração de proveniência estão destacados na tabela abaixo.
| Requisitos de geração de proveniência | Descrição | Nível SLSA |
| Disponível | O consumidor deve ter acesso à informação sobre a proveniência num formato aceitável. | 1 |
| Verificável | O consumidor deverá poder verificar a autenticidade das informações sobre a proveniência fornecidas. | 1 |
| Gerado por serviço | Todas as informações de proveniência devem ser geradas pelo serviço de construção.
|
2 |
| Não falsificável | Os usuários não podem falsificar dados de proveniência. | 3 |
| Dependências completas | Os dados de proveniência devem incluir todas as dependências utilizadas durante as etapas de construção. | 4 |
Requisitos de conteúdo de proveniência
Os requisitos de conteúdo de proveniência verificam a identidade e a origem de todos os artefatos, dependências e restrições de construção que foram usados no processo de construção. Eles estão destacados na tabela abaixo.
| Requisitos de conteúdo de proveniência | Descrição | Nível SLSA |
| Identifica artefato, construtor, origem e ponto de entrada. | ● Identifica o artefato de saída
● Identifica a entidade de construção ● Identifica a fonte por meio de uma referência imutável ● Identifica o comando que invocou o script de construção |
1 |
| Inclui todos os parâmetros de compilação | Todos os parâmetros de construção devem ser identificados.
|
3 |
| Inclui dependências transitivas e informações reproduzíveis | ● Inclui todas as dependências transitivas
● Se a construção for reproduzível, todas as informações necessárias para reproduzi-la deverão ser fornecidas
|
4 |
| Inclui metadados | Todos os metadados devem ser incluídos para auxiliar nas investigações. | 0 |
Requisitos Comuns
Os requisitos comuns se aplicam a artefatos de software no nível 4 do SLSA. Espera-se que todo artefato confiável atenda a esses requisitos. Eles incluem requisitos básicos de segurança e registros que detalham todo o acesso físico e remoto. Os requisitos comuns também estipulam um pequeno número de administradores de plataforma que podem substituir as estipulações na documentação do SLSA.