Cadeia de fornecimento

Os agentes de programação instalam muitos pacotes, e uma dependência recentemente comprometida é uma das formas mais diretas de envenenar uma sandbox. O painel Cadeia de fornecimento configura a política por espaço de trabalho que a Bromure Agentic Coding aplica a cada obtenção de pacote. Como diz a própria descrição do painel: a Bromure examina cada obtenção de pacote (npm, PyPI, Cargo, RubyGems, Maven, NuGet, módulos Go, Packagist) através do MITM do anfitrião e aplica estas políticas antes de o agente ver a resposta; os ficheiros .npmrc / pip.conf dentro da VM só podem restringir ainda mais estas definições — não as podem relaxar. Utilize as listas de permissões por pacote para exceções cirúrgicas.

O painel agrupa cinco camadas ativadas de forma independente: Restrição por idade, Verificação de vulnerabilidades OSV, Filtragem de pacotes, Scripts de instalação e Instalações fixadas por ficheiro de bloqueio (desloque-se para ver as três últimas). Esta página documenta as definições; o pipeline completo — cobertura de ecossistemas, o Registo de Segurança, cabeçalhos de resposta e deteção de comprometimento — é abordado no capítulo de proteção da cadeia de fornecimento.

Como funciona a aplicação

Todas as verificações são executadas no proxy do lado do anfitrião, nunca dentro da VM. As chaves de API dos serviços de reputação (socket.dev, Delpi) são mantidas apenas no anfitrião e nunca exportadas para a VM. Quando uma verificação é acionada, o proxy bloqueia o descarregamento com uma resposta HTTP 451 que transporta um motivo em texto simples (por exemplo, "npm package [email protected] published 4 hours ago — policy requires 2 days minimum"); o npm, o pip e o cargo imprimem esse texto tal e qual, pelo que tanto o agente como você veem exatamente por que motivo uma instalação falhou. As respostas bloqueadas transportam o cabeçalho X-Bromure-Block: supply-chain; as respostas reescritas transportam X-Bromure-Rewritten: supply-chain.

As edições de política aplicam-se em tempo real: guardar o espaço de trabalho envia imediatamente a nova política para as sessões em execução — sem reiniciar a VM — e cada alteração é confirmada com uma linha [supply-chain] policy engaged no Registo de Segurança (menu Janela → Registo de Segurança…).

Nota: Os pacotes já presentes na cache local do npm ou do pip nunca acedem à rede, pelo que nada é verificado ou registado para eles. Um Registo de Segurança silencioso durante uma instalação pode simplesmente significar que tudo estava em cache.

Restrição por idade

A restrição por idade recusa versões de pacotes mais recentes do que um limite configurável, partindo do princípio de que as versões acabadas de publicar são as que mais provavelmente correspondem a um pacote recentemente comprometido. É a única camada ativada por predefinição.

• Recusar pacotes mais recentes do que o limite — o interruptor principal. Ativado por predefinição.
• Idade mínima — o limite em dias (seletor incremental, 0–90). Predefinição: 2 dias.
• Pacotes isentos — uma lista de permissões no formato npm:axios (um ecossistema) ou apenas axios (todos os ecossistemas), sem distinção de maiúsculas/minúsculas. Clique em Adicionar entrada para acrescentar uma linha.

As referências flutuantes (pkg@latest, intervalos semver) nunca são bloqueadas de forma rígida: o proxy reescreve os metadados do registo de modo que as versões demasiado recentes simplesmente não existam do ponto de vista do agente, e o gestor de pacotes resolve para a versão permitida mais recente. Apenas as referências fixadas a versões demasiado recentes recebem o 451, indicando a idade do pacote e o mínimo exigido.

Nota: Os módulos Maven, NuGet e Go não transportam marcas temporais por versão nas suas respostas de metadados padrão, pelo que a restrição por idade não bloqueia atualmente esses três ecossistemas. O npm, o PyPI, o Cargo, o RubyGems e o Packagist estão totalmente cobertos (no caso do PyPI, a Bromure consulta os tempos de publicação a pedido através da API JSON do PyPI).

Verificação de vulnerabilidades OSV

Quando Consultar pacotes em api.osv.dev (gratuito, sem chave necessária) está ativado, o ecossistema, o pacote e a versão de cada artefacto descarregado são verificados na base de dados OSV — uma agregação gratuita da GitHub Advisory Database, dos avisos do PyPI, da base de dados de vulnerabilidades do Go, da RubySec e de outras. Qualquer aviso igual ou superior ao limiar de Bloquear a partir da gravidade bloqueia o descarregamento com um 451.

• Desativado por predefinição — como o painel indica, uma CVE de baixa gravidade num subpacote transitivo não deve interromper um fluxo de trabalho.
• Bloquear a partir da gravidade oferece Baixa e acima, Média e acima, Alta e acima (a predefinição) ou Apenas crítica.
• Cobre todos os oito ecossistemas; as verificações são executadas no momento do descarregamento do artefacto, não nas obtenções de metadados.

Filtragem de pacotes

O botão de opção Filtragem de pacotes seleciona um fornecedor de reputação: Nenhum, socket.dev ou Delpi. Os dois fornecedores funcionam de forma diferente — o socket.dev é uma consulta prévia que o proxy realiza antes de deixar passar uma obtenção, ao passo que o Delpi substitui totalmente o registo npm — pelo que são mutuamente exclusivos. As chaves de API armazenadas são conservadas quando muda de fornecedor, pelo que alternar entre fornecedores não é destrutivo.

socket.dev

Com o socket.dev selecionado, cole um token de API em Chave de API (a hiperligação Obter uma chave de API abre a página de tokens do socket.dev). Ambos os interruptores abaixo permanecem desativados até ser introduzida uma chave, e uma chave vazia desativa totalmente o socket.dev, independentemente dos interruptores. A chave é armazenada apenas no lado do anfitrião e nunca entra na VM.

• Bloquear pacotes comprometidos (scripts de instalação maliciosos, sinalizados como malware, typosquats, telemetria suspeita) — bloqueia com base em sinais de risco de cadeia de fornecimento com forma de ataque: indicadores definitivos de malware com qualquer gravidade; sinais mais ruidosos como código ofuscado, scripts de instalação, typosquatting ou acesso a shell apenas quando o socket.dev os classifica como altos ou críticos (para que um pacote com um postinstall benigno não seja bloqueado). Desativado por predefinição.
• Bloquear pacotes com CVEs conhecidas — bloqueia com base no conjunto de vulnerabilidades do socket.dev igual ou superior ao Limiar de bloqueio de CVE (predefinição Alta e acima; o seletor está desativado até este interruptor estar ativado). Desativado por predefinição.

Nota: O socket.dev não tem suporte para Cargo. Com a filtragem do socket.dev ativada, cada artefacto do crates.io não produz veredito e aciona a retenção de pacotes não verificados descrita abaixo — efetivamente um pedido por versão de crate. Desative o socket.dev para espaços de trabalho com muito Rust, ou conte com ter de responder a pedidos.

Delpi

Com o Delpi selecionado e uma chave de API introduzida (a hiperligação Obter uma chave de API abre landh.tech), o proxy reencaminha todos os pedidos ao registo npm — metadados, tarballs, auditoria, tudo o que seja endereçado a registry.npmjs.org — para o registo seguro compatível com npm do Delpi em depi-npm-proxy.landh.tech, anexando a sua chave como um token Bearer injetado pelo anfitrião. O Delpi serve pacotes previamente validados, pelo que, em vez de uma consulta por pacote, todo o registo é substituído. As outras camadas (restrição por idade, OSV, remoção de scripts) continuam a aplicar-se por cima: o Delpi substitui o socket.dev, não a política local.

Enquanto o campo da chave estiver vazio, um aviso laranja indica Introduza uma chave de API — o Delpi permanece desativado sem uma. Se o Delpi rejeitar a chave, a instalação npm falha com um erro claro da Bromure, a rejeição é registada no Registo de Segurança e é emitido um alerta único. O Delpi afeta apenas o npm; os outros ecossistemas não são tocados.

Scripts de instalação

Remover preinstall / install / postinstall / prepare dos tarballs npm em tempo real remove os hooks que os pacotes npm maliciosos usam para executar código no momento da instalação. A Bromure reescreve o tarball em trânsito — remove as chaves de script do package.json do pacote, recalcula a soma de verificação do tar, volta a comprimir com gzip — e limpa os hashes de integridade dos metadados do registo, de modo que a própria verificação do npm continue a passar em instalações não fixadas. As remoções são registadas a laranja no Registo de Segurança; em qualquer falha de análise, o tarball original passa intocado (esta camada falha de forma aberta em vez de quebrar uma instalação bem formada).

Os compiladores de bindings que realmente necessitam de scripts de instalação (better-sqlite3, node-canvas, …) vão em Permitir scripts de instalação para, no formato npm:better-sqlite3.

Desativado por predefinição; apenas npm (os sdists do PyPI nunca são reescritos — o setup.py é código arbitrário).

Instalações fixadas por ficheiro de bloqueio

As instalações fixadas por ficheiro de bloqueio (npm ci, pip --require-hashes) fixam os hashes de integridade dos tarballs no ficheiro de bloqueio, pelo que a Bromure não pode reescrever esses tarballs sem quebrar a verificação. Por predefinição, passam sem modificação e silenciosamente.

Ative Perguntar antes de deixar passar tarballs fixados por ficheiro de bloqueio sem modificação (npm ci, pip --require-hashes) para ser questionado em vez disso: a primeira obtenção fixada por ficheiro de bloqueio de um lote apresenta uma caixa de diálogo no anfitrião intitulada Pass through npm ci (lockfile-pinned install) from workspace "<name>"? com as opções Permitir durante 15 minutos, Permitir uma vez, Permitir durante o resto da sessão e Não permitir. Todo o lote segue a decisão (as obtenções concorrentes agrupam-se num único pedido); negar bloqueia com um 451 e é memorizado durante 60 segundos.

Nota: Embora o rótulo mencione pip --require-hashes, a deteção está atualmente implementada apenas para o npm ci do npm — as instalações do pip fixadas por hash não acionam o pedido.

Quando uma fonte de reputação está inacessível

Se uma fonte de reputação ativada (OSV ou socket.dev) não conseguir produzir um veredito — rede em baixo, limite de taxa atingido, falha de autenticação, ecossistema não suportado — a Bromure falha de forma fechada em vez de permitir silenciosamente. O descarregamento é retido e uma caixa de diálogo pergunta, por pacote e versão, se aceita o pacote não verificado; negar bloqueia com um 451. As aprovações são indexadas por package@version, pelo que uma resposta não pode abranger todo um grafo de dependências.

Trata-se de uma proteção deliberada contra um atacante que induza limites de taxa para introduzir pacotes furtivamente. Também significa que o trabalho totalmente offline com OSV ou socket.dev ativado irá pedir confirmação para cada pacote não em cache — desative essas camadas para uso offline. Em sessões SSH/CLI sem interface, a mesma pergunta é feita dentro do tmux do espaço de trabalho; a ausência de resposta significa negar.

Referência de definições

As chaves de API introduzidas aqui residem no profile.json do espaço de trabalho no anfitrião (nunca na VM); todas as chamadas de reputação têm origem no proxy do anfitrião. Para o Registo de Segurança, os detalhes de interceção por ecossistema e o alarme de deteção de comprometimento que acompanha estas políticas, consulte o capítulo de proteção da cadeia de fornecimento.