Para equipas PSIRT
O CRACI para equipas PSIRT e responsáveis de segurança de produto
A primeira pergunta em qualquer caso de PSIRT é que produtos e versões nossos contêm o componente vulnerável. O CRACI responde a partir de um registo do que cada build efetivamente obteve, e continua a responder à medida que são publicadas novas CVE.
Atualizado a
O problema de um gestor de PSIRT
Um responsável de segurança de produto tem de prestar contas por respostas que a PSIRT não produz sozinha. Quando surge uma CVE numa biblioteca amplamente usada, clientes, executivos e, cada vez mais, reguladores fazem as mesmas perguntas em poucas horas: estamos afetados, em que produtos e versões, desde quando, e quando será corrigido?
As respostas dependem do inventário, e o inventário vem normalmente de scanners que leem lockfiles ou manifestos a posteriori. Estes listam dependências de desenvolvimento que nunca são distribuídas e não veem pacotes que o build descarregou de outra forma. Assim, a PSIRT pede às equipas de engenharia que verifiquem manualmente, e a resposta chega dias depois, com ressalvas.
O PSIRT Services Framework da FIRST considera um inventário dos componentes do produto essencial para identificar rapidamente os produtos afetados por vulnerabilidades herdadas. É nesse inventário que o CRACI começa. Para uma visão completa da função, consulte o que é uma PSIRT.
O que o CRACI dá a uma PSIRT
Um inventário registado a partir do build
O CRACI executa os seus builds de GitHub Actions em runners próprios e regista os pacotes que cada job efetivamente obteve, incluindo dependências transitivas, pacotes restaurados de caches de CI e dependências que nenhum lockfile lista. É um registador, não um scanner. Cada SBOM traz um estado de completude, pelo que um registo parcial é assinalado como parcial, e as SBOM são exportadas em CycloneDX ou SPDX.
Monitorização contínua do que foi distribuído
As SBOM monitorizadas são reavaliadas continuamente à medida que são publicadas novas vulnerabilidades, e as conclusões são agregadas em todos os builds e repositórios. Uma CVE publicada no próximo mês é cruzada com as versões que já distribuiu, não apenas com o próximo build. As versões maliciosas conhecidas com uma CVE publicada são assinaladas como qualquer outra vulnerabilidade.
Produtos, versões e períodos afetados
O histórico de builds mostra todos os builds anteriores com a respetiva SBOM e que builds continham uma dependência vulnerável, direta ou transitiva, pelo que sabe durante que período esteve afetado, dentro do seu período de retenção. A vista de inventário mostra exatamente que versões de software estão implementadas em que produtos. Em conjunto, transformam "estamos afetados?" numa simples consulta.
Componentes adquiridos
Os produtos raramente são constituídos apenas pelo seu próprio código. É possível adicionar SBOM de fornecedores, pelo que os componentes de terceiros são monitorizados a par dos seus builds.
Triagem, encaminhamento e VEX
As equipas de segurança fazem a triagem das vulnerabilidades descobertas e enviam-nas às equipas responsáveis pela correção, o que corresponde ao modelo distribuído de PSIRT, em que as equipas de produto fazem a remediação. O CRACI suporta VEX. Consulte VEX para ver como as declarações de não afetado poupam trabalho a uma PSIRT e aos seus clientes.
Manter uma CVE corrigida fora de builds posteriores
Os policy gates podem bloquear um build com base em conclusões, incluindo builds que contenham uma CVE específica. Depois de um caso de PSIRT ser encerrado, um gate sobre essa CVE impede que a versão vulnerável regresse discretamente num lançamento posterior.
Evidências para auditorias e clientes
A API devolve SBOM, traços de rede e proveniência de cada build, pelo que o registo por detrás de um aviso de segurança ou de uma resposta de auditoria está disponível fora da interface. Onde o Cyber Resilience Act da UE se aplica, o CRACI também submete as notificações exigidas às autoridades em nome do fabricante; a obrigação continua a ser do fabricante. Consulte o que é o CRA.
Onde o CRACI se enquadra no processo de PSIRT
| Fase da PSIRT | Contributo do CRACI |
|---|---|
| Preparação | Uma SBOM por build, registada durante a execução, com um estado de completude |
| Descoberta | Reavaliação contínua das SBOM monitorizadas, incluindo SBOM de fornecedores |
| Verificação | Que builds, versões e produtos contêm o componente, e desde quando |
| Remediação | Triagem para a equipa responsável; policy gates que mantêm a CVE fora de builds posteriores |
| Lançamento e divulgação | Suporte de VEX; exportação de SBOM; acesso ao registo do build através da API |
As fases seguem o ciclo de vida da gestão de vulnerabilidades.
O que o CRACI não faz
- Análise de alcançabilidade. O CRACI mostra que um pacote vulnerável estava no build, não se o seu código chama a função vulnerável.
- Análise do código-fonte. O SAST e a análise de segredos estão fora do âmbito; há muitas boas ferramentas que o fazem a par do CRACI.
- Sistemas de CI além do GitHub Actions. Hoje, o GitHub Actions; outros sistemas de CI estão no roadmap.
- Conformidade em seu nome. O CRACI fornece as evidências; cumprir a NIS2, o CRA ou qualquer outro referencial continua a ser um processo da sua organização.
CRACI para equipas PSIRT: perguntas frequentes
O CRACI é uma ferramenta de PSIRT?
O CRACI cobre a parte do trabalho de PSIRT que depende de saber o que distribui: SBOM registadas durante o build, a sua monitorização contínua, que builds e produtos contêm um componente vulnerável, e a triagem para a equipa responsável. O seu canal de divulgação e o seu processo de avisos de segurança assentam nesse registo.
Como sabe o CRACI o que está num produto?
Os builds são executados nos runners de GitHub Actions do CRACI, e o CRACI regista os pacotes que cada job efetivamente obteve, incluindo dependências transitivas, pacotes restaurados de caches de CI e dependências que nenhum lockfile lista. É um registador, não um scanner. Cada SBOM traz um estado de completude, pelo que sabe quando o registo é parcial.
O CRACI consegue dizer-nos que versões anteriores foram afetadas por uma CVE?
Sim, dentro do seu período de retenção. O histórico de builds mostra todos os builds anteriores e a respetiva SBOM, e que builds continham uma dependência vulnerável, direta ou transitiva, pelo que sabe durante que período esteve afetado. A vista de inventário mostra que versões de software estão implementadas em que produtos.
O CRACI cobre os componentes que compramos a fornecedores?
Pode adicionar SBOM de fornecedores, pelo que os componentes adquiridos são monitorizados a par dos seus builds.
O CRACI suporta VEX?
Que sistemas de CI suporta o CRACI?
Hoje, o GitHub Actions. Outros sistemas de CI estão no roadmap.
Veja a exposição dos seus produtos a partir do build
Marque uma demo com os seus próprios builds de GitHub Actions: as SBOM que o CRACI regista, os builds a que uma CVE chegou e a vista de triagem em que a sua PSIRT trabalharia.
Marcar demo