Lemos configuração. Nunca os seus dados.
Uma ferramenta de segurança que pede acesso à sua cloud precisa merecer esse acesso. Esta página lista exatamente o que o Basalt lê, o que guarda e o que nunca vai fazer, para que seu time confira linha por linha.
Somente leitura, garantido no código
O conector da AWS só permite uma lista fixa de operações. Qualquer outra, incluindo leituras de dados como s3:GetObject, é bloqueada antes de a requisição sair do scanner. Um teste automatizado verifica que o scanner nunca chama nada fora dessa lista.
Credenciais temporárias
Assumimos uma role criada por você, com um ExternalId único por cliente contra o problema do confused deputy. As credenciais vêm do STS e expiram em uma hora. Nenhuma access key é armazenada.
Valores de secrets nunca armazenados
Lambda e ECS devolvem os valores das variáveis de ambiente junto com a configuração. Classificamos cada um em memória (parece um secret: sim ou não) e descartamos. Um teste planta secrets falsos e verifica que eles não aparecem em nenhuma saída.
Toda leitura registrada
Cada chamada de API de um scan é registrada com serviço, operação, região e horário, e guardada junto com o scan, para podermos mostrar exatamente o que foi lido na sua conta.
Código analisado, nunca executado
Os repositórios são analisados pela árvore sintática. Nada do seu código é importado ou executado do nosso lado.
Isolamento entre clientes
Toda linha de cliente no nosso banco de dados é protegida por row-level security do Postgres vinculada ao workspace, além das verificações na aplicação.
As permissões exatas na AWS
Catorze leituras de configuração e uma negação explícita de leitura de dados como segunda garantia, mesmo que a role receba mais acesso por engano no futuro.
| Ação | Para quê |
|---|---|
iam:GetAccountAuthorizationDetails | Roles, policies inline e gerenciadas, relações de trust |
iam:GetPolicy, iam:GetPolicyVersion | Conteúdo das policies gerenciadas pela AWS anexadas às suas roles |
s3:ListAllMyBuckets | Lista de buckets |
s3:GetBucketPolicy, s3:GetBucketPublicAccessBlock | Se um bucket é público |
s3:GetBucketTagging | Sensibilidade a partir das suas próprias tags |
dynamodb:ListTables | Nomes das tabelas, sem itens |
secretsmanager:ListSecrets | Nomes e tags dos secrets, nunca os valores |
lambda:ListFunctions, lambda:GetFunctionUrlConfig | Funções, a role de cada uma, URLs públicas |
ecs:ListTaskDefinitionFamilies, ecs:DescribeTaskDefinition | Roles das tasks e nomes das variáveis de ambiente |
ec2:DescribeInstances | Instance profiles (roles) das instâncias |
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "BasaltReadConfiguration",
"Effect": "Allow",
"Action": [
"iam:GetAccountAuthorizationDetails",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"s3:ListAllMyBuckets",
"s3:GetBucketPolicy",
"s3:GetBucketPublicAccessBlock",
"s3:GetBucketTagging",
"dynamodb:ListTables",
"secretsmanager:ListSecrets",
"lambda:ListFunctions",
"lambda:GetFunctionUrlConfig",
"ecs:ListTaskDefinitionFamilies",
"ecs:DescribeTaskDefinition",
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Sid": "BasaltNeverReadsData",
"Effect": "Deny",
"Action": [
"s3:GetObject*",
"secretsmanager:GetSecretValue",
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:Scan",
"ssm:GetParameter*",
"kms:Decrypt",
"rds-data:ExecuteStatement"
],
"Resource": "*"
}
]
}
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::<BASALT_ACCOUNT_ID>:root" },
"Action": "sts:AssumeRole",
"Condition": { "StringEquals": { "sts:ExternalId": "<YOUR_EXTERNAL_ID>" } }
}]
}
Prefere não compartilhar nenhum valor de variável de ambiente? Remova lambda:ListFunctions e ecs:DescribeTaskDefinition. O scan continua rodando sem a análise de compute, e o relatório indica a permissão que faltou.
O que guardamos
Só o que a análise precisa para mostrar um caminho e comprová-lo.
| Dado | Guardado |
|---|---|
| Nomes e ARNs de recursos, roles, policies, relações de trust | Sim |
| O grafo: componentes e o que cada um alcança | Sim |
| Evidência: caminho do arquivo, número da linha, recurso | Sim |
| Nomes de secrets e de variáveis de ambiente | Só os nomes |
| Valores de secrets e de variáveis de ambiente, chaves e tokens | Nunca |
| Objetos, linhas ou itens dos seus data stores | Nunca lidos |
| Access keys da AWS | Nunca; só credenciais temporárias do STS |
Rode do seu lado
O scanner funciona sem a nossa cloud. Rode a CLI contra um repositório ou Terraform, ou contra a AWS com as suas próprias credenciais e a mesma trava de somente leitura. Nada sai da sua máquina a menos que você a vincule a um workspace.
# same allow-list, your own credentials
basalt scan-aws --use-current-credentials --profile auditLimites conhecidos
Publicamos o que a análise ainda não cobre. Quando um destes pontos pode mudar um resultado, o passo é marcado como incerto em vez de reportado com alta confiança.
- SCPs da organização, session policies e a maior parte das resource policies ainda não são avaliadas (as bucket policies públicas são).
- O Block Public Access é verificado por bucket, não no nível da conta.
- As URLs de funções Lambda são verificadas só em
$LATEST.
Quem somos, sem rodeios
Somos uma empresa em estágio inicial. É aqui que estamos hoje.
Vocês têm SOC 2?
Ainda não. Planejamos o SOC 2 Type I conforme nossos primeiros clientes enterprise precisarem. Até lá, respondemos o seu questionário de fornecedor por inteiro e mostramos como cada controle funciona hoje.
Quais suboperadores tratam os nossos dados?
Recursos de IA como o assistente de terminal usam a API Claude, da Anthropic, que não treina modelos com dados da API segundo seus termos comerciais. Nossos provedores de hospedagem e de banco de dados serão listados aqui antes de guardarmos dados de clientes com eles.
Por quanto tempo vocês guardam os resultados dos scans?
Enquanto o seu workspace existir, e apagamos quando você pedir. Uma retenção menor pode ser definida no contrato.
O Basalt vai alterar a nossa infraestrutura?
Não. Nunca escrevemos na sua conta de cloud. As correções são mudanças de código, aplicadas pela CLI em um branch só depois que você aprova o diff, e nunca no branch padrão.
Encontrou uma vulnerabilidade no Basalt?
Conte para a gente em particular e confirmamos o recebimento em até dois dias úteis. Pedimos um prazo razoável para corrigir antes de você publicar. Não tomaremos nenhuma medida contra pesquisa feita de boa-fé.