Executando uma auditoria

O comando buildprint audit executa verificações de segurança locais no workspace da branch do Buildprint sincronizada. Ele é útil antes de alterações arriscadas, antes de devolver uma branch a um usuário ou antes de realizar o merge de uma branch que tenha alterado privacidade, workflows de backend, uploads, autenticação ou configurações do conector de API.

A auditoria é consultiva. Ela relata descobertas programáticas que ainda exigem contexto do produto e revisão humana. Ela não modifica o Bubble, não bloqueia o buildprint apply, não faz deploy para o ambiente live, nem substitui o verificador de problemas nativo do Bubble.

Executar uma auditoria

Execute a auditoria de dentro de um workspace de branch:

buildprint sync
buildprint audit

Use JSON para automação:

buildprint audit --json

O comando lê os arquivos locais atualmente no disco. Se alguém alterou a branch do Bubble no editor após sua última sincronização, execute buildprint sync primeiro.

O que ele verifica

O buildprint audit é atualmente focado em segurança. Ele verifica:

• 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 parecem não ter 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 que não serão executadas como redirecionamentos do lado do servidor.

• Secrets, chaves de API, tokens ou credenciais copiadas em arquivos do workspace, quando o gitleaks está instalado.

No momento, ele não executa verificações gerais de desempenho.

Entendendo os resultados

A saída legível por humanos inclui o caminho, a gravidade, o ID da verificação, o título, a explicação e a sugestão de correção:

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 em JSON tem este formato:

{
  "message": "These audit results are programatic 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 de nível alto não prova que o aplicativo é explorável, mas significa que a configuração deve ser revisada antes da branch ser enviada.

Corrigindo descobertas comuns

Para descobertas de tipos de dados públicos, revise as regras de privacidade do Bubble para o tipo. Adicione uma função everyone apenas para registros e campos 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 workflows de backend públicos, exija autenticação apenas para administradores ou adicione uma condição de workflow que comprove que o chamador está autorizado para a operação específica. Autenticação por si só não é autorização.

Para descobertas de uploader, configure o uploader de arquivo ou imagem como privado e anexe o arquivo enviado a um Thing protegido pelas regras de privacidade do Bubble.

Para descobertas de senha temporária no frontend, mova a atribuição da senha temporária e todos os usos posteriores dessa senha para um workflow de backend. Não exponha o resultado da senha temporária para 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 secrets, 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. Buildprint não lê nem armazena chaves de API ou secrets de plugins privados do Bubble, portanto, os agentes não podem mover esses valores para você.

Escaneamento de secrets

O escaneamento de secrets 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 secrets.

Instale o Gitleaks localmente quando quiser 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 redigidos antes de aparecerem nas descobertas da auditoria.

Limites

O buildprint audit vê apenas o workspace da branch local sincronizada. Alterações diretas no editor do Bubble são invisíveis até que você execute buildprint sync novamente.

As descobertas da auditoria não impedem automaticamente a execução do buildprint apply. Trate a auditoria como uma ferramenta de checklist de lançamento para branches sensíveis à segurança, especialmente ao alterar a privacidade de dados, workflows de backend expostos, uploads, logins, redirecionamentos ou configurações do conector de API.