preparo para a era da IA
12 artigos com esta tag
Segurança para a era da IA: os fundamentos para blindar agora (checklist por prioridade)
A IA em sua maior parte amplifica ataques sobre fraquezas EXISTENTES (CVEs sem correção, senhas reutilizadas, segredos expostos) em vez de inventar novas — encontradas de forma automática, rápida e em escala. Então a melhor preparação é blindar os fundamentos na ordem certa: correção de CVE + monitoramento de dependências, acabar com reutilização + MFA, remover segredos expostos, menor privilégio, reduzir a superfície pública, logs/IOCs, backups.
O que funciona (e o que não funciona) na segurança da era da IA — por que sites pequenos também são atingidos
Quatro mitos da era da IA corrigidos: (1) pequeno demais para ser alvo → a automação remove 'um humano te escolhe'; (2) precisa de um novo controle especial → o básico ainda vence; (3) um produto te deixa seguro → design de prevenção antes da detecção; (4) código de IA é rápido então é seguro → ele vem com vulnerabilidades, revise antes de publicar. O que funciona é o básico tedioso na ordem certa.
Um e-mail de phishing falsificou seu próprio domínio? Spoofing vs invasão, e como impedir
Um e-mail suspeito que parece vir do seu próprio domínio geralmente não é uma invasão — é um From falsificado, porque o SMTP deixa qualquer um escrever a linha From. Ler os headers (Authentication-Results, Received, Reply-To) distingue invasão de falsificação. A principal razão de ele chegar à caixa de entrada é uma política DMARC ausente. Corrija com SPF → DKIM → DMARC (p=none → reject).
Escolhendo MFA do jeito certo: o que significa 'resistente a phishing' e por que o SMS é fraco
MFA é uma segunda fechadura para que uma senha vazada sozinha não consiga entrar — mas o que você ativa muda sua força em três níveis. Códigos por SMS/e-mail caem diante de phishing por relay e SIM-swap; apps autenticadores (TOTP) ficam no meio; passkeys/chaves de segurança (FIDO2) não podem ser apresentados a um site falso de jeito nenhum — essa é a resistência a phishing. Prioridade máxima: coloque MFA resistente a phishing nas chaves do reino (e-mail, domínio, pagamentos). Guardar os códigos de recuperação e ter um fator de backup completam a configuração.
Fundamentos de backup: a regra 3-2-1 e um plano de recuperação que sobrevive a ransomware
'Tenho um backup' não basta — só um backup que você verificou ser restaurável é real. O básico: a regra 3-2-1 (três cópias, dois tipos de mídia, uma fora do local). Para ransomware você também precisa de ao menos uma cópia 'offline ou imutável' — um backup sempre conectado é criptografado junto com o original. Sincronização na nuvem não é backup (ela replica exclusões e criptografia também). Versionamento e um teste de restauração periódico completam a prática.
Gerenciadores de senhas são seguros? Como funcionam, nuvem vs. local e como escolher
Um gerenciador de senhas é mais seguro que reutilizar ou guardar em texto puro. A chave é a criptografia de conhecimento zero: sua senha-mestra descriptografa o cofre só no seu dispositivo, o provedor guarda apenas o texto cifrado, então uma invasão do provedor não expõe suas senhas. O ponto único real é sua senha-mestra mais o MFA do cofre. Escolha nuvem (Bitwarden/1Password) ou local (KeePass) pelo uso.
A base de segurança para devs independentes e pequenos operadores: o conjunto-padrão completo
A base não é 'tudo igualmente importante'. A ordem de prioridade deste site: 1) chaves do reino (MFA, domínio, e-mail), 2) segredos e código, 3) o próprio app, 4) corrigir, detectar, recuperar. Com tempo finito, preencha de cima para baixo. A maioria das invasões sérias vem não de ataques inéditos, mas de uma falha nesta base.
Corrigindo CVEs de dependências de verdade: varrer, corrigir, isolar e seguir vigiando
O trabalho de vulnerabilidade não termina quando você 'corrige'. Pronto = 1) varrer, 2) corrigir, 3) isolar/repassar, 4) monitorar. Até o monitoramento (detecção de mudança diária) estar no lugar, está incompleto — dependências voltam a ser vulneráveis amanhã. Uma correção perfeita que o próximo deploy sobrescreve vale zero. Equipes pequenas se mantêm seguras com duas disciplinas: detecção de mudança automatizada e 'local→push→deploy'.
Instalando e usando o osv-scanner: encontre CVEs nas suas dependências
O osv-scanner escaneia lockfiles e containers para revelar CVEs nas suas dependências, de graça. Este guia percorre a instalação, a execução e a integração ao CI, além de quando usá-lo vs. npm/pnpm audit vs. Dependabot. A visão deste site: a ferramenta certa é decidida pela SUA configuração — use o osv-scanner em projetos multi-ecossistema ou sem GitHub, e o pnpm audit embutido para uma única árvore npm.
Você deixou um arquivo de segredo em um diretório público? Audite seu webroot
Qualquer coisa no seu webroot pode ser baixada pela URL por qualquer um. Um JSON de token/credenciais esquecido, um .env ou um backup significam exposição instantânea — e se veio de um template compartilhado, todo site tem o mesmo buraco. Correção: coloque no diretório público só o que pode ser compartilhado, mantenha segredos fora do webroot com permissão 600 e, ao achar um, audite todos os sites e hosts.
Não dê chaves de root a ambientes que podem ser comprometidos: menor privilégio para chaves SSH
Cadastrar uma chave de root em produção a partir de um ambiente efêmero e comprometível (pod de GPU, runner de CI, VM descartável) significa que, no momento em que o ambiente é comprometido, produção é tomada com root. Correção: sem chaves de root em ambientes efêmeros; remova chaves quando não usadas; se precisar de novo, use um usuário sem root mais uma chave restrita a comando que limita a chave a uma operação. Uma chave reutilizada é seu ativo mais crítico — nunca construa um cenário de 'um vazamento, tudo'.
Código escrito por IA vazou uma chave de API e gerou cobranças fraudulentas — a verdadeira causa foi um CVSS 10.0 sem correção
O pico na fatura era um sintoma. A causa real foi um RCE público CVSS 10.0 sem correção. Um caso anonimizado, destilado em lições defensivas.