CRACI vs Timesys Vigiles

A resposta curta

O Vigiles é o produto de SBOM e de gestão de vulnerabilidades da Timesys, que a Lynx Software Technologies adquiriu em dezembro de 2023; a Lynx vende-o agora como Lynx Vigiles. Foi feito para Linux embebido: uma camada Yocto, a meta-timesys, recolhe metadados sobre os pacotes da sua imagem e carrega-os, e o Vigiles cruza-os com uma base de dados de CVE com curadoria, acompanhando depois as decisões de triagem e exportando relatórios de SBOM, VEX e vulnerabilidades.

O CRACI é um runner de GitHub Actions. O seu build BitBake corre nele e, durante a execução, o CRACI regista todos os pacotes e fontes que o build obteve, limita a que o build se pode ligar e continua a monitorizar a SBOM face a vulnerabilidades. Ambos os produtos lhe dão uma SBOM e monitorização de CVE para uma imagem Yocto; diferem na origem da SBOM. O Vigiles lê o que os metadados do BitBake dizem que entra na imagem. O CRACI regista o que o build realmente trouxe.

Visão geral

O que o Vigiles faz bem

Feito para Linux embebido. O Vigiles integra-se com o Yocto através da meta-timesys, e com Buildroot, OpenWrt, Timesys Factory e FreeRTOS, e importa SBOM em SPDX 2.2 a 3.0.1, CycloneDX 1.1 a 1.7 e CSV para tudo o resto. A Lynx afirma que o Vigiles, lançado em 2019, já processou mais de 90.000 SBOM.

Menos ruído de CVE. O Vigiles cruza os componentes com uma base de dados de CVE com curadoria em vez de dados públicos em bruto, o que, segundo a Lynx, elimina a maioria dos falsos positivos que os dados públicos produzem. O seu scanner pode carregar os seus ficheiros .config completos do kernel Linux e do U-Boot, pelo que os CVE em funcionalidades que não compila são filtrados. Isto importa em Linux embebido: no relatório de exemplo do README da meta-timesys, 60 dos 62 CVE por corrigir estão no kernel.

Decisões que perduram entre versões. As equipas registam se cada CVE é affected, fixed, deferred ou not exploitable, e o Vigiles guarda essas decisões por versão, destaca as CISA Known Exploited Vulnerabilities e exporta SBOM em CycloneDX, SPDX e SPDX Lite, juntamente com relatórios VEX e de vulnerabilidades. Os seus relatórios mostram também os CVE já corrigidos por patches no seu build e os patches disponíveis na camada meta-timesys-security. A Lynx inclui o CRA da UE e a EO 14028 entre as normas em que ajuda, e o Vigiles liga-se ao Jira e ao Okta.

Onde o CRACI é diferente

A SBOM do Vigiles é apenas tão completa quanto a visão que o BitBake tem da imagem. O README da meta-timesys descreve-a como uma recolha de metadados sobre os pacotes a instalar, e os pacotes construídos fora do BitBake, ou construídos por ele mas ausentes do manifesto do sistema de ficheiros raiz, têm de ser listados à mão. O CRACI não lê metadados. É a máquina onde o build corre.

O que a própria SBOM do Yocto deixa de fora

Não comparámos uma SBOM do Vigiles com a do CRACI. Comparámos a do CRACI com a SBOM SPDX integrada do Yocto, que também é gerada a partir dos metadados do BitBake. Num build lado a lado de core-image-sato num runner ARM64 de 32 vCPU, a SBOM do CRACI tinha todos os componentes da SBOM do Yocto, mais 88 que esta não incluía: pacotes do host na máquina de build, como o cpio do Ubuntu, fontes do GitHub e a GitHub Action actions/upload-artifact, e outras fontes e ferramentas obtidas durante o build. Nenhum deles está instalado na imagem, e todos estão no caminho crítico do build.

Ambas as SBOM listavam as mesmas 653 versões de crates Rust, mas a do Yocto lista-as apenas por nome de ficheiro e URL de transferência, sem package URL. A correspondência de vulnerabilidades funciona com package URLs, pelo que esses crates não podem ser monitorizados a partir da SBOM do Yocto. O CRACI regista cada um deles com um package URL pkg:cargo.

Controlo sobre o que o build pode alcançar

Uma política de egress no runner decide a que hosts um job se pode ligar. É validada antes de o job arrancar, falha em modo fechado e envia um alerta em caso de violação. Para Yocto, acrescenta uma segunda camada ao próprio BB_ALLOWED_NETWORKS do BitBake, e uma política de negação por defeito impede que uma ferramenta de build comprometida envie segredos para um host de que o build não precisa.

Proveniência e monitorização a partir do mesmo registo

A API devolve SBOM, traços de rede e proveniência. O CRACI não assina a proveniência. O CRACI agrega vulnerabilidades de todos os builds e repositórios, continua a reavaliar as SBOM monitorizadas à medida que surgem avisos de segurança, permite às equipas de segurança fazer a triagem das conclusões e encaminhá-las para a equipa responsável pela correção, e mostra que builds anteriores continham uma dependência vulnerável, para que saiba durante que período esteve afetado. O CRACI suporta VEX e pode submeter as notificações de vulnerabilidades do CRA em seu nome.

O próprio build, em runners maiores

O Vigiles não executa o seu build; o CRACI executa. Os builds Yocto correm em runners de até 32 vCPU e 96 GB de RAM, medidos ao segundo a $0.002 por vCPU-minuto ($0.004 para um runner predefinido de 2 vCPU). Na mesma comparação de core-image-sato, o build sem a geração de SBOM do Yocto demorou menos 43% do que o build com ela.

Substituir o Vigiles pelo CRACI

Para imagens Yocto construídas em GitHub Actions, o CRACI cobre aquilo para que o Vigiles é comprado: uma SBOM para cada build, monitorização de CVE após o lançamento, decisões de triagem e VEX. Acrescenta o que uma SBOM baseada em metadados não lhe pode dar: os pacotes do host, as fontes do GitHub e as Actions que o build usou, e uma política de egress durante a execução.

Tenha bem presente aquilo de que abdica. Os dados de CVE com curadoria do Vigiles e os filtros de configuração do kernel e do U-Boot reduzem o ruído de CVE de uma forma que o CRACI não faz. O Vigiles reporta que CVE os patches do seu build já corrigem, o que o CRACI não regista; o próprio SPDX do Yocto também contém esses metadados das receitas, pelo que deve manter create-spdx ativo se depender deles. O Vigiles cobre também Buildroot, OpenWrt e FreeRTOS, corre dentro de qualquer CI e importa SBOM em muitos formatos. O CRACI suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap, pelo que os pipelines de Jenkins ou GitLab teriam primeiro de ser migrados para GitHub Actions.

Para o CRA

O Cyber Resilience Act pede aos fabricantes que documentem os componentes dos seus produtos, incluindo uma SBOM, e que tratem as vulnerabilidades enquanto um produto tiver suporte, com obrigações de reporte a partir de setembro de 2026. O Vigiles ajuda ao guardar SBOM, decisões sobre CVE e relatórios por versão. O CRACI produz as evidências por build do que entrou no firmware, com proveniência, monitorização contínua e exportação de SBOM em CycloneDX ou SPDX. Automatiza uma parte significativa da visibilidade da cadeia de abastecimento de software e das evidências de que um fabricante precisa para o seu processo mais amplo do CRA; nenhuma das ferramentas torna um produto conforme por si só. Leia o que exige o CRA.

Migrar um build Yocto para o CRACI

Defina runs-on: craci no job BitBake e escolha um tamanho de runner; o workflow continua a correr em GitHub Actions. O exemplo de Yocto na documentação do CRACI constrói core-image-sato no maior tamanho. Veja como o CRACI funciona para IoT industrial e eletrónica de consumo.