Security Guides

#AI-era readiness #security basics #CVE monitoring #MFA

Security for the AI era: the basics to lock down now (priority checklist)

AI lets attackers find ordinary weaknesses automatically and at scale. Patch CVEs fast, stop password reuse, remove exposed secrets: a priority checklist.

Published 2026-06-26 Updated 2026-10-06 9 min read

On this page

"When capable AI becomes common, what changes about security?" The answer is surprisingly mundane: you don't need a special new control; the value of doing the ordinary basics now goes up. Here's why, and the order to lock them down (defensively; no attack steps).

Why now

AI mostly amplifies attacks rather than inventing them. Defensively, watch these five directions (general trends you should know — no how-to details):

1) Automated recon / vulnerability discovery at scale (the whole internet, continuously)

2) Just-published CVEs exploited almost immediately (the disclosure→exploit gap shrinks)

3) Targeted phishing made fluent, personalized, and high-volume

4) Brute-force and credential stuffing accelerated

5) AI-written code shipped together with its vulnerabilities

AI amplifies attacks on ordinary weaknesses more than it creates new ones — so basic gaps get found first.

The common thread: each gets in through an ordinary, basic weakness. So the more you lock down the basics, the more even large-scale attacks fail to get in. The basic gaps you postponed are the first thing automated attacks find. That is why it matters now.

The numbers bear this out. Mandiant (Google Cloud) found the average time from a vulnerability's disclosure to its exploitation fell from 32 days in 2021–2022 to 5 days in 2023. In January 2024, the UK National Cyber Security Centre (NCSC) also assessed that AI will "almost certainly" increase the volume of cyber attacks over the next two years. A routine of updating once a month will sometimes be too slow.

Lock down in this order (priority checklist)

Top-down. Each item links to a detailed guide on this site.

Monitor dependency CVEs and patch fast

Known, published vulns are now exploited near-instantly. Let a machine watch so human oversight can't miss one (→ CVE remediation · monitor deps with OSV · Next.js CVE hygiene).

Stop password reuse and turn on MFA

The most effective measure against accelerated brute-force / credential stuffing. A password manager + phishing-resistant MFA/passkeys (→ password manager · MFA guide).

Remove exposed secret files

Audit for .env, keys, and backups left in the web root — automated scans grab these first (→ secrets in public directories · .env exposure case · .env & API key basics).

Least privilege, so a breach does less damage

If breached, limit the damage to one area. Keep keys and rights minimal (→ SSH key least privilege).

Shrink the public surface, stop spoofing

Close needless admin pages and risky files; use email auth to stop forgery of your own domain (→ email spoofing defense · CORS misconfig · session fixation).

Harden dependencies and Git

Prevent secret commits and protect your supply chain (→ block secrets with gitleaks · self-hosted Git vs GitHub).

Keep logs; be able to notice via IOCs

Perfect prevention is impossible — be able to spot what slips through by behavior (→ what is an IOC · IOA · EDR).

Have backups and recovery

Your fallback when other controls fail: a tested way to restore from ransomware or destruction (→ backup & recovery).

Quick table: frequency and tools

The eight items above, split into what to do first and how often afterwards. The frequencies are this site's recommended guideline.

Item	Do first	Then how often	Tools (mostly free)
1. Dependency vulnerabilities	Scan dependencies across every project once	Weekly, or automatically on each code change	osv-scanner, `npm audit`, `composer audit`, GitHub Dependabot alerts
1. Patch deadlines	Patch vulnerabilities confirmed as exploited (on KEV) first	KEV entries within days to two weeks	prioritizing with CVSS, EPSS, and KEV
2. Multi-factor authentication	Start with admin accounts for email, GitHub, cloud, and domain management	Each time you create an account	Passkeys, authenticator apps
3. Exposed secrets	Audit public directories and public repositories; revoke any key you find	Before every release	secret leak scanner, site audit
4. Least privilege	Disable unused keys, tokens, and accounts	Every three months	Each service's access token list
6. Git defenses	Add a check that stops secrets before commit	Automatic (every commit)	gitleaks, GitHub push protection
8. Backups	Store a copy elsewhere and try one restore	Restore test every three months	Provider snapshots, external storage

GitHub push protection is on by default when a personal account pushes to a public repository. It does not cover private repositories or other Git services, so pair it with a local check such as gitleaks.

Common mistakes and fixes

Common mistake	What happens	Fix
Receiving an update notice but not confirming it was applied	The hole stays open even though a fix exists	Check the version after updating and run the scan again
Deleting a leaked key from files and history, then stopping	If it is not revoked, anyone with a copy can still use it	Revoke it at the issuer first, then switch to a new key
Turning on MFA only for your own account	Someone gets in through a shared admin or old account	List every account with admin rights and turn it on for all
Keeping backups on the same server	If the server fails or is encrypted, the backup goes with it	Store it elsewhere and actually test a restore
Shipping AI-written config or code straight to production	Debug output or hard-coded secrets are left in	Run secret detection and a dependency scan before release

Real cases

The incident that started this site is a typical example. An API key was stolen soon after AI-written code was shipped, followed by fraudulent charges. The cause: a published top-severity CVE (CVSS 10.0) left unpatched for months. It is a concrete example of AI making unpatched weaknesses more costly (→ the AI-code API-key-leak case).

There are other cases of the same type.

Equifax (2017): the fix for the Apache Struts flaw was released the day it was disclosed, but it was not applied to a public system, and personal data on about 147 million people leaked. This is what skipping item 1 looks like (→ the Equifax breach).
Hugging Face (2026): the intrusion by a research AI agent started from credentials that had been exposed publicly. This is what skipping item 3 looks like (→ the Hugging Face intrusion).

This site's view: AI makes unpatched weaknesses more costly, so do the basics now

On this site we treat AI-era readiness as doing the basics sooner, not adding special new controls. What helps attackers most when capable AI is in their hands isn't inventing zero-days — it's finding and hitting the basics you postponed (unpatched, reused, exposed) cheaply and at scale. So what works is the boring basics, done in the right order, now. Check your own site with the site security audit, email-auth checker, and dependency scanner. Setting something up is not enough; it works only once you verify it.

Sources

Google Cloud (Mandiant), "How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends" — cloud.google.com
UK NCSC, "The near-term impact of AI on the cyber threat" (24 January 2024) — ncsc.gov.uk
US CISA, "BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities" — cisa.gov
GitHub Docs, "About push protection" — docs.github.com

FAQ

QDoes the AI era need some new, special security control?

Usually what you need isn't a special new control; it's doing the basics, in the right order, now. The biggest change capable AI brings isn't a new class of weakness; it's that the old, 'too tedious to bother' weaknesses (unpatched CVEs, reused passwords, secret files left public) can now be found and exploited automatically, fast, and at scale. So locking down the basics in priority order, as below, is the highest-return preparation.

QDo indie projects and small sites really get targeted?

Yes. Automated attacks skip the 'a human picks a target' step. They scan the whole internet continuously and hit wherever a weakness appears, indiscriminately — so size doesn't matter. 'We're too small to be a target' stops holding as automation and scale increase.

QWhere do I start?

The top of this priority checklist is enough. In particular: (1) dependency CVE monitoring + fast patching, (2) stopping password reuse + MFA, and (3) removing secret files left in public directories — these have the biggest payoff and you can start today. Check your own site's current state with this site's free tools.

QHow soon after disclosure should I patch a vulnerability?

For vulnerabilities confirmed as exploited, aim for within days. Mandiant's analysis found the average time from disclosure to exploitation was 5 days in 2023. As a public benchmark, the US CISA requires federal agencies to fix entries in its KEV catalog (the list of vulnerabilities confirmed as exploited) generally within two weeks (six months for CVE IDs assigned before 2021). For anything not on KEV, set the order using severity (CVSS) and likelihood of exploitation (EPSS).

QHow much can I do without spending money?

Most of this checklist is free. Dependency scanning works with osv-scanner, npm audit, or GitHub Dependabot alerts; blocking secret commits with gitleaks and GitHub push protection; and multi-factor authentication is built into most services. The costly parts tend to be detection products and backup storage, and both can wait until the basics are done.

QHow often should I revisit this checklist?

Run dependency scans weekly or automatically on every code change. Review accounts and keys, and test restoring a backup, about every three months. Also revisit it when you start using a new service or when the person in charge changes.