Compras Públicas: Segurança-by-Design Essencial

Introdução

Afirmação ousada: contratar sem exigir segurança-by-design é praticamente abrir o cofre e escrever “leve tudo” no papel.

Quando governos, estados e municípios compram tecnologia — software, serviços em nuvem, dispositivos IoT, sistemas SCADA, plataformas de gestão — eles não estão apenas adquirindo funcionalidades. Estão contratando riscos: dependências de terceiros, cadeias de fornecimento complexas, componentes com vulnerabilidades conhecidas e práticas de desenvolvimento que podem expor dados sensíveis. O problema é sistêmico e real. Em dezembro de 2020, o mundo viu, com o caso SolarWinds, como uma única falha na segurança da cadeia de suprimentos pode comprometer dezenas de agências governamentais e milhares de empresas. Em 2017, o ataque NotPetya se espalhou pelo planeta causando bilhões em perdas e mostrando que componentes terceiros e práticas de manutenção precárias transformam a TI em linha de fogo.

Este artigo foi escrito para gestores de compras públicas, juristas, arquitetos de segurança, auditores, fornecedores e profissionais de segurança que precisam entender como incorporar requisitos de segurança-by-design em processos de contratação pública. Nosso objetivo é ser o recurso definitivo: teoria, legislação, padrões, cláusulas contratuais, modelos técnicos, estudos de caso reais, checklists acionáveis, exemplos de SBOM e até snippets de código para automatizar verificações. Tudo pensado para aplicação prática — não apenas para ser citado em slides.

Ao final deste texto você terá: uma visão histórica e conceitual dos princípios de segurança-by-design; um mergulho técnico nas práticas que fazem essa abordagem funcionar; estudos de caso com lições claras; um guia passo a passo para inserir requisitos em editais e contratos; templates de cláusulas; exemplos de SBOM (CycloneDX / SPDX); scripts e políticas de aceitação; e recomendações alinhadas a frameworks como ISO/IEC 27001, NIST SSDF, NIST CSF, MITRE ATT&CK e ISA-62443.

Em suma: se você participa de compras públicas, este texto é um manual que transforma intenção em força contratual. Se você é fornecedor, é o roteiro do que a administração pública razoavelmente vai passar a exigir — e o que será decisivo para ganhar concorrências nos próximos anos.

🔍 Entendendo Compras Públicas e Segurança-by-Design – Os Fundamentos

A relação entre aquisições públicas e segurança não é nova, mas ganhou urgência. Contratos governamentais historicamente priorizaram preço, prazo e conformidade funcional. Segurança era tratada como cláusula adicional — muitas vezes vaga, reativa e com baixa responsabilização. Segurança-by-design altera essa abordagem: trata a segurança como requisito funcional e não como adição posterior, integrando práticas de engenharia, arquitetura e governança desde a concepção até a manutenção.

O que significa “Segurança-by-Design”? Segurança-by-design é uma filosofia e conjunto de práticas que pretende incorporar princípios de segurança desde o primeiro dia do ciclo de vida de um produto ou serviço. Isso inclui:

• Minimização de superfície de ataque: reduzir funcionalidades desnecessárias, portas e serviços expostos;
• Privacidade e proteção de dados por padrão: configurções padrão seguras, anonimização quando aplicável, e requisitos de retenção mínimos;
• Defesa em profundidade: múltiplas camadas de proteção — autenticação forte, criptografia, segregação de privilégios, detecção e resposta;
• Design para atualização: mecanismos para patching rápido, atualizações assinadas e rollback seguro;
• Transparência de cadeia de suprimentos: SBOM, prova de integridade e políticas de disposição de componentes;
• Testabilidade: builds reproduzíveis, integração contínua com segurança (DevSecOps), fuzzing e testes automatizados;
• Compartilhamento de responsabilidades: acordos contratuais claros sobre quem responde por quê, incluindo canais de divulgação de vulnerabilidades.

Por que isso importa nas compras públicas? A administração pública é alvo atraente: concentra dados pessoais (cidadãos), infraestruturas críticas (energia, água, transporte), e serviços essenciais (saúde, educação). Além disso, contratos públicos influenciam o mercado — um edital que exige SBOM e testes de penetração muda o comportamento dos fornecedores. Incorporar segurança-by-design nas compras públicas cria externalidades positivas: eleva o padrão do mercado e reduz risco sistêmico.

Marcos históricos e evolução

• 2015 — OPM Breach (Estados Unidos): vazamento massivo de registros pessoais relacionados a fornecedores e pessoal federal, destacando risco de terceiros;
• 2017 — NotPetya: mostrou impacto econômico em cadeias logísticas por meio de software legítimo comprometido;
• 2017 — WannaCry (NHS/Reino Unido): expôs fragilidade de sistemas dependentes de software desatualizado em infraestrutura crítica;
• 2020 — SolarWinds (Sunburst/Supply Chain): ilustrou como um vendor comprometido pode se tornar vetor para atacar várias agências e empresas simultaneamente;
• 2021 — EO 14028 (EUA): Executivo dos EUA introduz requisitos para fortalecer segurança da cadeia de suprimentos de software e incentiva adoção de SBOM;
• 2021-2024 — NIS2 e regulação europeia: aumentam requisitos de segurança para entidades essenciais e fornecedores; fabricantes e provedores passaram a ter responsabilidades mais claras.

Princípios fundamentais aplicáveis a compras:

• Requisito contra requisito: declarar métricas de segurança mensuráveis no edital (ex.: tempo máximo para aplicar patch crítico — 15 dias);
• Transparência: exigir SBOM, políticas de segurança e relatórios de auditoria independentes;
• Responsabilização jurídica e técnica: cláusulas de SLA, penalidades, escrow de código em determinados casos e auditoria independente;
• Proibição de ‘through the eyes’ gap: não aceitar declarações genéricas — exigir evidências (relatórios de pentest, certificações, logs de CI/CD);
• Visão de ciclo de vida: considerar manutenção, desativação e planos de continuação como parte do contrato;
• Compatibilidade com frameworks: alinhar requisitos contratuais a ISO/IEC 27001, NIST SSDF, CIS Controls, MITRE ATT&CK para prevenção/detecção.

Interseção com contratos públicos e leis

No Brasil, a Lei nº 14.133/2021 (nova lei de licitações) modernizou regras de contratação pública e introduziu caminhos para considerar responsabilidade técnica em contratações complexas. Além disso, a LGPD (Lei nº 13.709/2018) impõe obrigatoriedades no tratamento de dados pessoais — o que é crítico quando contratos envolvem manejo de dados de cidadãos. Internacionalmente, normas como NIS/NIS2 (UE) e políticas norte-americanas (EO 14028) adicionaram pressão para que clientes públicos exijam segurança detalhada de fornecedores.

Conclusão do fundamento: Segurança-by-design em compras públicas não é apenas boa prática — é uma necessidade sistêmica, econômica e legal. A seguir, veremos como isso funciona tecnicamente e como transformar conceitos em requisitos concretos nos editais e contratos.

⚙️ Como Compras Públicas com Segurança-by-Design Funciona – Mergulho Técnico

Integrar segurança-by-design nas compras públicas exige que o gestor entenda as práticas técnicas que comprovam a segurança de um produto ou serviço. Não basta declarar que “o fornecedor segue práticas seguras”; é preciso exigir artefatos, evidências técnicas e integrações que possibilitem auditoria contínua. Nesta seção vamos detalhar os mecanismos, arquiteturas, processos e métricas que tornam essa abordagem operacional.

Arquitetura e componentes críticos

Quando falamos em segurança-by-design para um produto contratado, devemos considerar cada camada da arquitetura:

• Pipeline de desenvolvimento (CI/CD): como são construídas e distribuídas as releases? Builds reproduzíveis, assinaturas digitais, repositórios privados com controle de acesso, e integração de testes de segurança automáticos (SAST, DAST, SCA) são requisitos técnicos;
• Gestão de dependências: SCA (Software Composition Analysis), políticas de atualização de dependências, bloqueio de versões vulneráveis, e curadoria de mirror de pacotes;
• Gerenciamento de identidade e acesso (IAM): autenticação multifator (MFA), princípios de menor privilégio, roles e políticas de IAM auditáveis;
• Infraestrutura e rede: segmentação, firewalls, WAF, TLS estrito, cipher suites aprovados, e uso de VPNs ou links dedicados para tráfego sensível;
• Observabilidade e Telemetria: logs centralizados, uso de formatos interoperáveis (CEF, LEEF, Elastic Common Schema), integrabilidade com SOC/SIEM do cliente, e APIs para exportação de telemetria;
• Integridade e criptografia: criptografia at-rest e in-transit, gerenciamento de chaves através de HSMs ou KMS, e uso de algoritmos modernos (ex: AES-GCM, RSA-2048/3072, EC secp256r1/384);
• Processos de atualização/patching: deploys atômicos, planos de rollback testados, e política de resposta a vulnerabilidades;
• Propriedade intelectual e escrow: cláusulas de escrow para código fonte e build artifacts, quando necessário para continuidade do serviço.

Software Bill of Materials (SBOM) — o coração da transparência

SBOM é uma lista formal dos componentes que compõem um software — bibliotecas, versões, licenças e hashes. Para compras públicas, exigir um SBOM em formatos interoperáveis (SPDX, CycloneDX) é essencial. Um bom SBOM inclui:

• Identificação única do componente (name, version, supplier);
• Hashes de integridade (SHA-256 mínimo);
• Licença e origem;
• Data de build e metadados do build (pipeline, repositório, versão do compilador);
• Vulnerabilidades conhecidas (link para CVE/CWE) e data da última varredura SCA;
• Relação de dependência (graph) para identificar componentes transitivos.

Exigir SBOMs atualizados a cada release permite ao comprador público rapidamente mapear impacto quando uma nova CVE é divulgada. Um SBOM também facilita análises de risco automatizadas: varredura cruzada entre SBOM e bancos de vulnerabilidades (NVD/CVEs) pode acionar obrigações contratuais de remediação.

Assinatura de código e cadeia de confiança

Assinar artefatos (binários, containers, pacotes) com chaves gerenciadas em HSMs reduz risco de adulteração. Exigir que builds sejam assinados e que o processo de assinatura seja auditável é um requisito técnico poderoso. Modelos de confiança como SLSA (Supply-chain Levels for Software Artifacts) descrevem níveis de maturidade da cadeia de suprimento, desde builds não verificáveis até builds altamente integrados e herméticos com políticas de aprovisionamento e atestação.

Testes automatizados e validação contínua

Contratos devem exigir que fornecedores executem testes SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), IAST (Interactive), e fuzzing em componentes críticos. Além disso, políticas de qualidade que definam cobertura mínima de testes unitários e de integração, bem como métricas de complexidade ciclomática, devem estar presentes. Importante: resultados e relatórios desses testes precisam ser entregues em artefatos assinados e disponibilizados ao cliente para auditoria.

Monitoramento, detecção e resposta (MDR/SOC integration)

Para serviços críticos, a integração com o SOC/SIEM do cliente é mandatória. Isso inclui:

• Envio de logs em formato padrão (CEF/LEEF/ECS);
• APIs para consulta e exportação de eventos e metadados;
• SLAs de tempo de retenção de logs e acesso a dados de investigação;
• Playbooks conjuntos para investigação e resposta (RACI definido);
• Notificações automáticas para incidentes de alta severidade, conforme RFC 5070 (ou similar) implementada no contrato.

Modelagem de Ameaças e Privacy Impact Assessments

Antes de finalizar uma contratação, um requisito técnico importante é a entrega de modelagem de ameaças (Threat Model) e de Avaliação de Impacto de Proteção de Dados (DPIA / PIA). Essas entregas precisam mapear surface attacks, dados sensíveis, vetores de ataque, e controles mitigantes. No caso de sistemas SCADA/ICS, usar ISA-62443 como baseline é adequado; para software, alinhar com NIST SSDF e OWASP SAMM é recomendável.

Métricas técnicas que funcionam como requisitos

• Time-to-patch (TTP): máxima janela aceitável para patches críticos (ex.: 15 dias) e para patches de alta severidade (30 dias);
• Mean-time-to-detect (MTTD): requisito para detecção de intrusão (ex.: 24 horas);
• Mean-time-to-respond (MTTR): tempo para conter e mitigar (ex.: 72 horas para incidentes críticos);
• Coverage de testes: percentuais mínimos de testes (ex.: 80% cobertura unitária em módulos críticos);
• Número de vulnerabilidades abertas: limites aceitáveis e planos de mitigação;
• Requisitos de criptografia: TLS 1.2+ (preferência por TLS 1.3), algoritmos aprovados e uso de PFS (Perfect Forward Secrecy).

Verificabilidade técnica: como garantir que o fornecedor cumpre?

As evidências exigidas não devem ser meras declarações: contratos públicos precisam especificar artefatos técnicos auditáveis:

• SBOM assinado por release;
• Relatórios de SAST/DAST e resultados de fuzzing;
• Logs de pipeline (Build IDs, hashes) e assinaturas de artefatos;
• Relatório de pentest realizado por terceira parte independente (escopo e datas definidos);
• Certificações e atestados (ISO 27001, requisitos de NIST SSDF ou SLSA level), quando aplicáveis;
• Acesso temporário e controlado para auditoria (on-site ou remoto), com regras para proteção de IP do fornecedor.

Automação e integração com processos de compras

Por fim, o poder real vem da automatização das validações. Ferramentas de CI/CD podem expor webhooks que notifiquem o cliente sobre novas releases; pipelines podem gerar SBOMs automaticamente; scanners SCA podem enviar relatórios para plataformas de gestão de riscos do comprador. Contratos devem especificar formatos e APIs para integração, reduzindo fricção operacional e permitindo resposta rápida a vulnerabilidades recém-divulgadas.

Na próxima seção examinaremos estudos de caso reais para ilustrar por que essas exigências são imprescindíveis e o que acontece quando não são aplicadas.

🎯 Aplicações Reais e Estudos de Caso

Nada convence mais do que exemplos concretos. Abaixo, apresento estudos de caso emblemáticos que demonstram as consequências de uma cadeia de suprimentos insegura, e como requisitos de segurança-by-design poderiam ter mitigado os impactos.

1) SolarWinds / SUNBURST (Dezembro de 2020)

Resumo do incidente: a campanha de ataque ao SolarWinds comprometeu o processo de build da solução Orion. Artefatos maliciosos assinados foram distribuídos via atualização legítima. O incidente afetou agências governamentais dos EUA e milhares de organizações globais.

Impacto: comprometeu a confiança em atualizações assinadas, afetou diretamente departamentos de defesa, comércio e energia; levou a uma investigação ampla e a políticas executivas (EO 14028) para fortalecer a segurança da cadeia de suprimentos.

Lições contratuais: se os compradores tivessem exigido:

• SBOM detalhado com hashes verificáveis;
• Provas de builds reproduzíveis e logs de pipeline;
• assinaturas com chaves gerenciadas em HSM e atestações SLSA nível 3;

…o risco de ingestão de código não autorizado poderia ter sido reduzido. Além disso, cláusulas de auditoria que permitissem inspeção de processos de build teriam possibilitado detecção precoce de anomalias.

2) NotPetya / 2017 (Distribuído em atualização de software de um fornecedor ucraniano)

NotPetya foi inicialmente distribuído via atualização de software de um fornecedor local (MEDoc), e acabou causando danos globais a empresas como Maersk, Merck e Mondelez. O ataque não visava apenas dados: foi destrutivo — um wiper — causando paralisação de operações.

Lições contratuais: verificações de integridade de atualização, assinaturas robustas, maturidade de processos de release e mecanismos de rollback podem limitar o escopo do impacto. Para infraestruturas críticas, contratos devem prever redundância e capacidade de isolar atualizações para um subconjunto controlado antes de promover em ambiente de produção (canary releases).

3) OPM (Office of Personnel Management) – 2015

O vazamento de dados pessoais do OPM — incluindo informações de seguridade nacional — ocorreu em parte devido a falhas de segurança e pela exploração de fornecedores terceirizados. O incidente expôs a importância de controlar a superfície de ataque introduzida por terceiros e exigir práticas de segurança consistentes em fornecedores.

Implicações para licitações: contratos devem prever avaliações periódicas de fornecedores, requisitos de hardening de sistemas e controles mínimos de IAM para acesso remoto e integrações com bases de dados governamentais.

4) Accellion FTA (2020)

O Accellion FTA, um produto de transferência de arquivos legado, foi explorado por atacantes que exploraram vulnerabilidades em um componente central ainda utilizado por várias organizações, incluindo universidades e empresas. O vetor foi a continuidade do uso de uma solução desatualizada para processos críticos.

Resposta contratual: contratos públicos devem exigir planos de lifecycle management, incluindo end-of-life (EOL) e planos de migração, para evitar dependência de sistemas que se tornam inseguros com o tempo.

5) WannaCry e NHS (2017)

WannaCry explorou uma vulnerabilidade conhecida (EternalBlue). A infraestrutura da NHS sofria com sistemas legados e falta de atualização, resultando em cancelamento de procedimentos e impactos clínicos.

Requisitos essenciais: exigir inventário atualizado de ativos, patch management com periodicidade definida, e planos de continuidade clínica/operacional que incluam fallback em caso de indisponibilidade tecnológica.

6) Equifax (2017)

Vulnerabilidade em Apache Struts foi explorada e resultou em um dos maiores vazamentos de dados pessoais. O caso mostra falhas em scans e patching de components conhecidos.

Ação contratual adequada: exigir SCA contínuo, varreduras automáticas, e integração de alertas CVE com maturidade contratuais — prazos de remediação vinculados a SLAs e penalidades.

Análise transversal: Todos os casos acima têm pontos em comum: dependência de componentes de terceiros, ausência de transparência na cadeia de build, e processos de manutenção inadequados. Para o comprador público, a resposta passa por transformar práticas técnicas em obrigações contratuais verificáveis.

Exemplo de caso de sucesso: Governo do Reino Unido e teste de fornecedores

O Reino Unido, após episódios como o da NHS, passou a exigir avaliações mais rigorosas em contratos de tecnologia para saúde. Programas como o Cyber Essentials e listas aprovadas de fornecedores reduziram o risco para órgãos públicos ao criar filtros técnicos e de processo.

Estudo de caso prático – Contrato de Plataforma de Gestão Municipal (hipotético baseado em práticas reais)

Imagine um município que contratou uma plataforma de gestão fiscal. O edital exigiu:

• SBOM em CycloneDX por release;
• Relatórios trimestrais de SCA e pentest anual por terceiro;
• Integração com o SOC municipal via TLS e autenticação mútua;
• Escrow do código-fonte em caixa-forte eletrônico;
• Tempo máximo de patch 15 dias para CVE crítico.

Ao longo dos dois primeiros anos, o fornecedor recebeu duas notificações de CVE crítico: a capacidade contratual de exigir remediação em 7 dias e reverter a release defeituosa evitou indisponibilidades e preservou dados sensíveis. O custo do mecanismo de defesa foi inferior ao impacto potencial de uma violação.

Conclusão dos estudos de caso: Lições práticas podem e devem ser traduzidas em cláusulas, métricas, e evidências técnicas. A próxima seção mostra como fazer isso passo a passo, do edital à aceitação final.

🔧 Guia de Implementação – Passo a Passo

Implementar segurança-by-design em compras públicas envolve cinco grandes fases: Planejamento do edital, Avaliação pré-qualificatória, Avaliação técnica durante a seleção, Execução contratual com mecanismos de garantia, e Gestão contínua do ciclo de vida. A seguir apresento um roteiro detalhado para gestores e equipes técnicas.

Fase 1 — Planejamento do edital

1.1 Definir escopo e criticidade: classifique o ativo a ser contratado segundo impacto em confidencialidade, integridade e disponibilidade (C-I-A). Para sistemas críticos, exigir níveis maiores de segurança e garantias contratuais.

1.2 Requisitos técnicos mínimos (exemplo):

• SBOM em CycloneDX ou SPDX por release;
• Assinatura de builds com chaves gerenciadas em HSM;
• Relatórios SAST/DAST com cobertura e resultados mínimos;
• Pentest por terceiro independente ao menos anual;
• Planos de resposta a incidentes e integração com SOC do cliente;
• Tempo máximo para remediação de CVE crítico: 15 dias (ou conforme risco).

1.3 Documentos esperados no RFP / Edital:

• Política de segurança do fornecedor e certificações (ISO 27001, SOC2 tipo II, quando aplicável);
• Modelagem de ameaça do sistema e DPIA;
• SBOM inicial para avaliação;
• Relatórios de testes de segurança recentes e pentest independente;
• Detalhamento do pipeline CI/CD, uso de ferramentas SCA, e controles de assinatura de artefatos;
• Escopo de suporte, SLAs e penalidades;
• Planos de continuidade e EOL;
• Cláusula de auditoria, incluindo auditoria técnica com acesso controlado.

Fase 2 — Pré-qualificação de fornecedores

2.1 Lista curta baseada em evidência: pré-selecione apenas fornecedores que comprovem práticas mínimas (ex.: SBOM, CI/CD seguro, pentest recente). Use um template de avaliação com pesos:

2.2 Inspeção técnica: realize entrevistas técnicas e provas de conceito (PoC) com foco em evidências: pedir o SBOM de um build exemplo, logs de pipeline e relatório de SCA. Contratos públicos podem exigir ambiente sandbox para execução de PoC.

Fase 3 — Seleção e cláusulas contratuais

3.1 Exemplo de cláusulas essenciais (trecho modelo em português):

3.2 Escrow de código: para sistemas estratégicos, incluir cláusula de escrow que permita ao contratante acesso ao código-fonte em caso de falência do fornecedor, descumprimento ou cessação do serviço.

3.3 Penalidades e incentivos: definir penalidades proporcionais a impactos (multa, rescisão, retenção de pagamento) e incentivos por super-qualidade (bônus por SLAs excedidos, redução de auditorias).

Fase 4 — Execução e aceitação técnica

4.1 Pipeline de aceitação: definir etapas de homologação técnica: validação de SBOM, verificação de assinaturas, run de SCA, execução de casos de teste de segurança, e integração com SIEM/SOC. Cada etapa deve gerar artefatos assinados que comprovem conformidade.

4.2 Ambiente de pré-produção e testes canary: exigir que atualizações sejam primeiro aplicadas em ambiente isolado e depois promovidas gradualmente (canary) para limitar impacto de regressões.

4.3 Planos de rollback e validação de integridade: deploys devem ser atômicos e permitir rollback seguro com verificação de hashes e assinaturas.

Fase 5 — Gestão contínua e encerramento

5.1 Monitoramento contínuo: manutenção de integração entre logs do fornecedor e SIEM do contratante, com indicadores (MTTD, MTTR) monitorados mensalmente.

5.2 Reavaliações periódicas: pentests anuais, reavaliação do SBOM em cada release maior, e re-certificações a cada 2 anos quando aplicável.

5.3 Fim de contrato: planos de transição de dados, revogação de chaves, entrega de assets e transferência do escrow conforme cláusula.

Exemplo técnico — template SBOM CycloneDX minimal (JSON):

Automatizando validações com SCA e pipelines

Adicionar steps automáticos no CI para gerar SBOM, executar SAST/SCA, e negar builds quando encontrar componentes com CVE crítico. Exemplo de job em YAML (exemplo genérico):

Conclusão do guia: a implementação efetiva converte requisitos técnicos em artefatos verificáveis e processos automatizados. O próximo bloco aborda recomendações práticas e checklists que facilitam priorização e aplicação.

⚡ Melhores Práticas e Recomendações de Especialistas

Reunir todas as recomendações úteis em uma lista prática é essencial para quem precisa agir. Abaixo, um conjunto de melhores práticas que combinam visão técnica, jurídica e operacional — testadas por profissionais de SOC, arquitetos e auditores que atuam com compras públicas.

1. Exija SBOM como padrão — Não como opcional

SBOMs permitem ações proativas: quando uma CVE é divulgada, o comprador mapeia rapidamente o impacto. Exigir SBOM em SPDX/CycloneDX e com hashes assinados é fundamental. Além disso, especifique a periodicidade de atualização (por release, hotfix e patch crítico).

2. Integre requisitos a SLAs e penalidades

Só exigir não basta: estabeleça SLAs claros (TTP, MTTD, MTTR) e penalidades econômicas/contratuais quando não cumpridos. CLÁUSULA: “Remediação de CVE crítico em X dias; em caso de não cumprimento, aplicação de multa diária Y% do valor do contrato”.

3. Use níveis de maturidade de cadeia (SLSA/OWASP/SAMM)

Adote SLSA ou OWASP SAMM como referência para exigir níveis mínimos. Por exemplo, para serviços críticos exigir SLSA nível 3 ou equivalente, o que envolve builds automáticos, controles de integridade, e verificações de provenance.

4. Exija pentest por terceira parte independente

Relatórios de pentest devem ser entregues com evidências (logs, PoC em ambiente controlado), e ações corretivas devem ser acompanhadas. Use metodologias conhecidas (OSSTMM, PTES, OWASP) e solicite remediação antes da aceitação final.

5. Controle de dependências e políticas de lock

Recomende ou exija uso de SCA, políticas de bloqueio de versões quando apropriado e mirrors corporativos para reduzir risco de packages maliciosos. Automatize alertas para vulnerabilidades novas em dependências transitivas.

6. Defina requisitos de cryptography e KMS/HSM

Especifique algoritmos e operações: exija TLS 1.3 quando aplicável, chaves com rotação periódica, uso de HSMs para chaves de assinatura de builds e armazenamento de segredos com vaults seguros (HashiCorp Vault, cloud KMS com MFA para acessos sensíveis).

7. Implementar políticas de Disclosure e Bug Bounty

Exigir que fornecedores tenham política de divulgação de vulnerabilidades e canais para reporte (VDP). Para fornecedores estratégicos, incentivar bug bounty ou colaboração com comunidades de segurança para descoberta ativa de falhas.

8. Auditoria técnica com acesso limitado

Incluir no contrato possibilidade de auditoria técnica por terceiros, em ambiente controlado, com non-disclosure agreement (NDA) que proteja IP do fornecedor. Técnicos do contratante devem poder verificar logs/artefatos-chave.

9. Planejamento para transição e EOL

Previna vendor lock-in pedindo planos de exportação de dados, formatos abertos e cláusulas de continuidade (escrow/transferência). Defina o que acontece se o fornecedor encerrar atividade ou houver falha contratual.

10. Educação e governança interna

Compras públicas precisam de capacidade técnica interna: equipe de análise de SBOMs, analistas de risco e SOC com processos de ingestão de telemetria. Sem isso, exigências técnicas se tornam papel molhado.

11. Alinhe com privacidade por design

Integre DPIA/DPA nos requisitos, exija minimização de dados e criptografia at-rest. Para projetos de saúde e educação, peça segregação entre ambientes e controles de pseudonimização.

12. Exija integração com SOC/SIEM do cliente

Para serviços em nuvem ou SaaS, exigir envio de logs, APIs de pesquisa e suporte a investigação é vital. Defina formatos e cadence (real-time, near-real-time) e retenção mínima.

13. Mantenha modelos contratuais atualizados

Modelos desatualizados que não preveem SBOM, assinaturas de build ou integração com SOC devem ser revisados por equipes técnicas e jurídicas com frequência mínima anual.

14. Recomendação sobre certificações

Certificações como ISO/IEC 27001 e SOC2 podem ser indicadores; no entanto, não substituem evidências técnicas. Use certificações como parte da avaliação, mas exija também artefatos operacionais concretos.

15. Priorização pragmática

Nem todos os contratos precisam do mesmo nível de rigor. Use matriz de risco para definir níveis — baixo, médio, alto — com contrapartidas técnicas proporcionais.

Checklists práticas para edital:

• SBOM por release (formato e assinatura);
• Logs de build (hashes) e assinatura de artefatos com HSM;
• SCA contínuo e política de VDP;
• Pentest anual por terceira parte independente;
• Integração de logs com SIEM (formato e endpoint);
• Penalidades e SLAs (TTP, MTTD, MTTR);
• Escrow, EOL plan, e transferência de dados.

Na próxima seção exploraremos os requisitos de segurança e compliance, com foco em LGPD, ISO, NIS2 e como mapear obrigações legais a cláusulas contratuais práticas.

🛡️ Considerações de Segurança e Compliance

As compras públicas não ocorrem em vácuo jurídico. Em muitos países, há regulamentações rígidas que impactam como software e serviços devem tratar dados e segurança. Para gestores brasileiros, é essencial conciliar LGPD e Lei de Licitações (14.133/2021) com padrões internacionais que frequentemente orientam práticas e exigências. Nesta seção detalhamos compliance, implicações legais e como mapear frameworks técnicos para obrigações contratuais.

LGPD (Lei nº 13.709/2018) — pontos críticos para contratação

A LGPD impõe responsabilidades ao controlador e ao operador quanto ao tratamento de dados pessoais. Em contratos públicos:

• Defina claramente controlador e operador: o contrato deve determinar quem decide finalidades e meios do tratamento (controlador) e quem processa dados por conta do controlador (operador);
• Cláusula de tratamento de dados: exigência de medidas técnicas e administrativas (art. 46 LGPD);
• Transferência internacional: quando aplicável, prever bases legais e garantias adequadas (ex.: cláusulas padrão);
• Violação de dados: obrigação de notificação imediata ao órgão público (com prazos), cooperação para investigação e mitigação;
• Auditorias e registros: exigir relatórios de atividades de tratamento, logs e políticas de retenção e eliminação de dados.

Lei de Licitações (Lei nº 14.133/2021)

A nova lei moderniza procedimentos e permite mais flexibilidade técnica para contratações complexas, incluindo contratação integrada e fase de estudos preliminares. Pontos relevantes:

• Critérios de julgamento técnico: é possível atribuir peso a requisitos de segurança no julgamento de propostas;
• Contratação integrada: pode ser usada quando houver complexidade técnica, permitindo que a responsabilidade pelo projeto e execução seja do contratado (exigindo cláusulas robustas de garantia);
• Compliance e responsabilidade: a lei admite exigir garantias contratuais; gestores devem trabalhar próximos às áreas jurídica e técnica para inserir requisitos de segurança tecnicamente mensuráveis.

Normas e frameworks internacionais

Alinhe requisitos a frameworks reconhecíveis:

• ISO/IEC 27001: foco na gestão de segurança da informação — útil para avaliar maturidade de fornecedores;
• NIST CSF e NIST SP 800-218 (SSDF): orientam práticas de defe as a software development; o SSDF (Secure Software Development Framework) é particularmente relevante para requerer práticas de desenvolvimento seguro;
• ISA-62443: quando se trata de sistemas industriais/SCADA/ICS;
• MITRE ATT&CK: usar a base de técnicas para mapear requisitos de detecção e mitigação;
• SLSA: para maturidade de cadeia de suprimentos de software;
• ENISA / NIS2: regulação europeia que amplia responsabilidade de fornecedores e entidades essenciais.

Requisitos contratuais para compliance:

• Cláusula de proteção de dados (LGPD) com prazos e obrigações de notificação;
• Demandar documentos de DPIA/DPA quando tratamento sensível estiver envolvido;
• Definição de subcontratação/terceirização: aprovação prévia do contratante para subcontratação que envolva dados sensíveis;
• Requisitos de retenção e exclusão de dados ao término do contrato;
• Direito do contratante a auditorias técnicas e a receber logs e artefatos de investigação;
• Responsabilidade civil e indenização por vazamentos indevidos, com limites e exceções devidamente ponderados;
• Cláusulas de continuidade, escrow e plano de substituição para mitigação de risco operacional.

Como mapear frameworks a cláusulas concretas — exemplo prático

Tomemos NIST SP 800-218 (SSDF) e mapeamos para cláusulas:

• SSDF Prática 1: estabelecer padrões para requisitos de segurança desde fase de planejamento → CLÁUSULA: fornecedor deve aplicar requisitos de segurança descritos em anexos técnicos e fornecer evidências;
• SSDF Prática 2: usar análise de composição e ferramentas SCA → CLÁUSULA: fornecer SBOM e relatórios SCA por release;
• SSDF Prática 3: proteção durante build e deploy → CLÁUSULA: builds reproduzíveis, assinatura de artefatos e HSM/KMS.

Auditoria, evidências e litígio

Em caso de incidentes, ter evidências técnicas claras e verificáveis é determinante para defesa jurídica do contratante. Por isso, contratos devem exigir:

• Logs de acesso e informações de auditoria com retenção definida;
• Provas de build e cadeia de custódia de artefatos;
• Relatórios e comunicações de incidentes documentadas;
• Acesso controlado a ambientes de investigação quando necessário;
• Cláusulas de cooperação para investigação interna e com autoridades regulatórias.

Exigências de certificações e sua limitação

Certificações (ISO27001, SOC2) são valiosas, mas não substituem provas técnicas. Elas sinalizam maturidade de gestão, não necessariamente que cada release de software atende requisitos de segurança-by-design. Combine certificações com artefatos comprováveis.

Conclusão de compliance: alinhar requisitos contratuais às obrigações legais e frameworks técnicos melhora a defensabilidade do poder público e reduz risco jurídico e operacional. A seguir veremos desafios práticos e como superá-los.

⚠️ Desafios Comuns e Como Superá-los

Adicionar segurança-by-design às compras públicas é a decisão correta — mas não é simples. Aqui estão os desafios mais frequentes e soluções práticas, extraídas da experiência real em projetos e auditorias de fornecedores.

Desafio 1 — Falta de capacidade técnica interna

Muitos órgãos públicos não têm equipes técnicas capazes de analisar SBOMs, interpretar relatórios de SCA e executar auditorias técnicas. Solução: criar centros de excelência (CoE) centralizados ou contratar serviço de avaliação técnica terceirizado homologado. Treinamento contínuo e playbooks de avaliação simplificam decisões e evitam erros comuns.

Desafio 2 — Resistência jurídica e medo de litígio

Advogados públicos frequentemente veem cláusulas técnicas como risco de gerar disputas. A solução prática é trabalhar com contratos modulares: defina critérios técnicos mensuráveis e procedimentos de resolução — por exemplo, planos de correção com prazos, perícia técnica independente e mediação antes de multas ou rescisão. Isso cria caminho de remediação e reduz litígios.

Desafio 3 — Fornecedores pouco maduros

Pequenos fornecedores podem não ter capacidade de gerar SBOM ou executar práticas de DevSecOps. Solução: classificar fornecedores por critério de risco e oferecer janelas temporais para adoção de requisitos, além de programas de capacitação e incentivos contratuais. Para serviços críticos, exigir maturidade mínima desde o início.

Desafio 4 — Sobrecarga documental

Exigir relatórios demais pode paralisar processos. Priorize artefatos realmente úteis: SBOM, relatórios SCA e pentest resumido com PoC. Prefira formatos automatizáveis e APIs para ingestão de informações, reduzindo papel e revisões manuais.

Desafio 5 — Gestão de segredo industrial e IP

Fornecedores temem exposição de propriedade intelectual em auditorias. A solução é definir mecanismos de auditoria com NDA, auditorias in loco controladas, ambientes de sandbox e cláusulas específicas que protejam IP enquanto permitem verificação de evidências técnicas.

Desafio 6 — Atualizações rápidas e compatibilidade

Quando o fornecedor precisa liberar correções urgentemente, o processo contratual pode atrasar a aplicação de patches. Crie procedimentos de emergência que permitam aplicação de hotfixes sujeitos a posterior auditoria, mantendo o equilíbrio entre velocidade e segurança.

Desafio 7 — Integração com sistemas legados

Sistemas governamentais frequentemente têm legados. A solução é exigir padrões de integração segura (TLS, autenticação mútua, gateways de API) e planos de interface com testes de compatibilidade. Para sistemas críticos, use gateways de isolamento (API gateways com WAF) e sandboxes.

Desafio 8 — Avaliação de risco contínua

Risco não é estático. Exija reavaliações periódicas, integração com feeds de vulnerabilidades e automação para alertar impacto sobre ativos do contratante. Use políticas de correção que disparem quando CVEs relevantes aparecerem no SBOM.

Desafio 9 — Falta de padronização em SBOM e formatos

Embora SPDX e CycloneDX sejam amplamente adotados, nem todos os fornecedores produzem SBOM padronizada. Defina no edital um ou dois formatos aceitos e requisitos mínimos (hashes, license, dependency graph), e forneça exemplos técnicos para facilitar adoção.

Desafio 10 — Custos percebidos e resistência política

Tornar segurança-by-design obrigatório pode aumentar custos iniciais. A resposta política é comparar custo previsto de mitigação com custo potencial de incidentes. Estudos e cases (SolarWinds, NotPetya) oferecem exemplos concretos de perdas muito maiores que investimentos em segurança.

Soluções operacionais e ferramentas para superar desafios

Central de garantia técnica: equipe que padroniza requisições, revisa SBOMs e orienta áreas de compras. Guias e templates: modelos de cláusulas e checklists (SBOM template, pentest scope). Plataformas de ingestão automatizada: permitem receber SBOMs e relatórios SCA diretamente para análise automatizada. Catálogo de fornecedores aprovados: lista com maturidade técnica mínima para compras rápidas.

Plano de implantação por fases:

• Fase 0 — Inventário e classificação de criticidade;
• Fase 1 — Requisitos mínimos (SBOM, pentest) para contratos novos de médio/alto risco;
• Fase 2 — Reavaliação de contratos existentes e inclusão gradual de requisitos;
• Fase 3 — Automação e integração com plataformas de risco e SIEM;
• Fase 4 — Auditoria periódica e evolução para exigência de SLSA/SSDF em contratos críticos.

Com esses caminhos práticos, gestores públicos podem superar as barreiras operacionais e transformar exigências de segurança em realidade. Agora abordaremos ferramentas e tecnologias que viabilizam essas práticas.

📊 Ferramentas e Tecnologias

Implementar segurança-by-design requer um conjunto de ferramentas que abordem geração de SBOM, análise de dependências, testes de segurança automatizados, assinatura de artefatos, e integração de logs. Abaixo listo tecnologias e plataformas relevantes, com prós, contras e critérios de seleção.

1. Ferramentas para SBOM

• CycloneDX: formato e conjunto de bibliotecas para gerar SBOMs para múltiplas linguagens. Prós: amplo suporte, foco em segurança. Contras: ainda em evolução para alguns ecossistemas.
• SPDX: padrão promovido pela Linux Foundation. Prós: aceitação ampla, boa para compliance jurídico. Contras: pode ser mais verboso e complexo que CycloneDX.
• Ferramentas geradoras: Syft (Anchore), CycloneDX-CLI, SPDX tools. Syft é popular para containers e multi-linguagens.

2. SCA — Software Composition Analysis

• Snyk: integração CI/CD, bom para devs. Prós: excelente triagem e PR remediation. Contras: custo por projeto.
• Dependabot (GitHub): automático para repositórios no GitHub. Prós: integrado e gratuito em muitos casos. Contras: escopo limitado a repositórios GitHub.
• WhiteSource, Black Duck (Synopsys): soluções corporativas com escopo amplo. Prós: maturity enterprise. Contras: custo e complexidade.

3. SAST/DAST/IAST

• SAST: SonarQube, Checkmarx, Veracode. Verificação de código estático e regras avançadas.
• DAST: OWASP ZAP, Burp Suite. Testes em tempo de execução e detecção de vulnerabilidades aplicacionais.
• IAST: Contrast Security — monitora em runtime com instrumentação.

4. Assinatura de artefatos e gestão de chaves

• HSMs e KMS: AWS KMS + CloudHSM, Azure Key Vault, Google KMS, Thales HSM on-prem. Chaves para assinatura de builds devem ser guardadas em HSM e com políticas de rotação.
• Sigstore: projeto open-source para assinatura de containers/artefatos com transparência (Rekor). Permite atestação de provenance e verificação.

5. CI/CD seguros

• GitLab CI/CD, GitHub Actions, Jenkins: adaptar para segurança: jobs imutáveis, runners isolados, secrets via vault. Use pipelines como código e gere registros.
• Wrappers e policies: gates que impedem releases se falhas críticas existirem (policy-as-code).

6. Ferramentas de observabilidade e SIEM

• SIEM: Splunk, Elastic SIEM, QRadar — aceitam logs em formato padronizado (CEF/ECS). Integração obrigatória com fornecedores em contratos críticos.
• SOAR/MDR: Palo Alto Cortex XSOAR, Splunk Phantom, serviços de MDR com playbooks e integração para resposta automatizada.

7. Ferramentas para pentest e fuzzing

• Ferramentas de pentest: Metasploit, Burp Suite, Nmap, Nessus (scanners de vulnerabilidade).
• Fuzzing: AFL, libFuzzer, OSS-Fuzz — importante para bibliotecas nativas e parsers.

8. Plataformas de gestão de risco e automação

• Plataformas GRC: RSA Archer, ServiceNow GRC, OneTrust — permitem mapear requisitos contratuais a evidências técnicas.
• Orquestração SBOM/SCA: bancos de dados que correlacionam SBOMs com feeds de CVE e alertam mudanças.

Critérios de seleção para órgãos públicos

• Compatibilidade com padrões (SPDX, CycloneDX);
• Integração com CI/CD existentes e pipelines de build;
• Capacidade de exportar artefatos e relatórios assinados;
• Escalabilidade e suporte para múltiplos fornecedores;
• Mapeamento claro de custos e taxa de manutenção;
• Componente on-premise para ambientes sensíveis quando exigido por compliance.

Práticas de integração

1) Automatize geração do SBOM no pipeline; 2) Integre SCA e bloqueio automático de builds com vulnerabilidades críticas; 3) Publique artefatos assinados e armazene em registries com políticas de retenção; 4) Exponha APIs para ingestão de logs e eventos de segurança ao comprador; 5) Configure playbooks de resposta a incidentes para integração com SOC.

Considerações sobre custo

Ferramentas corporativas têm custo, mas o total deve ser comparado com custo do risco. Muitas soluções open-source (Syft, Sigstore, OWASP ZAP, Elastic) permitem construir um pipeline seguro com investimento moderado e escalonável.

Na seção seguinte, discutimos tendências e evolução — para onde o modelo de compras públicas com segurança-by-design está caminhando.

🚀 Tendências Futuras e Evolução

O cenário de ameaças e as políticas públicas convergem para uma realidade em que segurança-by-design não é uma vantagem competitiva, mas um requisito obrigatório. Abaixo exploro tendências que moldarão compras públicas nos próximos 3-7 anos e como se preparar.

1. SBOMs tornam-se padrão regulatório

Já observamos iniciativas governamentais (EO 14028 nos EUA) que impulsionam SBOMs. A tendência é que SBOMs passem de boa prática para requisito regulatório, com exigência de formatos padronizados (SPDX/CycloneDX) e integrações para alertas automáticos. Governos podem vir a exigir SBOMs para qualquer software utilizado em serviços públicos.

2. Maturidade SLSA exigida para fornecedores críticos

À medida que ataques à cadeia de suprimentos aumentam, maturidade na criação de artefatos (SLSA levels) será critério de elegibilidade em licitações. Fornecedores precisarão demonstrar controles de provenance, builds herméticos e atestados de integridade.

3. Aumento de requisitos de telemetria e interoperabilidade com SOCs

Espera-se que contratos exijam integração nativa com sistemas de monitoramento do contratante, APIs padronizadas para logs, e suporte a investigação remota. Isso transformará a forma como SaaS opera com o setor público, com SLAs específicos para entrega de dados e suporte forense.

4. Automação e orquestração de remediação

Ferramentas que correlacionam SBOMs com CVEs e aplicam rules de remediação automática (ex.: scripts de atualização controlada) reduzirão janela de exposição. Contratos podem especificar uso de automação e prova de automação para remediação em cadeia.

5. Identidade e confiança descentralizada

Projetos como sigstore e iniciativas de código aberto para transparência em builds levam a modelos de confiança distribuída. Lista de transparência e registros de atestações (transparency logs) se tornarão artefatos exigidos, substituindo confiança cega em fornecedores.

6. Regulamentação mais severa (NIS2, GDPR, leis locais)

NIS2 e evolução da GDPR/Privacy frameworks aumentam responsabilidade dos fornecedores e compradores. Multas e responsabilidade conjunta elevarão a importância de cláusulas de compliance nos contratos.

7. Segurança industrial e OT em licitações públicas

Com a digitalização de serviço público (smart cities, IoT), exigências de ISA-62443 para segurança de sistemas industriais serão incluídas em contratos de infraestrutura, com auditorias específicas e verificações de hardening.

8. Adoção ampla de modelos de contratação baseados em risco

Modelos de contratação vão incorporar avaliações de risco dinâmicas e preços ajustados ao risco (insurance-linked procurement). Fornecedores com melhores práticas pagam menos retenção e têm maior probabilidade de vencer concorrências.

9. Integração com seguros cibernéticos

Seguradoras cada vez mais exigirão evidências técnicas (SBOM, pentest) para subscrição. Compradores públicos podem integrar requisitos do seguro cibernético nos contratos para garantir cobertura em caso de incidentes.

10. Inteligência de ameaças e feed diretamente para licitações

Feeds de threat intelligence podem ser utilizados para avaliar fornecedores em tempo real e ajustar SLAs e requisitos contratuais dinamicamente.

Preparando-se para o futuro — recomendações

• Adote SBOM e SLSA como roadmap obrigatório;
• Invista em automação para ingestão e correlacionamento de SBOM/CVE;
• Inclua cláusulas que permitam evolução de requisitos sem re-tendering total (força maior tecnológica);
• Crie parcerias público-privadas para capacitação de fornecedores pequenos;
• Mantenha governança centralizada para padronizar requisitos e reduzir custos.

As tendências apontam para um mercado onde a diferenciação será a capacidade técnica comprovada do fornecedor. Agora, finalizo com considerações que sintetizam ações imediatas e estratégicas para gestores públicos.

💬 Considerações Finais

Transformar compras públicas em um vetor de aumento de segurança depende de coragem política, capacidade técnica e contratos bem desenhados. Segurança-by-design não é um luxo: é uma estratégia de defesa sistêmica que reduz custos no médio-prazo e protege serviços essenciais e dados de cidadãos. Para concretizar essa visão, gestores públicos precisam mover-se em três frentes simultâneas: (1) atualizar modelos contratuais para exigir artefatos técnicos verificáveis (SBOM, assinaturas, pentest), (2) criar capacidade técnica interna ou via CoEs para avaliar e auditar fornecedores, e (3) automatizar ingestão e correlações entre SBOM, feeds de CVE e SIEM para agir antes que falhas se tornem crises.

Há trade-offs e custos iniciais, e fornecedores menores podem resistir, mas o mercado se ajusta: quem não evoluir ficará fora das grandes contratações. Casos como SolarWinds, NotPetya e Accellion não são apenas episódios do passado; são advertências. Se você é gestor de compras, reescrever seus editais com requisitos técnicos claros é uma responsabilidade pública. Se você é fornecedor, alinhar-se a esses padrões não é apenas compliance — é vantagem competitiva.

Em última análise, segurança-by-design nas compras públicas é menos sobre tecnologia e mais sobre governança. Exigir evidências, medir métricas, aplicar penalidades proporcionais e investir em capacidade de avaliação transforma risco aleatório em risco gerido. Comece pequeno (SBOM + pentest + cláusula de TTP), evolua com SLSA e automação, e torne a segurança parte do preço e da proposta técnica. O futuro da confiança pública depende disso — e ele começa na próxima licitação que você redigir.

📚 Referências

• Executive Order on Improving the Nation’s Cybersecurity (EO 14028) – Texto executivo dos EUA sobre segurança de software e cadeia de suprimentos.
• NIST Special Publication 800-218 (SSDF) – Secure Software Development Framework, orientações para desenvolvimento seguro.
• SLSA (Supply-chain Levels for Software Artifacts) – Padrão para maturidade da cadeia de suprimentos de software.
• CycloneDX – Formato de SBOM e ferramentas relacionadas.
• SPDX – Standard para Software Bill of Materials.
• CISA – Software Bill of Materials (SBOM) Guidance – Orientações sobre SBOM pelo órgão de cibersegurança dos EUA.
• ISO/IEC 27001 – Normas internacionais para sistema de gestão de segurança da informação.
• Lei nº 14.133/2021 — Nova Lei de Licitações (Brasil) – Texto oficial da nova lei de licitações brasileira.
• Lei nº 13.709/2018 — LGPD (Brasil) – Texto oficial da Lei Geral de Proteção de Dados.
• Mandiant – SolarWinds SUNBURST analysis – Relatório técnico sobre o ataque à SolarWinds.
• Microsoft Security – Analysis of NotPetya – Análise técnica do incidente NotPetya.
• Snyk – O que é SBOM? – Artigo explicativo com exemplos técnicos.