AI-era readiness
12 articles with this tag
Security for the AI era: the basics to lock down now (priority checklist)
AI mostly amplifies attacks on EXISTING weaknesses (unpatched CVEs, reused passwords, exposed secrets) rather than inventing new ones — found automatically, fast, at scale. So the best preparation is locking down the basics in the right order: CVE patching + dependency monitoring, kill reuse + MFA, remove exposed secrets, least privilege, shrink the public surface, logs/IOCs, backups.
What works (and what doesn't) for AI-era security — why small sites get hit too
Four AI-era myths corrected: (1) too small to be targeted → automation removes 'a human picks you'; (2) needs a special new control → the basics still win; (3) a product makes you safe → prevention design before detection; (4) AI code is fast so it's safe → it ships with vulns, review before publishing. What works is the boring basics in the right order.
A phishing email forged your own domain? Spoofing vs a breach, and how to stop it
A suspicious email that appears to come from your own domain is usually not a breach — it's a forged From, because SMTP lets anyone write the From line. Reading the headers (Authentication-Results, Received, Reply-To) tells a breach from a forgery. The main reason it reaches your inbox is a missing DMARC policy. Fix it with SPF → DKIM → DMARC (p=none → reject).
Choosing MFA the right way: what 'phishing-resistant' means, and why SMS is weak
MFA is a second lock so a leaked password alone can't get you in — but what you turn on changes its strength by three tiers. SMS/email codes fall to relay phishing and SIM-swap; authenticator apps (TOTP) are mid; passkeys/security keys (FIDO2) can't be presented to a fake site at all — that's phishing resistance. Top priority: put phishing-resistant MFA on the keys to the kingdom (email, domain, payments). Storing recovery codes and having a backup factor complete the setup.
Backup essentials: the 3-2-1 rule and a recovery plan that survives ransomware
'I have a backup' isn't enough — only a backup you've verified you can restore is real. The basics: the 3-2-1 rule (three copies, two media types, one offsite). For ransomware you also need at least one 'offline or immutable' copy — an always-connected backup gets encrypted along with the original. Cloud sync is not a backup (it replicates deletions and encryption too). Versioning and a periodic restore test complete the practice.
Are password managers safe? How they work, cloud vs local, and how to choose
A password manager is safer than reuse or plaintext storage. The key is zero-knowledge encryption: your master password decrypts the vault only on your device, the provider holds only ciphertext, so a provider breach doesn't expose your passwords. The real single point is your master password plus vault MFA. Choose cloud (Bitwarden/1Password) or local (KeePass) by use.
The security baseline for indie devs and small operators: the whole standard set
The baseline isn't 'all equally important.' This site's priority order: 1) keys to the kingdom (MFA, domain, email), 2) secrets and code, 3) the app itself, 4) patch, detect, recover. With finite time, fill it top-down. Most serious breaches come not from novel attacks but from a gap in this foundation.
Installing and using osv-scanner: find CVEs in your dependencies
osv-scanner scans lockfiles and containers to surface CVEs in your dependencies, free. This walks through install, run, and CI integration, plus when to use it vs npm/pnpm audit vs Dependabot. This site's view: the right tool is decided by YOUR setup — reach for osv-scanner on multi-ecosystem or GitHub-free projects, and the bundled pnpm audit for a single npm tree.
Did you leave a secret file in a public directory? Audit your webroot
Anything in your webroot is fetchable by URL by anyone. A leftover token/credential JSON, .env, or backup means instant exposure — and if it came from a shared template, every site has the same hole. Fix: put only publicly-shareable things in the public dir, keep secrets outside the webroot at perms 600, and once you find one, audit every site and host.
Don't give root keys to environments that can be compromised: SSH key least privilege
Registering a root key into production from an ephemeral, compromisable environment (GPU pod, CI runner, throwaway VM) means that the moment the environment is compromised, production is taken with root. Fix: no root keys on ephemeral environments; remove keys when unused; if needed again, use a non-root user plus a command-restricted key that limits the key to one operation. A reused key is your most critical asset — never build a 'one leak, everything' setup.
Fixing dependency CVEs for real: scan, fix, isolate, and keep watching
Vulnerability work isn't done when you 'fix it.' Done = 1) scan, 2) fix, 3) isolate/hand off, 4) monitor. Until monitoring (daily change-detection) is in place, it's incomplete — dependencies turn vulnerable again tomorrow. A perfect fix that the next deploy overwrites is worth zero. Small teams stay safe with two disciplines: automated change-detection and 'local→push→deploy.'
AI-written code leaked an API key and ran up fraudulent charges — the real cause was an unpatched CVSS 10.0
The bill spike was a symptom. The real cause was an unpatched, public CVSS 10.0 RCE. An anonymized case, distilled into defensive lessons.