Cada dispositivo inteligente é distribuído com firmware construído a partir de pacotes open source, SDK de fornecedores de chips e ferramentas obtidas durante o build. Um ataque à cadeia de abastecimento só precisa de um deles. O CRACI executa os seus builds de firmware, regista todos os componentes que entram e impede o build de alcançar tudo aquilo de que não precisa.
A maior parte do código de um dispositivo ligado foi escrita por outros: uma distribuição de Linux embebido, o board support package do fornecedor de chips, uma stack de rede, algumas centenas de bibliotecas open source e os crates Rust por baixo delas. Os mesmos componentes são distribuídos em produtos de muitas marcas, e os dispositivos ficam em casa das pessoas durante anos, muitas vezes muito depois de alguém ter verificado pela última vez o que contêm.
Isso faz com que um único componente fraco valha muito para um atacante. Uma falha numa biblioteca partilhada ou num SDK abre todos os produtos que a distribuem, e uma versão envenenada chega a todos os builds que a obtêm. Estes incidentes mostram o padrão.
Dezanove vulnerabilidades, até CVSS 10.0, numa pequena biblioteca TCP/IP que os fabricantes de dispositivos licenciavam há anos, muitas vezes sob outro nome. Estava presente em produtos de muitos fornecedores, e muitos deles tiveram primeiro de apurar se a distribuíam sequer.
Não se pode corrigir um componente que não se sabe que se distribui.
Falhas no SDK de um fornecedor de chips chegaram a cerca de 200 modelos de dispositivos de cerca de 65 fabricantes: routers, câmaras IP, gateways de iluminação inteligente, brinquedos ligados. Uma botnet Mirai procurava-os dois dias depois de os pormenores se tornarem públicos.
O código do fornecedor de chips passa a ser o seu assim que é distribuído no seu dispositivo.
Foi plantada uma backdoor no próprio projeto xz a montante, nas versões 5.6.0 e 5.6.1. As imagens de Linux embebido incluem por norma bibliotecas de compressão como o xz, em geral sem que ninguém as escolha.
O open source de confiança pode tornar-se hostil numa única versão.
Os atacantes usaram os próprios certificados de assinatura da ASUS para assinar uma versão com backdoor do seu utilitário de atualização e distribuíram-na a partir dos servidores oficiais de atualização. A Kaspersky estimou que poderá ter chegado a mais de um milhão de utilizadores.
Uma assinatura válida só prova quem assinou, não o que entrou.
O reforço do dispositivo, como o arranque seguro, a ausência de palavras-passe predefinidas e uma porta de depuração fechada, protege o dispositivo que distribui. Os passos abaixo protegem o que entra nele.
O CRACI cobre o lado do build desta lista: a SBOM de cada build, as SBOM de fornecedores, a monitorização contínua, o isolamento do build, o controlo de egress e os policy gates. A assinatura e o reforço do dispositivo ficam com as suas próprias ferramentas.
Execute os seus builds de Yocto e de outras distribuições de Linux embebido nos runners de GitHub Actions do CRACI, até 32 vCPU, em x86-64 ou ARM64 nativo. Durante o build, o CRACI regista todos os pacotes e ficheiros que obtém, incluindo pacotes do host, fontes Git, GitHub Actions e descargas que nenhuma receita ou lockfile lista. Num build core-image-sato, a SBOM do CRACI tinha todos os componentes da própria SBOM do Yocto, mais 88 que esta não incluía, com um package URL para cada uma das 653 versões de crates Rust, para que todas possam ser monitorizadas quanto a vulnerabilidades.
Cada job é executado na sua própria máquina virtual isolada, sob uma política de egress validada antes de o job arrancar e com falha em modo fechado. Com uma política de negação por predefinição, o build alcança as suas fontes de pacotes e mais nada. Uma dependência comprometida que tente enviar o seu material de assinatura ou os seus tokens para o host de um atacante é bloqueada e gera um alerta, mesmo quando o ataque é novo e ninguém publicou ainda um aviso de segurança sobre ele.
Adicione SBOM dos seus fornecedores de chips e de outros fornecedores, e os componentes adquiridos são monitorizados a par do software que constrói. Quando surgir a próxima vulnerabilidade num SDK, o código do fornecedor está no mesmo registo que o seu.
O CRACI continua a reavaliar as SBOM monitorizadas à medida que são publicadas novas vulnerabilidades. O histórico de builds mostra que builds continham a dependência vulnerável, direta ou transitiva, e a vista de inventário mostra que versões de software estão implementadas em que produtos. As equipas de segurança fazem a triagem de cada conclusão e encaminham-na para a equipa responsável pela correção, e um policy gate pode manter uma CVE específica fora de todos os builds posteriores.
A marcação CE ao abrigo do Cyber Resilience Act assenta na documentação técnica e numa avaliação da conformidade. O CRACI fornece as evidências da cadeia de abastecimento de que essa documentação precisa: SBOM registadas durante o build e exportadas em CycloneDX ou SPDX, registos de vulnerabilidades e histórico de builds. O CRACI também submete as notificações de vulnerabilidades do CRA em seu nome. A avaliação da conformidade, a declaração UE de conformidade e a marcação CE continuam a seu cargo, enquanto fabricante.
O CRACI não assina firmware, SBOM nem proveniência, e não deteta novos pacotes maliciosos por comportamento ou reputação: assinala uma versão maliciosa quando existe um aviso de segurança com uma CVE e, até lá, confia na política de egress. Não realiza a sua avaliação da conformidade nem elabora a sua declaração de conformidade. Hoje executa jobs de GitHub Actions em runners Linux; GitLab CI, Jenkins e runners Windows e macOS estão no roadmap.
Perguntas comuns sobre a proteção de dispositivos ligados e da sua cadeia de abastecimento de software
É um ataque que chega a um dispositivo através de algo de que o fabricante depende, e não através do próprio dispositivo: uma biblioteca open source vulnerável, o SDK de um fornecedor de chips, uma versão de pacote envenenada, uma ferramenta de build comprometida ou um canal de atualização sequestrado. Como o mesmo componente é distribuído em muitos produtos, uma única falha pode chegar de uma só vez a milhões de dispositivos de muitas marcas.
Comece pelo que distribui: mantenha uma SBOM para cada build de firmware, acompanhe os componentes dos fornecedores e continue a verificar as versões distribuídas à medida que surgem novas vulnerabilidades. Proteja o próprio build, mantenha de fora as versões problemáticas conhecidas com policy gates, proteja as suas chaves de assinatura e tenha um processo de triagem, correção e divulgação. O reforço do dispositivo, como o arranque seguro e a desativação das palavras-passe predefinidas, também importa, mas não ajuda se o firmware já trouxer um componente vulnerável.
Conheça todos os componentes que entram na imagem, incluindo o que o build obtém fora das suas receitas e lockfiles, e guarde esse registo por versão. Faça o build num ambiente isolado que só alcance as fontes de que precisa, para que uma dependência maliciosa não consiga enviar os seus segredos para lado nenhum. Monitorize os componentes registados e as SBOM dos seus fornecedores face a novas vulnerabilidades enquanto os dispositivos tiverem suporte.
Sim. Os builds de Yocto e BitBake são executados em runners do CRACI, e o CRACI regista a SBOM do job durante o build. O resultado SPDX do próprio Yocto continua a incluir metadados das receitas que o CRACI não regista, como os patches aplicados e as CVE que uma receita marca como corrigidas, por isso mantenha o create-spdx ativo se depender deles.
Sim, quando tem uma SBOM deles. Pode adicionar SBOM de fornecedores ao CRACI, e esses componentes são monitorizados a par do software que constrói. Tudo o que o seu build descarregar de um fornecedor durante o build é também registado na SBOM do job.
Não por comportamento ou reputação. Uma versão maliciosa conhecida que tenha uma CVE publicada, como a backdoor do xz, é assinalada como qualquer outra vulnerabilidade, e um policy gate pode bloquear os builds que a contenham. Contra ataques novos, a proteção do CRACI é a política de egress de negação por predefinição, que impede o build de alcançar hosts de que não precisa.
Não. O CRACI não assina firmware, SBOM nem proveniência. Continue a usar o seu próprio processo de assinatura e armazenamento de chaves baseado em hardware para as versões e atualizações.
O Cyber Resilience Act abrange os produtos com elementos digitais colocados no mercado da UE, o que inclui a maioria dos dispositivos de consumo ligados. As obrigações de reporte aplicam-se a partir de 11 de setembro de 2026 e o regulamento aplica-se na íntegra a partir de 11 de dezembro de 2027. O CRACI automatiza uma parte significativa da visibilidade da cadeia de abastecimento e das evidências de que o processo do CRA precisa; o cumprimento do regulamento continua a ser um processo do fabricante.
O CRACI executa jobs de GitHub Actions em runners Linux, x86-64 e ARM64, de 1 a 32 vCPU. Outros sistemas de CI, como o GitLab CI e o Jenkins, estão no roadmap, tal como os runners Windows e macOS.
Marque uma demo e mostraremos todos os componentes que os builds dos seus dispositivos obtêm, e quais deles são vulneráveis
Marcar demo