Ciclo de Desenvolvimento Seguro (SSDLC)

SSDLC é um ciclo de desenvolvimento que insere segurança em todas as fases, em vez de adicionar um teste no final. Exemplo: antes de escrever firmware de uma fechadura, o time define autenticação, autorização, operação offline, atualização assinada, anti-rollback, proteção de chaves, logs, privacidade e resposta a falhas. O NIST SSDF 1.1, SP 800‑218, organiza práticas em quatro grupos: Prepare the Organization, Protect the Software, Produce Well-Secured Software e Respond to Vulnerabilities. A preparação inclui políticas, papéis, competências, ambientes, critérios de risco e ferramentas. Cada produto tem responsável de segurança. Requisitos são rastreáveis a ameaças e testes. Dados são classificados. Dependências e linguagens recebem padrões. O time treina em memória segura, criptografia, web, mobile e IoT conforme contexto. Segurança também entra em contratos de fornecedores, componentes e serviços cloud. O ambiente de desenvolvimento é protegido por MFA, dispositivos gerenciados, menor privilégio e acesso condicionado. Repositórios usam branch protection, revisão obrigatória e commits assinados quando adequado. Segredos não entram no código. Um secret scanner bloqueia. O pipeline é ativo crítico. O requisito de implantação é ter governança mínima: dono, inventário, política de exceções e critérios de release. Sem isso, ferramentas geram alertas sem decisão. A consequência prática é reduzir correções emergenciais que deixam hubs e dispositivos vulneráveis após instalação.

A fase de projeto usa modelagem de ameaças, padrões seguros e decisões documentadas. A arquitetura separa privilégios, minimiza superfície, define trust boundaries, autenticação e recuperação. APIs usam esquema, rate limiting e autorização por objeto. Firmware usa secure boot e assinatura. Chaves são por dispositivo, não globais. A implementação segue guias como OWASP ASVS/MASVS, CERT e regras da linguagem. Revisão de código busca lógica, não apenas estilo. SAST encontra padrões de injeção, uso inseguro e memória; não entende todo contexto. SCA identifica bibliotecas e CVEs. Uma SBOM registra componentes, versões e licenças. Dependências são fixadas com lockfiles e hashes, mas atualizadas. Typosquatting e pacote comprometido são riscos. Repositórios privados, mirrors e allowlists reduzem. Builds devem ser reproduzíveis ou verificáveis quando possível. Provenance, como SLSA, registra origem e etapas. Runners são efêmeros e isolados. A chave de assinatura não fica em variável de ambiente comum; usa HSM/KMS e política. Artefatos são imutáveis e assinados. O pipeline separa teste e produção. Um desenvolvedor não publica sozinho. Componentes gerados, modelos de IA e código copiado também passam. Segredos de teste são fictícios. Dados reais de clientes não entram em desenvolvimento sem necessidade. Em IoT, bootloader, firmware, app, cloud e ferramenta de fábrica fazem parte do mesmo produto e do SSDLC.

Um release seguro acumula evidências. Testes unitários cobrem funções de validação, autorização e parsing. Testes de integração verificam mTLS, revogação, tokens, filas e falhas. DAST e scanners exercitam aplicação em execução. Fuzzing é valioso para parsers de protocolos, imagens, ASN.1, Bluetooth e mensagens. Análise de composição verifica CVEs e políticas. IaC scanning avalia Terraform, Kubernetes e cloud. Container scanning inspeciona imagem e base. Testes negativos tentam comando sem permissão, replay, tamanho excessivo, schema inválido, downgrade e firmware não assinado. Pentest independente cobre caminhos e lógica, mas não substitui. O critério de release define quais severidades bloqueiam e como exceções são aprovadas com prazo. Resultados falso-positivos são triados, não simplesmente suprimidos. Cada exceção tem justificativa. O artefato final recebe hash, assinatura e provenance. A distribuição usa TLS e CDN, mas o dispositivo valida assinatura. Chaves de produção em HSM. Canary release e staged rollout limitam regressão. Telemetria de atualização observa falhas sem coletar excesso. Rollback é planejado, com anti-rollback para versões vulneráveis e mecanismo de recuperação. O firmware pode ter partições A/B. O release inclui SBOM, notas de segurança, instruções e período de suporte. A equipe mantém cópia dos artefatos e capacidade de reconstruir. Um pipeline verde não prova ausência de falhas; ele prova que verificações definidas passaram. Revisão de arquitetura e risco residual continuam.

SSDLC continua depois do lançamento. O fabricante publica canal de vulnerabilidade e política de divulgação coordenada, recebe relatórios, confirma, corrige e comunica. PSIRT triageia. CVE é solicitado quando adequado. Patches são desenvolvidos, testados e distribuídos. Logs e telemetria detectam abuso, com privacidade. O produto tem prazo de suporte declarado. Dependências são monitoradas contra novos CVEs. SBOM permite localizar. Incidentes alimentam requisitos e testes. Chaves comprometidas são revogadas e rotacionadas. O plano de resposta inclui assinatura de emergência, atualização forçada apenas quando justificada e operação local. Fim de vida exige aviso antecipado, exportação de dados, migração e desativação segura. Um dispositivo não deve virar lixo funcional apenas porque a cloud fecha sem alternativa. Para casa inteligente, capacidade local e padrões abertos reduzem. O NIST SSDF define práticas de resposta, mas cada organização adapta. A limitação principal do SSDLC é implementação superficial. Adicionar SAST e checklist sem corrigir arquitetura não basta. Métricas de quantidade de scans podem incentivar ruído. Medidas melhores: tempo de correção, defeitos escapados, cobertura de threat model, dependências suportadas e porcentagem de releases assinados. Cultura e responsabilidade importam. Uma exceção permanente vira dívida. O ciclo precisa ser proporcional ao risco; uma lâmpada não exige o mesmo processo de um controlador de acesso, mas ambos precisam de atualização e credenciais únicas.