Este guia serve como referência para desenvolvedores que desejam implementar builds verificados para seus programas na Solana. Vamos abordar o que são builds verificados, como usá-los, considerações especiais e melhores práticas para garantir a autenticidade do seu programa na blockchain.

O que são builds verificados?

Builds verificados garantem que o programa executável que você implanta na rede Solana corresponde ao código-fonte em seu repositório. Com isso, desenvolvedores e usuários podem ter confiança de que o programa em execução na blockchain corresponde exatamente à base de código pública, promovendo transparência e segurança.

O processo de verificação envolve comparar o hash do programa na blockchain com o hash do programa compilado localmente a partir do código-fonte. Isso garante que não haja discrepâncias entre as duas versões.

Embora um build verificado não deva ser considerado mais seguro que um build não verificado, o build permite que os desenvolvedores verifiquem por conta própria se o código-fonte corresponde ao que está implantado na blockchain. Usando o código-fonte, um desenvolvedor pode então validar o que o código executa ao enviar uma transação.

O pipeline de builds verificados foi concebido e é mantido pela Ellipsis Labs e OtterSec. Para mais detalhes, siga o guia no repositório original de builds verificados e o processo de verificação de build diretamente na suíte de ferramentas Anza, quando suportado.

Como funciona?

O processo de verificação é feito comparando o hash do programa na blockchain com o hash do programa construído localmente a partir do código-fonte. Você constrói seu programa em um ambiente controlado usando a CLI Solana Verify e Docker. Isso garante que o processo de construção seja determinístico e consistente em diferentes sistemas. Depois de ter o executável, você pode implantá-lo na rede Solana. Durante o processo de construção, uma PDA do programa verify será criada. Esta PDA contém todos os dados necessários para verificar o programa. A PDA contém o endereço do programa, URL do git, hash do commit e os argumentos usados para construir o programa.

Usando os dados na PDA, todos podem executar o comando do programa verify localmente e verificar se o programa foi construído a partir do código-fonte fornecido. Então todos podem verificar por si mesmos de forma completamente confiável ou podem executar sua própria API de verificação mantida pela OtterSec para fornecer um ponto de acesso fácil para os usuários verificarem a verificação. Você já pode ver essas chamadas de API sendo usadas no Solana Explorer e SolanaFM, entre outros lugares.

Por que devo usar builds verificadas?

O uso de builds verificadas proporciona os seguintes benefícios:

• Segurança: Garante que o programa em execução na blockchain corresponde ao código-fonte, evitando alterações maliciosas.

• Transparência: Permite que outros usuários e desenvolvedores validem que o programa na blockchain é confiável, comparando-o com a base de código pública.

• Confiança: Aumenta a confiança do usuário, pois as builds verificadas demonstram que o comportamento do seu programa na blockchain está alinhado com seu código público. Ao construir programas verificáveis, você minimiza os riscos associados à execução de código não autorizado ou malicioso. Também garante que você siga as melhores práticas e ofereça aos pesquisadores de segurança uma maneira fácil de entrar em contato com você. Além disso, carteiras e outras ferramentas podem permitir transações do seu programa mais facilmente desde que esteja verificado.

• Descoberta: quando você fornece uma compilação verificada do seu programa, todos podem encontrar seu código-fonte, documentação, SDK do programa ou IDL e também podem facilmente entrar em contato com você via GitHub caso haja algum problema.

Como criar compilações verificadas?

Para criar compilações verificadas, você precisará seguir estas etapas:

Resumo:

• Faça commit do seu código em um repositório público
• Construa uma compilação verificada no Docker
• Implante a compilação verificada
• Verifique o programa implantado na API pública

Se você verificar seu programa que não foi compilado em um contêiner Docker, provavelmente falhará porque as compilações de programas Solana não são determinísticas em diferentes sistemas.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

cargo install solana-verify

cargo install solana-verify --version $VERSION

cargo install solana-verify --git https://github.com/Ellipsis-Labs/solana-verifiable-build --rev 13a1db2

[workspace]
members = ["program/programs/*"]
resolver = "2"

[profile.release]
overflow-checks = true
lto = "fat"
codegen-units = 1

[profile.release.build-override]
opt-level = 3
incremental = false
codegen-units = 1

[package]
name = "waffle"
version = "0.1.0"
edition = "2021"

[lib]
name = "waffle"
crate-type = ["cdylib", "lib"]

[dependencies]
solana-program = "2.1.0"

solana-verify build

solana-verify build --library-name $PROGRAM_LIB_NAME

solana-verify get-executable-hash target/deploy/$PROGRAM_LIB_NAME.so

solana program deploy -u $NETWORK_URL target/deploy/$PROGRAM_LIB_NAME.so --program-id $PROGRAM_ID --with-compute-unit-price 50000 --max-sign-attempts 100 --use-rpc

solana-verify get-program-hash -u $NETWORK_URL $PROGRAM_ID

solana-verify verify-from-repo -u $NETWORK_URL --program-id $PROGRAM_ID https://github.com/$REPO_PATH --commit-hash $COMMIT_HASH --library-name $PROGRAM_LIB_NAME --mount-path $MOUNT_PATH

solana-verify remote submit-job --program-id <program-id> --uploader <address>

solana-verify remote get-job --job-id <job-id>

Como verificar seu programa quando ele é controlado por um Multisig como o Squads

Para que a verificação remota funcione, você precisa gravar os dados de verificação em uma PDA assinada pela autoridade do programa. Se o seu programa for controlado por um multisig, você pode exportar essa transação de gravação de PDA e enviá-la pelo Squads Protocol ou por outra solução multisig de sua preferência.

solana-verify build

solana config set --url "PayedMainnetRPCAddress" // the public endpoint will be rate limited too much
solana program deploy target/deploy/verify_squads.so

solana-verify verify-from-repo https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD

solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader <your program authority> --encoding base58 --compute-unit-price 0

P6vBfcPaaXb8fZoT3NBAYEcdtEj7tubA1k2gBxmFKZ3UWF5YyrmDMFTvLKALCJoUuRsPAjMckudYruCu3eeWQtuDrFbEMLxLFutnKXac974fnkMivcwUdY66VLjbxQT6ATmcy7F4hBtz1G4P1h6iBJLhb8WtrtgY3i4qq45MUEb7RjuMEfUFXKrNgPdGxkz5xvMHq3dxKRcpmEK5k2DkeW6SUQYBVe19Ga3B9GyhTX8k3CMt9JCEah13WyRnQd8GjoK6sTEvGJym6xDNvmd8yiJYSNcaYwEJsjHEUf4Yh6kAC7ki2KRvVAr3NVe1gjqK9McrwSQjtUatvydTG8Zovcr7PPUEMf3yPMgKXjZLB2QpkH63yTTYdNAnWFuv9E6b6nYRqye5XcNi436yKw5U14fXh65yK34bgYLi9328UT1huJELsJU9BRGnGUmb6GWp6c2WL5BhnzgNTSnt9TXFfEgUMzhvKzpVBxLP44hwqqBdyUhHFysCF37531PnmiESq8x1xou23xJ6FcQbc199754MkqQd7tX9CUznGzAEqHGkzn3VBoJnojsKtgYmiTYbdRsT1CU18MbYEE7WvGAvXyxxbpNzbAcc94HrnM6cqRGmwhEBroPfFghTdmzg9D

solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD
--uploader <your program authority>

solana-verify build
solana program write-buffer target/deploy/verify_squads.so --with-compute-unit-price 50000 --max-sign-attempts 50

solana program set-buffer-authority Fu3k79g53ZozAj47uq1tXrFy4QbQYh7y745DDsxjtyLR --new-buffer-authority 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

Verification request sent with request id: b63339d2-163e-49ac-b55d-3454c1c2b5b3
Verification in progress... ⏳ [00:18:02] ✅ Process completed. (Done in 18
minutes) Program 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD has been verified.
✅ The provided GitHub build matches the onchain hash. On Chain Hash:
96f8c3d9400258f7759408d1f6f8435b4a24d9b52f5a0340d97907e567cb8773 Executable
Hash: 96f8c3d9400258f7759408d1f6f8435b4a24d9b52f5a0340d97907e567cb8773 Repo URL:
https://github.com/Woody4618/verify-squads/tree/0fb0a2e30c15c51732c0ad5e837975a6f7bbc7ed
Check the verification status at:
https://verify.osec.io/status/6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD Job
url: https://verify.osec.io/job/b63339d2-163e-49ac-b55d-3454c1c2b5b3

Verificar a partir de uma imagem Docker

Você também pode verificar seu programa em uma imagem Docker executando o seguinte comando:

solana-verify verify-from-image -e
examples/hello_world/target/deploy/hello_world.so -i
ellipsislabs/hello_world_verifiable_build:latest -p
2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn

Este comando carrega a imagem armazenada em ellipsislabs/hello_world_verifiable_build:latest e verifica se o hash do caminho do executável no container é o mesmo que o hash do programa onchain fornecido ao comando. Como o build já foi enviado para uma imagem, não é necessário reconstruir completamente o executável, o que pode levar muito tempo.

O Dockerfile que cria a imagem ellipsislabs/hello_world_verifiable_build:latest pode ser encontrado no repositório da Ellipsis Labs /examples/hello_world.

Abaixo está a saída esperada:

Verifying image: "ellipsislabs/hello_world_verifiable_build:latest", on network
"https://api.mainnet.solana.com" against program ID
2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn Executable path in container:
"examples/hello_world/target/deploy/hello_world.so"

Executable hash:
08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Program hash:
08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Executable
matches onchain program data ✅

Exemplo de build verificada

Aqui está um exemplo de verificação de um programa de exemplo com o ID FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv usando o código-fonte deste repositório:

solana-verify verify-from-repo https://github.com/solana-developers/verified-program --url YOUR-RPC-URL --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --mount-path waffle --library-name waffle --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

Por padrão, o comando verify-from-repo utiliza o último commit na branch principal. Você também pode definir um commit específico caso queira continuar trabalhando no repositório usando o parâmetro commit-hash: --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

Quando solicitado, responda sim para enviar sua PDA de verificação onchain. Em seguida, envie um trabalho de verificação remota para a API da OtterSec:

solana-verify remote submit-job --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --uploader <your-upgrade-authority>

Programas populares que já estão verificados

Phoenix

solana-verify verify-from-repo -um --program-id PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY https://github.com/Ellipsis-Labs/phoenix-v1

Saída Final:

Executable Program Hash from repo: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9
Onchain Program Hash: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9
Program hash matches ✅

Squads V3

solana-verify verify-from-repo https://github.com/Squads-Protocol/squads-mpl --commit-hash c95b7673d616c377a349ca424261872dfcf8b19d --program-id SMPLecH534NA9acpos4G6x7uf3LWbCAwZQE9e8ZekMu -um --library-name squads_mpl --bpf

Observe que precisamos especificar o library-name porque o repositório do Squads inclui múltiplos programas. Usamos a flag --bpf porque o squads_mpl foi verificado anteriormente com Anchor.

Saída Final:

Executable Program Hash from repo: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205c
Onchain Program Hash: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205c
Program hash matches ✅

Drift V2

solana-verify verify-from-repo -um --program-id dRiftyHA39MWEi3m9aunc5MzRF1JYuBsbn6VPcn33UH https://github.com/drift-labs/protocol-v2 --commit-hash 110d3ff4f8ba07c178d69f9bfc7b30194fac56d6 --library-name drift

Saída Final:

Executable Program Hash from repo: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828
Onchain Program Hash: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828
Program hash matches ✅

Marginfi V2

solana-verify verify-from-repo -um --program-id MFv2hWf31Z9kbCa1snEPYctwafyhdvnV7FZnsebVacA https://github.com/mrgnlabs/marginfi-v2 --commit-hash d33e649e415c354cc2a1e3c49131725552d69ba0 --library-name marginfi -- --features mainnet-beta

Saída Final:

Executable Program Hash from repo: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5
Onchain Program Hash: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5
Program hash matches ✅

Perguntas frequentes

A minha verificação está a falhar. O que devo fazer?

Verifique estes problemas comuns:

• Signatário errado: Confirme que o seu signatário é a autoridade de atualização do programa executando solana program show YourProgramId
• Nenhum PDA onchain: Execute solana-verify verify-from-repo -um e selecione SIM quando solicitado. Sem fazer o upload do PDA, a API não consegue recuperar os seus metadados de verificação.
• Incompatibilidade de dados do PDA: Atualize o seu PDA se tiver reimplantado o seu programa. Os dados do seu PDA devem corresponder ao programa implantado.
• Hash de commit incorreto: Crie o seu PDA utilizando o hash de commit exato que implantou
• Diferenças no ambiente de compilação: Utilize o Docker com solana-verify ao criar o seu PDA

O hash da minha compilação local não corresponde ao hash onchain. Porquê?

Isto geralmente significa:

• Está a utilizar versões diferentes da toolchain Rust/Solana
• As suas dependências foram atualizadas entre compilações
• Não compilou num contentor Docker
• Fez checkout do commit errado

Corrija isto compilando com solana-verify build no Docker utilizando o commit exato que implantou.

Quanto tempo demorará a minha verificação?

Preveja os seguintes prazos com base no tamanho do seu programa:

• Programas simples: 1 a 5 minutos
• Programas complexos: 5 a 15 minutos
• Programas muito grandes: Até 30 minutos

Acompanhe o seu progresso utilizando o endpoint de estado da tarefa.

O meu programa é imutável (sem autoridade de atualização). Como posso verificá-lo?

Se o seu programa não tiver autoridade de atualização ou tiver sido tornado imutável antes de poder criar um PDA, temos um endereço na lista de permissões para esta situação. Contacte-nos em contact@osec.io e ajudamo-lo a verificar o seu programa.

O que é o PDA e por que razão é importante?

Seu PDA (Program Derived Account) permite verificação sem necessidade de confiança:

• Armazenamento On-Chain: Armazene seus metadados de verificação (URL do repositório, hash do commit, parâmetros de build) onchain em um PDA de propriedade do programa Otter Verify (verifycLy8mB96wd9wqq3WDXQwM4oU6r42Th37Db9fC)
• Vínculo Criptográfico: Seu PDA é derivado do endereço do seu programa, criando um vínculo imutável com seus dados de verificação
• Confiança Descentralizada: Qualquer pessoa pode ler seu PDA e verificar seu programa de forma independente

Por que devo criar o PDA antes de usar a API?

A API funciona apenas com PDAs onchain porque:

• Sem Necessidade de Confiança: A API rejeita dados arbitrários - ela utiliza apenas o que sua autoridade de atualização armazenou onchain
• Mais Simples: Basta fornecer o signatário + program_id; a API obtém todo o restante do seu PDA
• À Prova de Adulteração: Seu PDA cria um registro imutável que qualquer pessoa pode verificar de forma independente
• Prova de Propriedade: Seu signatário deve ser a autoridade de atualização, comprovando criptograficamente que você controla o programa

Com que frequência devo verificar meu programa?

Verifique seu programa:

• Após cada implantação ou atualização
• Quando você atualizar seu repositório de código-fonte
• Não se preocupe em reverificar em outros casos - a API reverifica automaticamente todos os programas a cada 24 horas

O que acontece quando eu atualizo meu programa?

Siga estas etapas após a atualização:

1. A API detecta sua atualização e cancela a verificação do seu programa.
2. Atualize seu PDA com os novos metadados de verificação:

solana-verify verify-from-repo -um \
  --program-id YourProgramId... \
  https://github.com/your-org/your-program

3. Envie uma nova solicitação de verificação usando sua autoridade de atualização
4. A API verificará sua nova versão em relação ao PDA atualizado

Importante: Sempre atualize seu PDA usando sua autoridade de atualização com o novo hash do commit para o programa atualizado.

Posso confiar nos resultados da verificação?

Sim - o sistema foi projetado para ser sem necessidade de confiança e verificável de forma independente:

O Que o Torna Confiável:

• PDA On-Chain: Os seus metadados de verificação residem onchain, sem ser controlados por nenhuma autoridade central
• Prova de Autoridade de Atualização: Apenas a autoridade de atualização do seu programa pode criar/atualizar o PDA
• Verificação Independente: Qualquer pessoa pode verificar lendo o seu PDA e executando solana-verify localmente
• Reverificação Contínua: A API reverifica automaticamente todos os programas a cada 24 horas

Compreenda Estas Limitações:

• A verificação confirma que o código-fonte corresponde à implantação - NÃO que o seu código é seguro
• Revise sempre o código antes de interagir com programas
• Verificado ≠ auditado, ou seguro
• Verifique o repositório e o commit no PDA para confirmar que é de uma fonte confiável

Como posso verificar um programa de forma independente?

Verifique qualquer programa por conta própria lendo o seu PDA onchain e executando a verificação localmente:

Passo 1: Ler o PDA On-Chain

# Install solana-verify if you haven't
cargo install solana-verify

# Get the PDA data
solana-verify list-program-pdas --program-id YourProgramId...

Passo 2: Verificar Localmente

# Verify using the repository and commit & other arguments from the PDA
solana-verify verify-from-repo \
  --program-id YourProgramId... \
  https://github.com/your-org/your-program
  --commit-hash <commit-hash>
  ... (other arguments from the PDA)
# Confirm the hash output matches the onchain program hash

Isso prova:

1. Os metadados do PDA são autênticos (armazenados onchain)
2. O código-fonte no repositório do PDA corresponde ao programa implantado
3. Não é necessário confiar na API - verifique tudo por conta própria onchain

Outra pessoa pode verificar o meu programa sem permissão?

Sim, é por isso que exigimos que o signatário seja a autoridade de atualização. Só consideramos a verificação válida se o signatário for a autoridade de atualização.

O que preciso para criar builds verificáveis?

Instale estas ferramentas:

• Docker (para builds determinísticos)
• Cargo (gerenciador de pacotes Rust)
• Solana Verify CLI: cargo install solana-verify
• Um repositório Git público com o seu código-fonte

Posso verificar repositórios privados?

Não — a verificação requer código-fonte público:

• O seu PDA armazena um URL de repositório público que qualquer pessoa pode acessar
• A verificação sem confiança depende do acesso ao código público
• Os utilizadores precisam de ler o seu código-fonte para entender o que o seu programa faz
• O propósito central é permitir que os utilizadores verifiquem independentemente se o código-fonte corresponde à implementação

Repositórios privados comprometem o modelo central de confiança do sistema de verificação.

Como verifico um programa controlado pelo Squads Multisig?

Siga estes passos para programas controlados por multisig:

# 1. Build and deploy normally
solana-verify build
solana program deploy <your-program.so> --program-id YourProgramId...

# 2. Verify locally first - confirm the hash matches
solana-verify verify-from-repo -um \
  --program-id YourProgramId... \
  https://github.com/your-org/your-program

# 3. Export the PDA creation transaction
solana-verify export-pda-tx \
  --program-id YourProgramId... \
  https://github.com/your-org/your-program

# 4. Execute the PDA transaction through your Squads Multisig interface

# 5. After multisig execution, trigger remote verification
solana-verify remote submit-job \
  --program-id YourProgramId... \
  --uploader YourMultisigAddress...

Importante: Verifique sempre localmente (passo 2) para confirmar que o hash de compilação corresponde antes de exportar a transação PDA.

Conclusão

Utilizar compilações verificadas no Solana garante a integridade e a confiabilidade dos seus programas na rede e permite que os programadores encontrem os seus SDKs diretamente a partir do Solana Explorer. Ao tirar partido de ferramentas como o Solana Verify CLI e o Docker, pode manter compilações verificáveis e seguras que estão alinhadas com o seu código-fonte. Tome sempre as precauções necessárias para utilizar ambientes consistentes e considere soluções de governança para atualizações e implementações seguras.

Segurança + Aviso Legal

Embora as compilações verificadas sejam uma ferramenta poderosa para garantir a integridade dos seus programas Solana, a configuração padrão não é completamente sem confiança. As imagens Docker são criadas e alojadas pela Solana Foundation.

Tenha em atenção que está a compilar o seu projeto numa imagem Docker descarregada e que toda a sua configuração, incluindo potencialmente informações sensíveis, é copiada para essa imagem Docker durante a compilação.

Se pretender uma configuração completamente sem confiança, pode compilar as imagens Docker por conta própria e alojá-las na sua própria infraestrutura. Desta forma, pode ter a certeza de que as imagens Docker não foram adulteradas. Pode encontrar os scripts para criar as suas próprias imagens Docker no repositório de compilações verificadas e pode fazer um fork do mesmo e executar as GitHub Actions por conta própria ou validar que estão corretas.

Além disso, para a verificação remota, você está confiando na API da OtterSec e no Solana Explorer até certo ponto.

A API ou o Solana Explorer pode potencialmente exibir informações incorretas se forem comprometidos.

Se você deseja ter uma configuração completamente sem necessidade de confiança, pode executar a API de Verificação por conta própria ou executar a verificação do programa localmente usando o comando verify-from-repo com os dados de verificação on-chain salvos em uma PDA derivada da autoridade de implantação do programa e do programa de verificação.

O programa de verificação é implantado pela equipe OtterSec e ainda não está congelado, podendo ser atualizado a qualquer momento.

A Solana Foundation, a OtterSec e a equipe da Ellipsis Labs não são responsáveis por quaisquer perdas ou danos que possam ocorrer pelo uso do pipeline de builds verificados.

Security.txt para programas Solana

Além dos builds verificados, você também pode adicionar um arquivo security.txt ao seu programa. No futuro, quando implementado, o security.txt conterá a chave pública do verificador para fácil acesso aos dados de verificação armazenados na PDA de verificação. A PDA contendo todas as informações necessárias para compilar e verificar um programa é derivada do endereço do programa e do pubkey do verificador. Por padrão, este é o mesmo pubkey que compilou e implantou o programa. Mas também pode ser outro pubkey que pode ser especificado no security.txt.

O recurso security.txt permite que os desenvolvedores incorporem informações de contato e segurança diretamente em seus contratos inteligentes Solana. Inspirado pelo securitytxt.org, essa abordagem fornece uma forma padronizada para que pesquisadores de segurança entrem em contato com os mantenedores do projeto, mesmo que conheçam apenas o endereço do contrato.

Por que usar security.txt?

Para muitos projetos, especialmente os menores ou privados, identificar os desenvolvedores apenas pelo endereço do contrato pode ser difícil e demorado. Incorporar um arquivo security.txt no programa garante que os pesquisadores de segurança possam entrar em contato com as pessoas certas facilmente, potencialmente previndo exploits e garantindo relatórios de bugs em tempo hábil.

Como implementar o security.txt

Para adicionar um security.txt ao seu programa Solana, siga as etapas abaixo:

Adicione a dependência solana-security-txt ao seu Cargo.toml:

[dependencies]
solana-security-txt = "1.1.1"

Use a macro security_txt! em seu contrato para definir as informações de segurança. Você pode incluir dados de contato, URLs do projeto e até uma política de segurança. Veja um exemplo:

#[cfg(not(feature = "no-entrypoint"))]
use {default_env::default_env, solana_security_txt::security_txt};

#[cfg(not(feature = "no-entrypoint"))]
security_txt! {
    name: "MyProject",
    project_url: "https://myproject.com",
    contacts: "email:security@myproject.com,discord:security#1234",
    policy: "https://myproject.com/security-policy",

    // Optional Fields
    preferred_languages: "en,de",
    source_code: "https://github.com/solana-developers/solana-game-preset",
    source_revision: "5vJwnLeyjV8uNJSp1zn7VLW8GwiQbcsQbGaVSwRmkE4r",
    source_release: "",
    encryption: "",
    auditors: "Verifier pubkey: 5vJwnLeyjV8uNJSp1zn7VLW8GwiQbcsQbGaVSwRmkE4r",
    acknowledgements: "Thank you to our bug bounty hunters!"
}

Assim que as informações do security.txt estiverem incorporadas ao seu programa, elas poderão ser facilmente consultadas por ferramentas como o Solana Explorer, garantindo que seus dados de contato e segurança estejam disponíveis para qualquer pessoa que deseje reportar possíveis problemas.

Boas práticas

• Use links: Para informações que possam mudar (ex.: dados de contato), é recomendável vinculá-las a uma página web em vez de codificá-las diretamente no contrato. Isso evita a necessidade de atualizações frequentes do programa.

• Verificação: Antes de implantar, verifique o formato e o conteúdo usando a ferramenta query-security-txt, que pode validar tanto programas onchain quanto binários locais:

query-security-txt target/bpfel-unknown-unknown/release/my_contract.so

Ao incorporar informações de contato de segurança diretamente em seu contrato, você facilita o contato dos pesquisadores com você, promovendo maior segurança e comunicação no ecossistema Solana.

Este é um exemplo de como o security.txt aparece no Solana Explorer

O projeto security.txt é mantido pela Neodyme Labs

Você pode verificar o status de verificação e explorar os programas verificados em verify.osec.io.