O gerenciamento de dependências deixou de ser apenas uma questão de baixar bibliotecas e configurar paths. Em projetos modernos, especialmente nos que sustentam operações críticas, também precisamos responder com precisão: quais componentes entraram em uma versão, de onde vieram, qual revisão foi utilizada, quais licenças foram declaradas e se uma vulnerabilidade conhecida realmente afeta o produto entregue.

É justamente nesse ponto que as versões 1.1.0 e 1.2.0 do Boss4D representam um avanço importante. Além de tornar o processo de build mais previsível, o Boss4D agora oferece uma base nativa para geração de SBOM, rastreabilidade de dependências, evidências de integridade, análise de vulnerabilidades por VEX e auditoria de releases. Na versão 1.2.0, essa evolução também alcança projetos Lazarus, permitindo que dependências Delphi e Free Pascal convivam em um fluxo de build mais consistente.

Neste artigo, vamos entender o que mudou, por que essas mudanças são importantes e como utilizar os novos recursos no dia a dia.

O que é uma SBOM e por que ela importa

SBOM é a sigla para Software Bill of Materials, ou lista de materiais de software. Podemos entendê-la como um inventário estruturado e legível por máquina de tudo que participa da composição de uma aplicação.

Uma SBOM bem formada ajuda a responder perguntas que uma simples pasta de fontes não consegue responder de maneira confiável:

• quais versões e revisões exatas das dependências entraram na release;
• de qual repositório cada componente foi obtido;
• qual checksum representa os arquivos efetivamente instalados;
• quais licenças foram declaradas e qual é a origem dessa informação;
• quais componentes podem estar relacionados a uma vulnerabilidade recém-divulgada;
• se o inventário publicado corresponde à versão entregue ao cliente.

No ecossistema Delphi, essa necessidade é ainda mais evidente. Uma aplicação pode combinar fontes instaladas por meio do Boss4D, pacotes do GetIt, RTL e compiladores do RAD Studio, SDKs comerciais, DLLs, DCUs e BPLs. Sem um inventário formal, grande parte desse conhecimento permanece espalhada em scripts, máquinas de desenvolvimento, documentos internos ou simplesmente na memória da equipe.

É importante fazer uma distinção: uma SBOM aumenta a transparência e fornece evidências para processos de conformidade e auditoria, mas não é, isoladamente, uma certificação legal, uma garantia de ausência de vulnerabilidades ou uma assinatura digital da release.

Boss4D 1.1.0: a base de conformidade e auditoria

A versão 1.1.0 introduziu o comando boss4d sbom e uma arquitetura neutra de inventário. A mesma evidência pode ser exportada nos dois formatos mais utilizados pelo mercado:

• CycloneDX 1.7 em JSON;
• SPDX 2.3 em JSON.

O gerador é nativo e funciona offline. Não exige Node.js, serviço em nuvem, scanner comercial ou acesso à internet para criar o inventário básico.

Para gerar documentos durante o desenvolvimento:

boss4d sbom --format cyclonedx --output bom.cdx.json --validate
boss4d sbom --format spdx --output bom.spdx.json --validate

O primeiro comando produz um documento CycloneDX; o segundo produz SPDX. A opção --validate verifica a consistência do documento antes de concluir a operação.

Um lock file que registra evidências

Para que uma SBOM seja útil em auditoria, não basta repetir o que o desenvolvedor desejava instalar. É preciso registrar o que foi efetivamente resolvido.

Por isso, o boss-lock.json passou ao schema v2 e agora armazena informações como:

• identidade canônica do repositório;
• revisão e referência Git resolvidas;
• checksum tipado;
• origem da informação de licença;
• grafo de dependências;
• artefatos compilados declarados;
• evidências do componente raiz.

O boss.json continua representando a intenção do projeto. O boss-lock.json representa a resolução efetiva e torna-se a evidência autoritativa para a release.

Locks antigos continuam legíveis e são promovidos ao schema v2 quando salvos novamente, facilitando a migração de projetos existentes.

Geração estrita e reproduzível para releases

Durante uma release, é possível gerar a SBOM usando somente o lock file:

boss4d sbom --format cyclonedx --lock-only --strict --validate --reproducible `
  --type application --output dist/sbom/app.cdx.json `
  --attestation-output dist/sbom/app.cdx.intoto.json

boss4d sbom --format spdx --lock-only --strict --validate --reproducible `
  --type application --output dist/sbom/app.spdx.json `
  --attestation-output dist/sbom/app.spdx.intoto.json

Nesse fluxo:

• --lock-only elimina a dependência do manifesto durante a publicação;
• --strict interrompe o processo se faltarem identidade, revisão, checksum, grafo ou evidências da raiz;
• --validate rejeita documentos inconsistentes;
• --reproducible remove dados voláteis e estabiliza a ordenação;
• --attestation-output gera uma attestation destacada ligada ao SHA-256 exato da SBOM.

O resultado é um artefato adequado para ser publicado ao lado do instalador e da tag que ele descreve.

CycloneDX, SPDX e VEX

CycloneDX e SPDX atendem necessidades semelhantes, mas possuem históricos e ecossistemas diferentes. Ao gerar ambos a partir de um modelo interno neutro, o Boss4D evita que o formato escolhido altere a forma como as dependências são resolvidas.

O suporte a VEX, ou Vulnerability Exploitability eXchange, complementa a SBOM. Enquanto a SBOM informa que um componente está presente, o VEX registra a análise sobre a aplicabilidade de uma vulnerabilidade naquele contexto.

Um exemplo de entrada VEX offline:

{
  "vulnerabilities": [
    {
      "id": "CVE-2099-0001",
      "component": "meu-projeto",
      "state": "not_affected",
      "detail": "O caminho de código afetado não está presente.",
      "source": "Revisão interna de segurança"
    }
  ]
}

Ela pode ser incorporada ao documento CycloneDX:

boss4d sbom --format cyclonedx --strict --validate --reproducible `
  --vex security.vex.json --output dist/sbom/app.vex.cdx.json `
  --attestation-output dist/sbom/app.vex.cdx.intoto.json

Os estados aceitos são affected, not_affected, fixed e under_investigation.

O Boss4D não consulta uma base de vulnerabilidades nem substitui uma solução SCA. O documento VEX deve ser produzido ou revisado por um processo de segurança responsável. Em outras palavras: a ferramenta registra e transporta a decisão; ela não inventa a decisão.

Attestations e verificação de integridade

As attestations geradas seguem o formato in-toto Statement v1 e registram o digest SHA-256 do documento. Isso permite detectar qualquer alteração nos bytes da SBOM depois da sua geração.

Uma attestation pode ser verificada posteriormente:

boss4d sbom --format cyclonedx --lock-only --strict --validate --reproducible `
  --type application --output dist/sbom/app.cdx.json `
  --verify-attestation dist/sbom/app.cdx.intoto.json

Essa verificação comprova a integridade do conteúdo associado ao digest. A implementação atual não deve ser confundida com uma assinatura digital vinculada à identidade de uma pessoa ou organização, nem com publicação automática em um transparency log.

Evidências do ambiente Delphi

Além das dependências gerenciadas diretamente, o Boss4D pode coletar evidências adicionais:

boss4d sbom --format cyclonedx --strict --validate `
  --include-getit --include-toolchain --include-artifacts `
  --output ambiente-build.cdx.json

• --include-getit inventaria os pacotes GetIt instalados;
• --include-toolchain registra evidências de dcc32, dcc64 e System.dcu para Win32 e Win64;
• --include-artifacts calcula hashes dos artefatos declarados, como DLL, BPL, DCP e DCU.

Esses coletores são opcionais porque representam o ambiente da máquina. Um pacote GetIt instalado, por exemplo, não prova automaticamente que ele foi utilizado pela aplicação. Essa separação evita transformar uma descoberta ambiental em uma afirmação incorreta de dependência.

Boss4D 1.2.0: builds mais determinísticos

Se a versão 1.1.0 criou a base de conformidade, a versão 1.2.0 fortaleceu a qualidade das evidências produzidas.

Uma auditoria só é confiável quando a identidade de cada componente permanece estável e quando o checksum descreve exatamente os bytes utilizados. Por isso, a 1.2.0 adicionou várias melhorias de build determinístico.

Armazenamento sem colisões

Dependências diferentes podem possuir o mesmo nome de repositório. Antes, dois projetos chamados common, por exemplo, poderiam disputar o mesmo diretório físico.

Agora, o nome da pasta inclui um prefixo derivado da identidade canônica do repositório:

modules/common-a1b2c3d4
modules/common-f8e7d6c5

URLs HTTPS e SSH que representam o mesmo repositório convergem para a mesma identidade. Já repositórios diferentes permanecem separados. O detalhe do diretório físico não altera os identificadores registrados na SBOM e no lock.

Normalização de fontes antes do checksum

Arquivos textuais Delphi e Lazarus passam por normalização CRLF depois do checkout e antes do cálculo SHA-256. Isso inclui extensões como .pas, .inc, .dfm, .dpk, .dproj, .lpi e .lpk.

Assim, o checksum exportado para o lock, CycloneDX e SPDX representa os bytes realmente instalados na máquina de build, reduzindo divergências causadas apenas por finais de linha diferentes entre sistemas ou configurações Git.

Arquivos binários são detectados e preservados. Um DFM binário, por exemplo, não é tratado como texto.

Toolchain e ordem de build previsíveis

A plataforma efetiva agora segue uma precedência explícita:

1. argumento boss4d install --platform;
2. toolchain.platform no boss.json raiz;
3. primeira plataforma declarada em engines.platforms;
4. fallback para Win32.

Também é possível selecionar a versão do compilador por toolchain.compiler. Quando uma dependência declara uma lista de projetos, somente esses projetos são compilados, exatamente na ordem informada.

Essa previsibilidade é importante porque reduz decisões implícitas que poderiam fazer duas máquinas compilarem conjuntos diferentes de artefatos.

Preservação de condicionais em pacotes Delphi

A atualização automática da cláusula requires de arquivos DPK passou a preservar comentários e diretivas condicionais existentes. Em vez de reconstruir toda a cláusula, o Boss4D acrescenta apenas as dependências ausentes.

É uma mudança pequena na aparência, mas relevante para pacotes que suportam diferentes versões do compilador ou plataformas por meio de compilação condicional.

Agora também com suporte a Lazarus

Uma das principais novidades da versão 1.2.0 é o suporte nativo ao roteamento de projetos Lazarus.

Dependências podem declarar projetos Delphi e Lazarus em sua configuração. O Boss4D reconhece:

• .dproj para projetos Delphi, compilados com MSBuild;
• .lpi para projetos Lazarus;
• .lpk para pacotes Lazarus.

Projetos .lpi e .lpk são encaminhados ao lazbuild, que precisa estar disponível no PATH da máquina.

Quando a propriedade projects é informada, os arquivos são compilados na ordem declarada. Os caminhos são validados para garantir que existam e permaneçam dentro da raiz da dependência.

Isso abre espaço para workspaces mistos, nos quais uma solução Delphi pode consumir bibliotecas compatíveis com Free Pascal ou manter dependências com projetos específicos para cada toolchain.

O suporte não significa que o compilador Delphi e o Lazarus sejam intercambiáveis. Cada formato continua sendo encaminhado para sua ferramenta correta. O ganho está em oferecer um único fluxo de resolução, ordenação e rastreabilidade para ambos.

Criação protegida de novos projetos

A versão 1.2.0 também adicionou scaffolding para aplicações e pacotes:

boss4d new app MeuConsole
boss4d new package MinhaBiblioteca --path D:\trabalho\MinhaBiblioteca

O Boss4D cria o manifesto, as pastas src e tests e o fonte inicial. O destino precisa estar vazio, evitando que arquivos existentes sejam sobrescritos acidentalmente.

Como isso melhora conformidade e auditoria na prática

As duas versões formam uma cadeia de evidências:

boss.json
   ↓ intenção declarada
boss4d install
   ↓ resolução, revisão, normalização e checksums
boss-lock.json v2
   ↓ evidência autoritativa
CycloneDX / SPDX
   ↓ inventário publicável
VEX + attestation + SHA256SUMS
   ↓ contexto de vulnerabilidade e integridade
Release do GitHub

Esse fluxo ajuda equipes de desenvolvimento, segurança e auditoria a trabalhar sobre os mesmos dados. Quando uma vulnerabilidade é divulgada, a organização pode consultar a SBOM da release afetada, localizar os componentes candidatos, documentar a análise por VEX e publicar uma atualização sem reconstruir o inventário manualmente.

Ele também reduz respostas vagas em processos de homologação. Em vez de afirmar apenas que “a aplicação usa determinada biblioteca”, passa a ser possível informar repositório, revisão, checksum, relacionamento no grafo e artefato de release correspondente.

Fluxo recomendado para uma release auditável

Um fluxo prático pode seguir estas etapas:

1. executar boss4d install e versionar o boss-lock.json v2;
2. executar testes Win32 e Win64;
3. gerar CycloneDX e SPDX com --lock-only, --strict, --validate e --reproducible;
4. gerar as attestations in-toto associadas;
5. validar os formatos com ferramentas externas;
6. compilar os artefatos em staging e somente promovê-los após todas as validações;
7. gerar SHA256SUMS.txt para os arquivos publicados;
8. publicar instalador, SBOMs, attestations e checksums junto da tag exata da versão;
9. manter o VEX como documento revisável durante todo o ciclo de vida da release.

A release 1.2.0 do próprio Boss4D já segue esse modelo. Ela publica o instalador, os documentos CycloneDX e SPDX, as duas attestations e o arquivo de checksums na mesma página da versão.

Qualidade da versão 1.2.0

O fechamento da versão 1.2.0 foi validado com:

• 79 testes aprovados em Win32;
• 79 testes aprovados em Win64;
• validação de CycloneDX, SPDX, VEX e reprodutibilidade;
• compilação da CLI e GUI em Win32 e Win64;
• compilação dos plugins para Delphi 11, 12 e 13;
• geração do instalador com Inno Setup;
• Sonar Quality Gate aprovado no commit final, sem novas violações.

Conclusão

As versões 1.1.0 e 1.2.0 levam o Boss4D além do papel tradicional de gerenciador de dependências.

A 1.1.0 introduziu inventários CycloneDX e SPDX, lock com evidências, geração reproduzível, VEX, attestations e coletores para o ambiente Delphi. A 1.2.0 consolidou essa base com armazenamento sem colisões, normalização determinística, seleção previsível de toolchain, builds ordenados e suporte a projetos Lazarus.

O resultado é um fluxo mais transparente e auditável para aplicações Object Pascal. Delphi e Lazarus continuam usando seus compiladores e ecossistemas próprios, mas agora podem participar de uma cadeia comum de resolução, build e evidências de software.

Para empresas que precisam responder a auditorias, avaliar vulnerabilidades ou simplesmente conhecer melhor aquilo que entregam aos clientes, essa mudança representa um passo importante: sair do conhecimento implícito e passar a trabalhar com evidências verificáveis.

O Boss4D é open source. A versão 1.2.0, o instalador e todos os artefatos de conformidade estão disponíveis no GitHub:

• Projeto Boss4D no GitHub
• Release 1.2.0
• Documentação de SBOM
• Melhorias de build e suporte a Lazarus