DEV Community: sachin k

A Package You Use Was Just Compromised. Now What?

sachin k — Thu, 20 Aug 2026 13:14:19 +0000

There are plenty of good posts about preventing supply-chain attacks: **ignore-scripts=true, minimumReleaseAge,** frozen lockfiles, provenance checks. Read them. Apply them.

But all of those posts end at the same cliff. What happens when prevention fails?

You open Slack and see: "lib-x versions 4.2.1 to 4.2.3 were compromised, malicious postinstall, rotate your creds." Your heart rate doubles. What do you actually type into your terminal right now?

Nobody writes that post, so I did. A 60-minute playbook, in order, with the exact commands. It assumes npm/pnpm/yarn or pip/uv, but the logic ports anywhere.

Minute 0-10: Answer one question first. Did I ever resolve the bad version?

Don't rotate anything yet. Don't panic-delete node_modules. First establish whether you were ever exposed, because "we depend on lib-x" and "we installed lib-x 4.2.2" are very different incidents.

Check what's installed right now

`# npm / pnpm / yarn: shows every resolved copy, including transitive
npm ls lib-x --all
pnpm why lib-x
yarn why lib-x`

# Python
`pip show lib-x
uv pip list | grep lib-x`
Check the lockfile, including its history

Your current lockfile might be clean while last Tuesday's wasn't. The exposure window is every commit where the lockfile referenced a bad version:

`# Every lockfile commit that ever mentioned the package
git log --follow -p -- package-lock.json | grep -n -B2 -A2 '"lib-x"'`

Faster: which commits introduced/removed the bad version string

git log -S '4.2.2' --oneline -- package-lock.json pnpm-lock.yaml yarn.lock

Python equivalents

`git log -S 'lib-x==4.2.2' --oneline -- requirements.txt uv.lock poetry.lock`

Don't forget branches and open PRs

A Renovate or Dependabot PR sitting open with the bad version has already been installed by CI on every push to that branch:

`# Search the bad version across ALL branches
git grep '4.2.2' $(git for-each-ref --format='%(refname)' refs/remotes) -- '*lock*'`

Decision point. If the bad version never appeared anywhere, you're done. Write two sentences in your incident channel, add the prevention controls, go back to work. If it appears in any lockfile, on any branch, at any point in the disclosed window, keep reading. You are now in incident mode.

Minute 10-20: Could the payload have executed?

Compromised is not the same as executed. Figure out which class of payload you're dealing with. Advisories usually say.

Class A: install-time payload (preinstall/postinstall, setup.py). It ran on every machine that installed it. Every dev laptop, every CI runner, every Docker build. If you run with ignore-scripts=true (or pnpm's default script blocking, or Bun), your laptops may be fine. Check CI separately though, because CI configs often differ from local ones.

`# Did this environment allow scripts?
npm config get ignore-scripts        # want: true
pnpm config get ignore-scripts`

Class B: runtime payload (malicious code inside the module itself). Installing it was harmless. Importing it was not. Now the question is which processes loaded it: your app in prod, your test suite in CI, a build script?

`# Was it actually imported anywhere, or just present in the tree?
grep -rn "require(['\"]lib-x" src/ scripts/
grep -rn "from ['\"]lib-x" src/
# Python
grep -rn "import lib_x\|from lib_x" .`

Write down your blast radius in one line. Something like: "Class A payload, scripts enabled in CI but not laptops, CI ran 14 installs between Aug 12 and Aug 18." Everything after this is scoped by that sentence.

*Minute 20-35: Contain. Rotate what the payload could reach.
*
This is the step people do in the wrong order. Rotate before cleanup, because your cleanup commits will trigger CI, and if CI secrets are burned you're re-exposing fresh code to a compromised environment.

Recent real-world payloads (the Shai-Hulud-style worms) go straight for tokens. Assume the payload harvested every credential readable from the environment it ran in.

If it ran in CI:
All repo/org secrets in that CI system (GitHub Actions secrets, GitLab variables)

Cloud credentials. Prefer OIDC federation over static keys going forward, but rotate any static AWS_/GCP_ keys now.
NPM_TOKEN / PYPI_TOKEN. Top priority if you publish packages. This is how one compromise becomes a worm: your token publishes the next infected version.

`# npm: list and revoke tokens
npm token list
npm token revoke <id>`

`# GitHub: check for tokens/keys you didn't create
gh api /user/keys
gh auth status`

If it ran on laptops:

~/.npmrc and ~/.pypirc tokens
SSH keys, gh CLI tokens, long-lived cloud creds in ~/.aws/credentials
.env files in project directories. These are exactly what the payloads grab.

Also check for persistence. Several npm worms added malicious GitHub Actions workflows or new repos using stolen tokens:

`# Recently created/modified workflows across your org
gh api "search/code?q=org:YOUR_ORG+path:.github/workflows&sort=indexed" \
  --jq '.items[].repository.full_name' | sort -u`

`# Repos created during the exposure window
gh repo list YOUR_ORG --limit 200 --json name,createdAt \
  --jq '.[] | select(.createdAt > "2026-08-12")'`

*Minute 35-50: Eradicate the version, and every cache holding it
*
Fixing package.json is the easy 10%. The tarball is also sitting in caches that will happily re-serve it.

`1. Force a safe version everywhere, including transitive deps
jsonc
// package.json (npm)
"overrides": { "lib-x": "4.2.0" }

// pnpm: pnpm-workspace.yaml (or package.json pnpm.overrides)
// overrides:
//   lib-x: 4.2.0

// yarn
"resolutions": { "lib-x": "4.2.0" }
bash
# Python: pin explicitly, even if it's transitive
echo "lib-x==4.2.0" >> requirements.txt   # or constraints.txt
uv lock --upgrade-package lib-x==4.2.0`

Then regenerate and diff the lockfile by hand before committing. You're looking for the bad version disappearing and nothing suspicious appearing.

Purge every cache layer

`# Local
rm -rf node_modules
npm cache clean --force
pnpm store prune
yarn cache clean
pip cache purge && uv cache clean
`
# CI caches. This is the one everyone forgets.
# GitHub Actions: delete caches so restored node_modules can't resurrect the payload
gh cache list
gh cache delete --all

# **Docker:** layer caches can pin the bad tarball indefinitely
docker builder prune --all

If you run a registry proxy (Artifactory, Verdaccio, Nexus), purge the bad version there too. Otherwise every future install in your org re-downloads it from your own mirror.

*3. Rebuild and redeploy anything built in the window
*
Any artifact (Docker image, Lambda zip, frontend bundle) built while the bad version was resolvable is suspect. Rebuild from the fixed lockfile, redeploy, and if you keep image digests, note which digests were built in the window.

Minute 50-60: Verify, then write it down

`# Confirm the bad version is gone from the tree
npm ls lib-x --all
# Confirm the lockfile can't drift
npm ci        # or: pnpm install --frozen-lockfile
# Confirm integrity/signatures on what you now have
npm audit signatures`

Then write a short postmortem. Five lines, in the incident channel, today:

Exposure window: first commit to fix commit, with timestamps
Blast radius: which environments installed it, whether scripts or imports executed
What was rotated (and what deliberately wasn't, and why)
Caches purged, artifacts rebuilt
The prevention gap that let it in, with one linked follow-up ticket

That last line is where all those prevention articles finally become relevant: ignore-scripts=true, a release-age cooldown (minimum-release-age in npm 11.10+, on by default in pnpm 11, npmMinimalAgeGate in Yarn 4.10+), frozen-lockfile installs in CI, and OIDC instead of static cloud keys. Prevention posts tell you to do these things. An incident tells you which one you actually needed.

The 10-second version to bookmark

`1. git log -S '<bad-version>' -- <lockfiles>     -> was I ever exposed? (all branches!)
2. Install-time or runtime payload?              -> scope: laptops vs CI vs prod
3. Rotate: publish tokens > CI secrets > cloud keys > laptop creds
4. Check persistence: new workflows, new repos, new tokens
5. overrides/resolutions pin + purge npm/pnpm/CI/Docker caches
6. Rebuild artifacts from the window; redeploy
7. npm ci + npm audit signatures                 -> verify
8. Five-line postmortem + one prevention ticket`

Prevention articles get written because prevention is comfortable. Incident response gets skipped because it's the part where you were already wrong. The window between "compromise published" and "compromise detected" will never be zero, which means this playbook isn't a nice-to-have. It's the half of supply-chain security we all stopped writing about.

If you've lived through one of these, drop your war story in the comments. Especially the cache layer you forgot.

Cybersecurity from Zero to Hero #4: Passwords and Hashing, or Why a Good Site Cannot Tell You Your Own Password

sachin k — Thu, 20 Aug 2026 13:00:38 +0000

Welcome back to Cybersecurity from Zero to Hero, the series where I learn security from scratch and write it down while the confusion is still fresh. In post three we separated authentication from authorization. Today we go inside the most common authentication factor on earth: the password, and the strange one way math that protects it.

Here is the question that unlocked this whole topic for me. When you click Forgot Password, why does every decent site send you a reset link instead of just telling you your password? The answer is not policy. The answer is that a well built site literally does not know your password. And that is exactly how it should be.

🥣 Hashing: the one way blender

When you create an account, a good site never stores the password you typed. Instead it runs the password through a hash function and stores only the result.

A hash function is like a blender. Drop in an apple and you get a very specific smoothie. Drop in the same apple tomorrow and you get the same smoothie. But no power on earth un-blends the smoothie back into the apple. That is the whole trick: same input always gives the same output, and the process only runs one direction.

So the login flow works like this. You type your password. The site blends it. It compares your fresh smoothie to the smoothie it stored on day one. Match means you knew the password. The site verified your password without ever storing it.

Now the Forgot Password mystery solves itself. The site cannot email you your password because all it has is the smoothie. The only honest option is a reset link that lets you make a new one.

💻 What I actually did: hashing my first strings in Python

This is the first hands on in the series that uses code, and it needs nothing but Python's standard library. Fifteen lines, no installs:

`python
import hashlib

def hash_it(text):
return hashlib.sha256(text.encode()).hexdigest()

print(hash_it("hello"))
print(hash_it("hello"))
print(hash_it("Hello"))`

Three things jumped out the moment I ran it.

Same input, same output. The first two lines print identical hashes. Deterministic, as promised.

Tiny change, chaos. Capitalizing one letter produced a hash with no resemblance to the first. This is called the avalanche effect, and it is why hashes make great tamper detectors. It is the same property we used in post one when we verified a download with a checksum. Different purpose, same math.

Any size in, same size out. I hashed a single letter and then a whole paragraph. Both came out as 64 hex characters. A hash is a fingerprint, not a container.

If you followed my Python series, this is where the two tracks officially shake hands. If not, you can still run those five lines in any online Python playground and see it yourself.

🔓 So how do passwords get cracked at all?

If hashing cannot be reversed, why do we keep hearing about cracked password databases? Because attackers do not reverse the blender. They run the blender forward, billions of times.

Take every common password, hash each one, and compare the results against the stolen database. Whenever a hash matches, you have found someone's password. Precomputed versions of this are called rainbow tables, and against common passwords they work depressingly well.

This is exactly why two defenses exist:

Salting. The site adds a random string to your password before hashing, and stores the salt alongside the hash. Now two users with the same password get different hashes, and precomputed tables become useless. Every guess has to be recomputed per user.

Slow hashing. SHA 256 is designed to be fast, which is great for checksums and terrible for passwords, because fast for you is fast for attackers. Password storage uses deliberately slow functions like bcrypt or argon2 that turn billions of guesses per second into thousands. My demo above uses SHA 256 because it ships with Python and shows the concepts perfectly, but hear this clearly: real systems must never store passwords with plain SHA 256.

And the math behind length beats everything. Each extra character multiplies the guessing work. This is why every serious guide says the same boring thing: long unique passwords in a password manager beat clever short ones every time. In post two my worst risk score was password reuse. This post is the reason it scored so high: one cracked database anywhere unlocks every account where I reused that password.

🤔 What confused me today

If hashes are one way, how does my password manager show me my passwords? Because a password manager does not hash, it encrypts. Encryption is a two way door that opens with a key, in this case my master password. Hashing is for verifying, encryption is for retrieving. Two different tools that beginner me had filed in the same drawer.

What are collisions? In theory two different inputs could produce the same hash, since infinite inputs map to fixed size outputs. For SHA-256, nobody has ever found one, and the numbers involved are absurd. Older functions like MD5 have real, demonstrated collisions, which is why you still see MD5 in tutorials but never in serious modern systems.

⏭️ Next in this series

Post 5 covers multi-factor authentication, including what actually happens inside that six-digit code app and why the codes keep working with your phone in airplane mode. The hands on part sets one up and proves that offline trick. Follow the series so you do not miss it.

Cybersecurity from Zero to Hero #3: Authentication vs Authorization, or Why the Bouncer Checks Your ID Twice

sachin k — Thu, 20 Aug 2026 12:56:12 +0000

Welcome back to Cybersecurity from Zero to Hero, the series where I learn security from scratch and write it down while the confusion is still fresh. In post two we untangled threats, vulnerabilities and risk. Today we tackle two words that even experienced developers mix up in conversation: authentication and authorization.

They sound alike, they often happen within the same second, and they get abbreviated to the nearly identical authn and authz. But they answer two completely different questions, and confusing them has caused real breaches.

🎟️ The nightclub analogy

Picture a nightclub with a bouncer and a VIP area.

Authentication asks: who are you, and can you prove it? That is the bouncer at the front door checking your ID against your face. You claim an identity, then you prove it. If the proof fails, you never get inside at all.

Authorization asks: what are you allowed to do now that you are inside? Your regular ticket gets you the main floor. It does not get you into the VIP area, and it definitely does not get you behind the bar pouring drinks. The second bouncer at the VIP rope is not asking who you are again. He is asking what your ticket permits.

One sentence to remember forever: authentication is about identity, authorization is about permission. You cannot have the second without the first, but proving who you are never automatically entitles you to everything.

💻 Translating it to computers

Authentication is the login. Username plus password, a fingerprint, a code from your authenticator app. The system verifies you are who you claim to be. We will spend two full posts on this soon, because passwords and multi-factor authentication each deserve their own deep dive.

Authorization is everything after the login. Can this account read that file? Can it delete other users? Can it see the admin dashboard? In real systems this runs through things like roles and permissions. A regular user and an admin might log in through the same screen, and the difference between them is pure authorization.

Here is why the distinction matters for security. Some of the ugliest vulnerabilities are authorization failures, not authentication failures. The attacker logs in as a completely legitimate low level user, then reaches data or actions that should have been off limits. Nothing about the login was broken. The system simply forgot to check the ticket at the VIP rope. In the web security world this shows up as broken access control, and it currently sits at the very top of the OWASP Top 10 list of web application risks. We will meet it hands on in phase four of this series.

A tiny example of the difference in code terms. Changing a URL from /account/1234 to /account/1235 and seeing someone else's data is an authorization failure. Guessing someone's password is an authentication failure. Same damage, totally different broken door.

📝 What I actually did: mapping a real login flow

The hands on exercise this time needs nothing but a browser. I picked a site I use daily and wrote down every identity and permission step from arrival to action. Try it with any site you like. Mine looked like this:

Step 1, the claim. I typed my email. That is me claiming an identity. No proof yet.

Step 2, the proof. I typed my password. First authentication factor: something I know.

Step 3, more proof. The site asked for a six digit code from my phone. Second factor: something I have. Two proofs, one identity. This is multi-factor authentication, coming up in post 5.

Step 4, the session. After login the site set a cookie in my browser. I found it in DevTools under Application, then Cookies. That cookie is my wristband. For the rest of the visit the site checks the wristband, not my ID. This also explains something I never understood before: logging out just destroys the wristband. My password did not change. The session ended.

Step 5, the permissions. I opened my account settings and saw sections I can use, and I remembered that an admin of the same site sees panels I do not. Same login flow, different tickets. That gap between what I see and what an admin sees is authorization, drawn as a user interface.

Five steps, and the first three were authentication while the last two were session and authorization. Once you map one site this way, you start seeing the pattern absolutely everywhere.

🤔 What confused me today

Is the session cookie authentication or authorization? It puzzled me because it feels like both. The cleanest answer I found: the cookie is proof of an already completed authentication, a temporary stand in for your ID so you do not retype your password on every click. The system still runs authorization checks against your permissions on every request. The wristband proves you were checked at the door. It does not decide what you may touch.

Why do sites make me re-enter my password before sensitive actions like changing email? Now I can name it: that is reauthentication. The site trusts the wristband for browsing, but for dangerous actions it wants fresh proof of identity, in case someone walked up to my unlocked laptop. Annoying, and correct. It is the same tension we met in post one between availability and confidentiality.

⏭️ Next in this series

Post 4 covers passwords and hashing, including why a well built site literally cannot tell you your own password, and why that is exactly how it should be. The hands on part builds a tiny hashing demo in Python. Follow the series so you do not miss it.

Cybersecurity from Zero to Hero #2: Threats, Vulnerabilities and Risk Are Not the Same Thing

sachin k — Tue, 18 Aug 2026 11:14:57 +0000

Welcome back to Cybersecurity from Zero to Hero, the series where I learn security from scratch and write it down while the confusion is still fresh. In post one we met the CIA Triad, the three promises every security control exists to protect. Today we learn the three words that describe how those promises get broken.

Here is the problem. Security articles throw around threat, vulnerability and risk as if they were synonyms. They are not. Once I finally separated them, every security article I read became twice as clear, and I could suddenly follow conversations that used to sound like noise.

🏠 The house analogy that made it stick

Imagine your house.

A threat is anything out there that could cause harm. The burglar walking through your neighborhood. The storm forming offshore. The threat exists whether or not your house has any weaknesses. You do not control threats. They are simply out there.

A vulnerability is a weakness in your house. The broken lock on the back door. The window that does not close properly. A vulnerability by itself harms nothing. A broken lock in a neighborhood with zero burglars is just a broken lock.

Risk is what happens when the two meet. It is the likelihood that a threat actually exploits a vulnerability, multiplied by how bad it would be. Burglar in the area, plus broken lock, plus your laptop and passport sitting inside: now you have real risk.

The formula you will see everywhere in this field:

Risk = Threat x Vulnerability x Impact
Kill any one of the three and the risk collapses. You cannot remove the burglar, but you can fix the lock, or move the passport to a safe. That is what security work actually is: reducing risk by attacking the parts you control.

💻 Translating it to computers

The same three words, now in tech form:

Threats: ransomware gangs, phishing crews, a disgruntled employee, even a hurricane heading for a data center. Remember post one: not every threat is a hacker.

Vulnerabilities: an unpatched server, a weak password, an employee who has never heard of phishing, a database left open to the internet.

Risk: an active ransomware gang targeting your industry, plus your unpatched server, plus that server holding customer data. High likelihood, high impact, high risk.

This also explains something that used to puzzle me. Why do companies leave some known vulnerabilities unfixed? Because risk is a business decision. If the vulnerability sits on an internal test machine with no valuable data, the risk is low and the fix can wait. Security teams do not fix everything. They fix what matters most first. That is called risk management, and it is the actual day job behind most security roles.

📝 *What I actually did: rating three risks in my own life
*
Reading definitions is easy, so I forced myself to apply them. I listed three real risks in my own digital life and scored likelihood and impact from 1 to 5.

Risk 1: password reuse. Threat: credential stuffing attacks using leaked password lists. Vulnerability: I reuse a password across several old accounts. Likelihood 4, impact 4. Score 16, my worst one. The fix costs nothing: a password manager and an hour of cleanup. That is this weekend's task.

Risk 2: phishing. Threat: phishing emails, which everyone receives. Vulnerability: I read email fast and on my phone, where sender addresses are hidden by default. Likelihood 3, impact 4, score 12. Fix: slow down on anything asking me to click or log in.

Risk 3: laptop theft. Threat: ordinary theft in cafes and transit. Vulnerability: my disk was not encrypted. Likelihood 2, impact 5, score 10. Fix: I turned on full disk encryption today. It took five minutes and one restart. If you do nothing else after reading this, check yours: BitLocker on Windows, FileVault on Mac.

Try this exercise yourself. Three risks, two scores each, five minutes. It turns abstract vocabulary into a to do list, and it is exactly what professional risk assessments do at a much larger scale.

🤔 What confused me today

Is a hacker a threat or a threat actor? Strictly, the person or group is the threat actor, and the thing they might do is the threat. A ransomware gang is the actor, ransomware attack is the threat. People mix these constantly and the world keeps turning, but knowing the distinction helps when reading serious reports.

Where do exploits fit? An exploit is the actual tool or technique that takes advantage of a vulnerability. Broken lock is the vulnerability, the crowbar technique is the exploit. We will meet real ones later in the series, safely and legally.

⏭️ Next in this series

Post 3 covers authentication versus authorization, the difference between proving who you are and what you are allowed to do. It is the concept behind every login screen you have ever seen, and the hands on part maps a real website login flow. Follow the series so you do not miss it.

Smashing a hidden I/O bug: 100 disk reads per run for data that never changed

sachin k — Mon, 17 Aug 2026 16:48:54 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

awesome-tech-newsletter is an open-source project by Infrasity Labs that auto-discovers tech newsletters across the web. It runs a fleet of Python fetchers — for Substack, Hacker News, Medium, Product Hunt, Beehiiv, Hashnode, and more — that crawl each platform, classify what they find against a shared keyword config, and aggregate everything into a curated, categorized directory in the README.

Bug Fix or Performance Improvement

I picked this off the project's open issue tracker: issue #41, a performance bug in the Product Hunt fetcher.

The fetcher pulls 100 recent posts from the Product Hunt GraphQL API, then loops over them to classify each post against a list of keyword queries. The problem was this line, sitting inside the per-post loop:

for post_edge in posts:
    # ...build text_corpus...
    queries = get_search_queries(append_newsletter=False)  # <-- every iteration
    for query, cat in queries:
        ...

That looks like a harmless list rebuild — until you read what get_search_queries() actually does:

def get_search_queries(append_newsletter=True):
    config_path = os.path.join(..., "config.json")
    with open(config_path, "r", encoding="utf-8") as f:   # disk read
        categories = json.load(f)                          # JSON parse
    # ...build query list...

It opens and JSON-parses config.json from disk on every single call. So every fetch run was doing 100 file opens and 100 JSON parses for data that cannot change mid-loop.

The smoking gun that this was a bug and not a design choice: every other fetcher in the repo (hackernews.py, substack.py, medium.py, and six more) calls get_search_queries() exactly once, outside its loop. Only producthunt.py did it per-post.

Measured impact (benchmarked against the repo's real config.json — 9 categories, 86 generated queries — with 100 simulated posts):

Metric (per fetch run)	Before	After
`config.json` file opens	100	1
JSON parses	100	1
Classification loop time	5.14 ms	0.14 ms (~36× faster)

Honest framing: this is a scheduled crawler, so no user was staring at a spinner. But the cost scales with post count × config size, and redundant loop-invariant I/O is exactly the kind of silent tax that compounds as a project grows.

Code

PR: https://github.com/Infrasity-Labs/awesome-tech-newsletter/pull/43

The full change:

             posts = data.get('data', {}).get('posts', {}).get('edges', [])

+            # Load search queries once: get_search_queries() reads and parses
+            # config.json from disk on every call, and its result never changes
+            # within a fetch run, so calling it per-post did 100 redundant
+            # file reads + JSON parses.
+            queries = get_search_queries(append_newsletter=False)
+            seen_urls = set()
+
             for post_edge in posts:
                 node = post_edge.get('node', {})
@@
-                queries = get_search_queries(append_newsletter=False)
-                for query, cat in queries:
-                    if query in text_corpus:
+                for keyword, cat in queries:
+                    if keyword in text_corpus:
                         is_tech = True
                         category = cat
                         break
@@
-                    if not any(d['url'] == target_url for d in discovered):
+                    if target_url not in seen_urls:
+                        seen_urls.add(target_url)
                         logger.info("Discovered Product Hunt: %s", target_url)

My Improvements

Three changes, in decreasing order of importance:

1. Hoisted the loop-invariant call. get_search_queries() now runs once per fetch, right after the API response is parsed. This turns 100 disk reads + JSON parses into 1. I deliberately did not add caching inside get_search_queries() itself — that would change behavior for every fetcher and risk serving stale config in long-lived processes. Fixing it at the single bad call site keeps the change surgical and matches the pattern the other nine fetchers already use.

2. Fixed a variable-shadowing landmine. The inner loop used for query, cat in queries: — but query was already the name of the GraphQL query string defined earlier in the same function. It happened to be harmless today because the GraphQL string isn't reused after the request, but it's the kind of shadowing that turns a future "add retry logic" PR into a mystery bug. Renamed the loop variable to keyword.

3. Replaced an O(n²) dedup with a set. The duplicate-URL check was any(d['url'] == target_url for d in discovered) — a full list scan for every discovered post. A seen_urls set makes it O(1) per lookup. Minor at 100 posts, but free to fix while I was in the function.

Verification: the module compiles clean (python3 -m py_compile), imports, and runs correctly through its no-token code path. The benchmark hooked builtins.open to count file accesses, confirming the 100 → 1 drop, and used timeit over 20 repeats for the timing numbers.

Transparency note: I found, benchmarked, and fixed this bug working alongside Claude (Anthropic's AI assistant) — it ran the code analysis and benchmarking in a sandboxed environment while I directed the hunt, reviewed the changes, and submitted the PR.

Cybersecurity from Zero to Hero #1: The CIA Triad, or Why Your Bank App Keeps Logging You Out

sachin k — Mon, 17 Aug 2026 14:14:50 +0000

Welcome to post one of my new series, Cybersecurity from Zero to Hero. I am learning security from absolute scratch and writing about it as I go, so you get the explanations while the confusion is still fresh in my head. The plan is simple: concepts first, then networking, then Linux and web security, then real tools and practice platforms. No prior knowledge needed. If you are experienced, stick around anyway, because the comment sections are where you get to correct me and teach everyone else.

One rule before we start, and it applies to this entire series. Every hands on exercise happens only on systems I own or on platforms built for legal practice like TryHackMe and OWASP Juice Shop. Learning security responsibly is part of learning security.

Today we lay the foundation stone of all security thinking.

The one framework everything else builds on

Ask any security professional where to start and you will hear three letters: CIA. Not the agency. It stands for Confidentiality, Integrity and Availability, and it is the lens through which every security decision is made. Firewalls, passwords, backups, encryption, every tool you will ever meet in this field exists to protect one or more of these three properties.

Here is what surprised me on day one of studying this. Security is not about stopping hackers. It is about protecting these three promises, and hackers are only one of many things that threaten them. A flood in a data center is a security event. So is an intern deleting the wrong folder.

🔒 Confidentiality: only the right people can see it

Confidentiality means information is visible only to those authorized to see it. Your medical records, your salary, your private messages.

Real world example. When your banking app logs you out after five minutes of inactivity, that is confidentiality at work. The bank assumes you might have walked away from your phone in a coffee shop. The aggressive timeout is not bad design. It is a deliberate tradeoff that sacrifices your convenience to protect your account from the stranger at the next table.

Tools that protect it: encryption, passwords, multi factor authentication, access controls, and even the privacy screen on a laptop.

The classic violation: a data breach where customer records leak to the public.

✅ Integrity: the data has not been tampered with

Integrity means information stays accurate and unaltered except by authorized changes. It is the promise that what you read is what was written.

Real world example. When you transfer 100 dollars, integrity is the guarantee that it does not become 1000 dollars in transit, and that the recipient account number is not silently swapped. Banks obsess over this. An attacker who can change data is often more dangerous than one who can only read it.

I also ran my first integrity check today, and you can too. When you download software, sites often publish a checksum next to the file. On Mac or Linux:

bash shasum -a 256 downloaded_file.zip
On Windows PowerShell:

powershell Get-FileHash downloaded_file.zip

Compare the output to the published value. If even one character differs, the file was corrupted or tampered with somewhere between their server and your machine. That comparison is integrity verification in its purest form, and later in this series we will build our own hashing tool in Python.

Tools that protect it: hashing, checksums, digital signatures, version control, audit logs.

The classic violation: an attacker altering a student database to change grades.

⚡ Availability: the system works when you need it

Availability means authorized users can access the data and systems when they need them. Security that makes a system unusable has failed at its job.

Real world example. When a Distributed Denial of Service attack floods a website with junk traffic until it collapses, nothing was stolen and nothing was altered. Confidentiality and integrity are intact. But the service is down, so it is absolutely a security incident. Backups, failover systems and disaster recovery plans all exist to protect this leg of the triangle.

Tools that protect it: redundancy, backups, load balancing, DDoS protection, disaster recovery plans.

The classic violation: ransomware locking a hospital out of its own patient records.

🔺 The part that made it click for me: the triangle is a tension

Here is the insight most beginner summaries skip. The three properties pull against each other, and real security work is about balancing them, not maximizing all three.

Make a system maximally confidential with twelve authentication steps and you have destroyed availability. Nobody can get in, including the people who should. Make it maximally available with no logins at all and you have destroyed confidentiality. That annoying bank timeout is not a bug or lazy engineering. It is a chosen point on the triangle. Once I saw it this way, a dozen daily annoyances suddenly made sense as deliberate design decisions.

A question for the experienced folks. When you review a system, do you consciously walk the triad, or has it become instinct? And what is your favorite example of a control that helps one leg while hurting another? Drop it in the comments and I will feature the best answers in a future post.

🤔 What confused me today

Where does authenticity fit? Some sources add authenticity and non repudiation as extra properties, and some textbooks talk about a hexad instead of a triad. For now I am parking that question. The triad is the standard mental model and the extensions can wait until the fundamentals are solid.

Is a power outage really a security issue? My instinct said no, that is an IT problem. But under the triad, anything that threatens availability is in scope for security. The field is wider than the hacker movies suggest.

⏭️ Next in this series

Post 2 covers threats, vulnerabilities and risk, three words people use interchangeably that mean very different things. Once you can tell them apart, every security article you read becomes twice as clear. Follow the series so you do not miss it.