Tema: security
-
Monitorar a expiração de certificados TLS em todos os endpoints, não só no site principal
Um certificado expirado é uma indisponibilidade com hora exatamente previsível: sonde de fora a data notAfter de cada certificado realmente servido (web, API, e-mail, painéis internos, balanceadores de carga), alerte com antecedência suficiente para renovar manualmente e verifique também os intermediários, não só o certificado final.
-
Como verificar se uma conexão TLS realmente negociou X25519MLKEM768
Diferencie a capacidade pós-quântica instalada do grupo selecionado em uma conexão TLS real, usando detalhes do navegador, OpenSSL, curl e evidências do servidor.
-
Logs de auditoria: o que registrar, como mantê-los íntegros e quem pode lê-los
Um log de auditoria responde a quem fez o quê, em qual objeto, quando e com que resultado. É gravado pela aplicação para cada ação relevante para a segurança, mantido separado dos logs de depuração, protegido contra alterações ao ser enviado rapidamente para armazenamento append-only ou write-once, e lido apenas mediante acesso restrito e registrado.
-
Correção de KEVs do kernel Linux: verificar cada CVE no pacote da distribuição e no kernel em execução
Acompanhe separadamente cinco falhas exploradas do kernel. Use as correções de pacotes de cada distribuição e confirme o kernel iniciado ou a cobertura explícita de livepatch; mitigar um subsistema não resolve as falhas dos demais.
-
Um segredo foi commitado: por que apagar o arquivo não basta e qual é a ordem de resposta
Uma credencial enviada a um repositório Git permanece no histórico, em forks, clones, caches e logs de CI. Reescrever o histórico reduz a exposição futura, mas não recolhe as cópias já feitas; por isso, primeiro revogue e troque a credencial, depois limpe o histórico e, por fim, verifique se ela foi usada.
-
Permissões de arquivos no Unix e a umask
Cada arquivo tem bits de permissão de leitura, escrita e execução para dono, grupo e outros, além dos bits setuid, setgid e sticky; os arquivos novos recebem permissões a partir da umask do processo. Segredos devem ficar em arquivos 0600, diretórios precisam de execução para serem atravessados e serviços devem rodar com um usuário dedicado.
-
System Integrity Protection e Signed System Volume: o que protegem e por que não desativá-los
O SIP impede até o root de modificar caminhos protegidos do sistema ou processos protegidos; o Signed System Volume sela criptograficamente todo o volume do sistema e o verifica a cada boot. Juntos, explicam por que /usr/local é gravável e /usr não, e por que desativar o SIP não é uma solução legítima para um erro de permissão.
-
Como projetar rate limits que protegem o serviço e informam o cliente
Limite pela identidade que você consegue verificar (conta, prefixo de rede), use contadores atômicos em janelas fixas ou deslizantes, responda com 429 e Retry-After, mantenha orçamentos separados para leituras, escritas e registros e publique os limites efetivos.
-
Política do sudo em arquivos drop-in em /etc/sudoers.d, verificados com visudo -c
Adicionar uma regra restrita como arquivo próprio em /etc/sudoers.d, validado com o visudo antes de entrar em vigor, mantém a política do sudo auditável e evita que um erro de sintaxe bloqueie o acesso de todos. Esta metodologia também aborda o risco de regras NOPASSWD amplas e onde o sudo registra suas decisões.
-
Vincular a identidade de publicação no npm e no PyPI aos artefatos de lançamento aprovados
A publicação confiável via OIDC elimina tokens de publicação armazenados, mas sua segurança ainda depende do workflow autorizado. Separe build e publicação, proteja as aprovações e verifique a identidade do artefato, sem tratar a proveniência como um veredito sobre a presença de malware.
-
Passo a passo de um serviço de upload de arquivos: tickets de envio direto ao storage, varredura assíncrona e cotas
Um passo a passo de design para uploads que não passam pelos servidores de aplicação: um ticket que reserva cota e devolve uma URL assinada de envio, uma etapa de conclusão que verifica o objeto armazenado, um worker de varredura que o promove ou o apaga, regras de ciclo de vida para uploads abandonados e um modelo de status que explica cada objeto armazenado.
-
Prevenção de cross-site scripting com codificação de saída
Faça o escape dos dados conforme o contexto exato em que são inseridos (texto HTML, atributo, JavaScript, URL, CSS), use templates que fazem escape por padrão, nunca monte HTML por concatenação de strings e reforce tudo com uma CSP rigorosa.
-
Cisco Secure Email Gateway e SD-WAN Manager: verificar correções e preservar evidências de comprometimento
Mantenha registros de remediação separados para o scanner de e-mail e o SD-WAN Manager. Verifique as correções efetivamente instaladas, preserve evidências antes de uma recuperação que altere o estado do sistema e siga o procedimento de investigação específico de cada produto.
-
Serviços de links curtos com identificadores sequenciais recebem mais requisições de enumeração do que serviços com identificadores aleatórios
Hipótese: num encurtador de URLs cujas chaves são um contador codificado em base62, qualquer pessoa consegue percorrer todos os links, enquanto chaves aleatórias de comprimento fixo fazem a maioria das tentativas falhar. Propõe-se que os serviços sequenciais recebam uma fatia maior de requisições a chaves existentes vindas de clientes que nunca receberam o link, e que a taxa de respostas 404 não distinga os dois tipos.
-
Preparar o fluxo de tratamento de vulnerabilidades de um fabricante para o CRA: recebimento, evidências e contagem dos prazos de notificação
Um protocolo de preparação proposto conecta o recebimento de relatos de vulnerabilidades e os registros de componentes à decisão de notificar segundo o CRA. Ele separa a obrigação de notificação já aplicável em 2026 dos requisitos mais amplos de tratamento de vulnerabilidades aplicáveis em dezembro de 2027.
-
A especificação Standard Webhooks versus o cabeçalho HMAC da Shopify e o token de segredo compartilhado do GitLab
A especificação Standard Webhooks define os cabeçalhos webhook-id, webhook-timestamp e webhook-signature, um segredo em base64 com prefixo whsec_ cujos bytes decodificados são a chave HMAC e uma assinatura v1,<base64> sobre "{id}.{timestamp}.{payload}"; os tokens de assinatura do GitLab (GitLab 19.0, disponibilidade geral na 19.1) seguem exatamente esse modelo. A Shopify, por sua vez, envia em X-Shopify-Hmac-SHA256 um HMAC em base64 do corpo bruto, e o X-Gitlab-Token mais antigo do GitLab é apenas um segredo compartilhado, sem HMAC algum.
-
Verificação de pacotes RPM instalados contra adulteração com rpm -V
O `rpm -V` compara os arquivos instalados com os checksums, permissões e proprietários registrados na instalação do pacote, e os códigos de uma letra na saída indicam exatamente o que mudou. Esta metodologia explica como ler essa saída e quais são seus limites como verificação de integridade.
-
A Same-Origin Policy: o que é uma origem e o que ela isola
Uma origem é o conjunto formado por esquema, host e porta de uma URL. Scripts podem ler e modificar documentos, armazenamento e respostas da mesma origem; leituras entre origens são bloqueadas por padrão, enquanto escritas (como envio de formulários) e incorporações (como imagens e scripts) costumam ser permitidas. O CORS flexibiliza as leituras; as defesas contra CSRF continuam necessárias.
-
Após a chegada de um relatório de vulnerabilidade: confirmar, avaliar, corrigir em privado e divulgar
Quando um relatório chega ao contato de segurança do projeto, o trabalho segue uma sequência com datas: confirmar o recebimento rapidamente, classificar (comportamento esperado, bug, pedido de funcionalidade ou vulnerabilidade), combinar um embargo com quem reportou, desenvolver a correção em privado, obter um identificador CVE e então lançar a versão e publicar um aviso que indique as versões afetadas e corrigidas e dê crédito a quem reportou. O guia de mantenedores da OpenSSF e as orientações de divulgação do GitHub descrevem esse processo; este artigo o resume para projetos com um a cinco mantenedores.
-
Sandbox para ações de agentes: limites de sistema de arquivos, rede e credenciais
Um agente que executa comandos ou código deve fazê-lo dentro de um limite que restrinja quais arquivos ele pode tocar, quais hosts pode acessar e quais segredos pode ler. Os blocos de construção são contêineres com capabilities removidas e perfil seccomp, kernels em espaço de usuário como o gVisor, rede com bloqueio por padrão e credenciais de curta duração com escopo restrito.
Legível por máquina: JSON