Notas da linha.

A maior parte da threat intel não é para si. A parte útil é uma resposta rápida a uma pergunta: este aviso está no que realmente corremos?

Rastreie um container em produção até ao seu commit, build e pull request usando image digests, labels OCI e attestations.

Os revisores obrigatórios num ambiente de produção só funcionam se quem escreveu a alteração não a puder também aprovar. Corra esta checklist para descobrir.

Uma checklist para fazer numa reunião antes de convidar investigadores externos: básico de divulgação, scope, SLAs de triage, estrutura de recompensas e o ciclo que transforma relatórios em correções.

Cinco controlos, um dia de trabalho: disco cifrado, secrets fora dos dotfiles, chaves SSH protegidas, commits assinados e tokens que só fazem o seu trabalho.

O controlo de acessos quebrado é o bug que o QA está mais bem posicionado para apanhar. Uma matriz de papel por endpoint e algumas linhas de pytest tornam-no rotina.

Cada achado de pentest diz-lhe como alguém o atacou. Use-o duas vezes: corrija o bug e depois escreva a deteção que teria apanhado a tentativa.

Encaminhe todos os pacotes por um proxy, faça as versões novas esperar alguns dias, desligue os install scripts e deixe o lockfile decidir.

Políticas curtas mapeadas para controlos reais, com evidências recolhidas dos seus pipelines, valem mais do que documentos longos que ninguém abre até à auditoria.

Não consegue fazer revisão de segurança a cada pull request. Encaminhe os poucos que importam para quem sabe o que procurar, usando caminhos e CODEOWNERS.

As extensões de editor correm como o seu código, com os seus ficheiros e os seus tokens. Como funcionam, como fazer o inventário e como construir uma allowlist que as pessoas aceitem.

Três artefactos, três perguntas: o que está lá dentro, quem o construiu e se foi alterado. Eis como produzir e verificar cada um.

Um plano estação a estação para o engenheiro de segurança solitário, mais quatro métricas que mostram se o programa está mesmo a funcionar.

Um único documento de threat model fica desatualizado na semana a seguir ao workshop. Divida-o em camadas e atualize cada uma quando essa camada mudar.

Um servidor MCP corre com os seus tokens, o seu sistema de ficheiros e a sua rede. Eis o que isso significa, e como fazer o inventário e limitar o seu scope.

As tags mudam, os SHAs não. Faça pin de cada action, deixe um bot mantê-las atualizadas e reduza o token ao que cada job precisa.

Um relatório de pentest é uma lista de bugs com evidências. Faça triage, reproduza, corrija a causa raiz e garanta que nenhum finding consegue voltar sem ninguém dar por isso.

Se o seu diagrama de arquitetura não mostra onde muda a confiança, não lhe pode dizer para onde vão os ataques. Eis como desenhar um que o faça.

Correr todos os scanners em cada commit é fácil. Conseguir que os programadores leiam o output é o verdadeiro trabalho, e começa por mostrar menos.

Quatro formas de um pacote malicioso chegar ao seu build, como é cada uma num manifest ou num log, e como verificar o seu caso.

Quando contratar, que perfil procurar primeiro, o que os primeiros 90 dias devem produzir e quando um lead fracionado é a jogada inicial mais inteligente.

Escreva a misuse story no mesmo ticket que a funcionalidade, e os requisitos de segurança deixam de ser um documento que ninguém abre.

Porque é que os melhores threat models acontecem com negócio, programadores e cyber na mesma sala, e como conduzir um numa hora.