Segredos na árvore.
Um token no repositório já é um incidente, mesmo que ninguém o tenha rotacionado.
Segurança no caminho da entrega.
Ameaças, acesso, dependências e segredos tratados como trabalho de engenharia. Isto não é certificação nem selo de conformidade.
Risco que sai junto com o build.
Sintomas que procuramos antes de nomear uma ferramenta.
Dependências sem dono.
Uma biblioteca vulnerável permanece porque ninguém sabe quem pode atualizá-la.
Acesso verificado só na interface.
A API ainda responde quando a tela está escondida.
Trabalho que podemos fazer.
Scanners como o Snyk, e listas como o OWASP, são exemplos da categoria. Nomeá-los não é uma parceria.
Um modelo de ameaças.
Ativos, limites de confiança e os poucos abusos que valem um desenho.
Acesso e segredos.
Autenticação, autorização, menor privilégio e um caminho de rotação.
Verificações no pipeline.
Varredura de dependências e segredos, e um portão que pode bloquear um release. Testes estáticos ou dinâmicos só onde pagam o custo.
Ordem do trabalho.
Achar o ativo.
Dados, credenciais e as ações que um estranho não pode executar.
Colocar um controle no caminho.
Uma verificação que roda antes do release, com um dono quando falha.
Escrever a resposta.
Quem rotaciona, quem avisa e que evidência fica. Sem SLA inventado.
Limites.
Sem certificação.
Não afirmamos certificação ISO, SOC, LGPD ou GDPR para a Solid Solutions nem para um cliente.
Controles do site são separados.
Cabeçalhos e o formulário deste site não são uma prática de segurança vendida como caso.
Perguntas que esperamos.
Vocês certificam nosso produto?
Não. Podemos desenhar controles e revisões. Um certificado vem de um organismo acreditado, e não fingimos ser um.
Vocês exigem um scanner específico?
Não. O controle é o ponto. O produto é escolhido depois que o pipeline e a licença são conhecidos.
Traga a restrição, não uma lista de ferramentas.
Dizemos o que entra no escopo, o que fica de fora e o que contaria como prova.