Todas as coleções

Executando uma auditoria

buildprint audit executa verificações de segurança locais em um workspace de branch Buildprint. Ele pode ser usado especificamente para auditar todo o aplicativo em busca de problemas relacionados à segurança e ao desempenho.

A auditoria é uma proteção (guardrail), não uma barreira de implantação. Ela relata descobertas programáticas que necessitam de contexto do produto e revisão humana.

Quando executá-la

Execute a auditoria após sincronizar a branch Bubble mais recente e após fazer alterações locais:

buildprint sync
buildprint audit

Para fluxos de trabalho de automação ou agentes, emita um JSON estruturado:

buildprint audit --json

O comando deve ser executado de dentro de um workspace de branch Buildprint criado por buildprint project clone <appId> --branch <branch>.

O que ele verifica

O buildprint audit atualmente procura por:

  • Tipos de dados sem regras de privacidade do Bubble.

  • Tipos de dados que concedem acesso público de leitura, busca, anexo ou campo.

  • Workflows de backend públicos que carecem de uma barreira de autorização.

  • Uploaders de arquivos e imagens que armazenam arquivos públicos.

  • Ações de senha temporária executadas em workflows de frontend.

  • Proteções de redirecionamento de página que parecem sensíveis à segurança, mas não serão executadas como redirecionamentos do lado do servidor (server-side).

  • Segredos de API expostos publicamente

As descobertas são classificadas primeiro por gravidade, depois pelo caminho do arquivo e detalhes da verificação, para que os itens de maior risco apareçam no topo.

Entendendo os resultados

A saída legível para humanos inclui o caminho do arquivo, gravidade, ID da verificação, resumo, explicação e correção sugerida:

data_types/orders/type.json
  high [public-data-types] Data type has no privacy rules
    Data type 'Orders' has no privacy_role entries, leaving it publicly readable in Bubble unless another layer blocks access.
    Fix: Add privacy rules for this data type. At minimum, define an everyone role with conditions and only the record and field permissions that should be public.

A saída JSON tem este formato:

{
  "message": "These audit results are programmatic checks. Consider each result in context of the desired application logic",
  "results": [
    {
      "check": "public-data-types",
      "title": "Data type has no privacy rules",
      "message": "Data type 'Orders' has no privacy_role entries, leaving it publicly readable in Bubble unless another layer blocks access.",
      "fix": "Add privacy rules for this data type. At minimum, define an everyone role with conditions and only the record and field permissions that should be public.",
      "severity": "high",
      "path": "data_types/orders/type.json"
    }
  ]
}

A gravidade é intencionalmente conservadora. Uma descoberta high não prova que o aplicativo é explorável, mas significa que a configuração deve ser revisada antes que a branch seja enviada.

Corrigindo descobertas comuns

Para descobertas de tipos de dados públicos, revise as regras de privacidade do Bubble para o tipo de dado. Adicione uma função everyone apenas para campos e registros que sejam intencionalmente públicos. Para dados privados, adicione condições de função ou remova permissões públicas de busca, visualização, anexo e campo.

Para descobertas de workflow de backend públicos, exija autenticação apenas para administradores ou adicione uma condição ao workflow que prove que o chamador está autorizado para a operação específica. Autenticação por si só não é o mesmo que autorização.

Para descobertas de uploader, defina o uploader de arquivo ou imagem como privado e anexe o arquivo carregado a uma Thing protegida por regras de privacidade do Bubble.

Para descobertas de senhas temporárias no frontend, mova a atribuição da senha temporária e cada uso posterior dessa senha para um workflow de backend. Não exponha o resultado da senha temporária a etapas do workflow de frontend.

Para descobertas de redirecionamento, use um workflow Page is loaded cuja primeira e única ação ativa seja uma ação simples de Go to page para outra página. Mantenha a condição avaliável pelo servidor, não envie dados da página e adicione apenas parâmetros de URL estáticos.

Para descobertas de segredos, remova o valor do arquivo do workspace, rotacione-o se ele puder ter sido exposto e armazene-o na configuração privada relevante do API Connector ou do plugin. O Buildprint não lê nem armazena chaves de API privadas do Bubble ou segredos de plugins, portanto, os agentes não podem mover esses valores para você.

Escaneamento de segredos

O escaneamento de segredos usa o gitleaks quando disponível. Se o Gitleaks não estiver instalado, o buildprint audit ainda executará as outras verificações de segurança e pulará o escaneamento de segredos.

Instale o Gitleaks localmente quando desejar que o buildprint audit identifique chaves de API, tokens ou credenciais copiadas no workspace da branch:

brew install gitleaks
buildprint audit

Os resultados do Gitleaks são ocultados antes de aparecerem nas descobertas da auditoria.

Limites

O buildprint audit visualiza apenas o workspace sincronizado da branch local. Alterações diretas no editor do Bubble feitas após a última sincronização ficam invisíveis até que você execute o buildprint sync novamente.

A auditoria não modifica o Bubble, não bloqueia o buildprint apply, não mescla branches nem faz implantações no ambiente live. Ela também não substitui a revisão de privacidade do Bubble, testes manuais ou as Buildprint Reviews. Use-a como uma etapa no checklist de lançamento para branches sensíveis à segurança.

Isso foi útil?