This site exists because most security advice sits at one of two extremes. Either it assumes you already work in the field, or it’s been simplified until following it doesn’t actually make you safer.

We’re aiming for the middle: clear enough to follow without a background in security, specific enough to be worth following.

What we’ll write about here

The blog is for things that are time-sensitive — a breach worth knowing about, a scam pattern making the rounds, a change in a product’s defaults that affects you. Anything durable goes in the guides instead, where it can be maintained rather than buried by newer posts.

A rough filter for what makes it onto this page:

  • Does it change what you should do? If the answer is no, it’s news, not advice.
  • Can we say what to do about it? Reporting a threat without a response is just anxiety with citations.
  • Is it still true next month? If yes, it probably belongs in a guide.

Formatting reference

Everything below is here so you can see how it renders. Delete it when you write your first real post.

Callouts

Three variants, for three levels of “pay attention”:

Worth knowing. Neutral context or an aside that supports the main point.

Be careful here. A common mistake, or a step where people typically go wrong.

Act on this. Active exploitation, an urgent patch, or something with a real deadline attached.

Lists, code, and quotes

An ordered list, for steps that happen in sequence:

  1. Confirm the report from a source you trust
  2. Check whether it applies to the software you actually run
  3. Patch, or apply the documented workaround
  4. Note the date you did it

Inline code works, and so do fenced blocks:

# Check which OpenSSH version you're running
ssh -V

Block quotes are for citing an advisory or another writer directly. Attribute the source and link it.

Tables

Severity What it means Typical response time
Critical Actively exploited, no workaround Same day
High Exploitable, workaround exists Within a week
Moderate Requires unusual conditions Next patch cycle

Writing your own post

  1. Copy this file to src/content/blog/your-slug.md
  2. Update the front matter — title, description, date, category, tags
  3. Delete everything below the front matter and write
  4. Preview with npm run dev, then commit and push

The description field matters more than it looks: it’s the excerpt on the blog index and the snippet search engines display. Write it as a real sentence, not a keyword list. It’s required — the build will tell you if it’s missing.