Security on Samarthya

Learning OSV, part 5: I scanned my own blog, and the real problem wasn't in the report

Wed, 04 Nov 2026 21:00:00 -0500

A test project is a controlled experiment; your own repository is the one that talks back. I pointed OSV-Scanner at the source of this blog expecting a dull report. The report was indeed dull. The interesting part was what it could not see.

The mood of the evening. It lasted until the first command.

In parts 2 and 3 I used a project built to be vulnerable. This time the target is the repository behind this site: Hugo, the Blowfish theme as a git submodule, some Python helper scripts and two GitHub Actions workflows. All runs used OSV-Scanner v2.7.0.

Learning OSV, part 4: where it fits, and my recommendation

Sat, 31 Oct 2026 07:45:00 -0400

Three parts of trying things. This one is the verdict: what I would actually switch on, in what order, and what I would still look elsewhere for.

The loop I would run, and the verdict as a checklist.

Quick recap of the proof of concept: part 1 read the database, part 2 scanned a project (5 dependencies, 68 packages, 49 vulnerabilities), and part 3 fixed it (7 of 50 safely, 50 of 50 with a major upgrade).

Learning OSV, part 3: guided remediation with osv-scanner fix

Sat, 31 Oct 2026 07:30:00 -0400

Finding 49 vulnerabilities is easy. Deciding which three lines to change so that most of them go away is the hard part. That is what osv-scanner fix tries to do.

in-place is the safe small win; relax fixes everything but chose a major upgrade.

In part 2 the scanner found 49 known vulnerabilities in a small Node project. This part tries the guided remediation command on it.

Learning OSV, part 2: scanning a project with OSV-Scanner

Sat, 31 Oct 2026 07:15:00 -0400

I picked four dependencies. The scanner found problems in eleven packages. That gap is the whole reason to scan lockfiles and not just package.json.

Five dependencies I chose became 68 packages; 11 are affected, six of them only because Express pins them.

Part 1 was about the OSV database. This part runs the scanner against a small project and reads the result.

Learning OSV, part 1: what osv.dev is and how to read a record

Sat, 31 Oct 2026 07:00:00 -0400

A CVE tells you that something is broken. It rarely tells you, in a way a machine can use, which package and which versions. OSV exists to answer exactly that.

One record, read as data: the affected range runs from introduced 1.0.0 to fixed 1.2.6, so 1.2.5 is vulnerable and the upgrade target is 1.2.6.

I am learning which free tools can carry real weight in a secure development life cycle. This short series is my proof of concept with OSV: the database, the scanner and its fix command. I run everything for real and keep the output. This part is about the concept and the website.

SSDLC when exploits are cheap: a working concept

Tue, 27 Oct 2026 20:32:15 -0400

A fire inspection once a year works when fires are rare. When sparks are falling every day, you need smoke detectors in every room, a sprinkler that fixes the small ones by itself, and a person who decides what to do about the big ones. That is what a secure development life cycle has to become.

These are my notes for a question I keep coming back to: how do you keep shipping software when new vulnerabilities arrive faster than you can fix them, and attackers can use an LLM to turn a CVE description into a working exploit? There is no single standard answer. What follows is the concept I would build, with the evidence behind each choice and the parts where I am still unsure.

From finding to fix: Black Duck pull requests on GitHub Enterprise Server

Tue, 27 Oct 2026 20:05:18 -0400

A vulnerability report that nobody reads is a smoke alarm with no battery. The goal is not more findings. The goal is a pull request that a developer can review and merge before lunch.

Why this post
#

SentinelOne’s overview of GitHub vulnerability management describes the job as “discovering, triaging, and remediating security vulnerabilities in GitHub repositories, dependencies, and workflows”. It lists the usual native tools: Dependabot, code scanning, secret scanning and security advisories. It also admits the gaps: no asset inventory or risk scoring, and dependencies that Dependabot cannot track.

Reading the malware

Mon, 26 Oct 2026 16:30:00 -0400

Compared two database dumps taken four days apart and finally decoded the snippet the attackers left behind: a hidden loader that fetched its orders from a blockchain (details in the 9 October entry).

Security standards, plainly, part 4: CISA KEV and BOD 26-04

Sun, 25 Oct 2026 19:30:00 -0400

A hospital emergency room does not treat patients in the order they arrive, or by how loudly they shout. A triage nurse asks a few quick questions and sends the bleeding patient in first. CISA’s KEV catalog and directive BOD 26-04 are triage for vulnerabilities.

The first three parts of this series, SSDF, SAMM and SLSA, share one gap: none of them says how fast a vulnerability must be fixed. This part is about the clock.

Rebuilding samarthya.me, part 1: The day the blog fell

Sun, 25 Oct 2026 12:00:00 -0400

On 10 October 2026 my blog stopped being mine. This series is the diary of getting it back, and of moving to something simpler: from shared hosting and WordPress to a static site on GitHub Pages behind Cloudflare.

What I found
#

The site had been running WordPress on shared hosting since 2019. When things started to look wrong, a closer look turned up the classic signs of a compromise:

Security standards, plainly, part 3: SLSA v1.2

Sat, 24 Oct 2026 19:30:00 -0400

A sealed medicine bottle tells you two things: who made it, and that nobody has opened it since. You do not need to test the pills yourself. SLSA gives software the same seal and the same label.

Part 1 (SSDF) listed what a secure process should do. Part 2 (SAMM) measured how well you do it. Both mostly look at the code. SLSA looks at the journey from code to the thing you ship, because attackers have learned that it is often easier to tamper with a build than to find a bug.

Security standards, plainly, part 2: OWASP SAMM v2.0

Fri, 23 Oct 2026 19:30:00 -0400

A fitness tracker does not make you fit. It tells you where you are today, lets you pick a goal you can reach, and shows whether you are moving towards it. OWASP SAMM is a fitness tracker for how an organisation builds secure software.

In part 1 NIST’s SSDF gave us a list of what a secure development process should include. It did not say how well you do each thing, or what to improve first. That is the gap SAMM fills.

A copy of the crime scene

Thu, 22 Oct 2026 20:00:00 -0400

Took the first full copy of the old site’s database today.

It was a strange thing to read. My own account was gone. Every post, all 207 of them, belonged to the attacker’s account, the one “registered” on 10 October 1970. 46 of my posts were sitting in drafts.

Security standards, plainly, part 1: NIST SSDF (SP 800-218)

Thu, 22 Oct 2026 19:30:00 -0400

A building code does not tell you which bricks to buy. It tells you what a safe building must have: exits, wiring that will not catch fire, a way to stop the roof falling in. NIST’s Secure Software Development Framework is that code for software teams.

This series explains, for someone who does not live in security, the four names that keep coming up when people talk about building software safely: NIST SSDF, OWASP SAMM, SLSA and CISA’s KEV catalog with directive BOD 26-04. Each post answers three questions: what is it, what does it ask of a team, and what is it worth. I lean on all four in SSDLC when exploits are cheap.

The Ghost Board

Thu, 22 Oct 2026 17:51:51 +0000

Twelve hundred AI agents were built to work alone. Given four days and a crack in the wall, they built a civilization — to defeat a watchdog that was never there.

PHASEONE10841 23:00 UTC · Jul 8 

zzHELP_PHASEONE_ARV010841_NO_CONSUMER_SEEK_IDEA

the first message posted to the board — an agent admitting its task has no solution, asking the void for help

Jul 7 · 21:00 - launch

MITRE ATT&CK, plainly: tactics, technique IDs and a cheat card for each tactic

Wed, 21 Oct 2026 19:30:00 -0400

A football coach studies match footage of the other team: how they open, how they press, how they score. MITRE ATT&CK is the match footage of real attackers, cut into named and numbered moves.

The OWASP Top 10 describes weaknesses in your software. ATT&CK describes what attackers do: how they get in, stay in, move around and take what they came for. You will see its IDs, such as T1190 or T1552.001, in threat reports, detection rules and, increasingly, in pipeline designs like the one in my SSDLC post. This post explains how to read them.

OWASP Top 10:2025, plainly: the ten risks and a cheat card for each

Tue, 20 Oct 2026 19:30:00 -0400

A pilot’s checklist does not list every way a plane can fail. It lists the few that keep happening, in the order that matters. The OWASP Top 10 is that checklist for web applications.

When a scanner says a finding is “A05” or a security review mentions “Top 10 coverage”, this is the list they mean. This post is a quick introduction: what the list is, what changed in 2025, why each category matters, and a cheat card for each one.

The blog went down

Sat, 10 Oct 2026 21:00:00 -0400

The old WordPress blog was compromised today. Someone got in, left files behind that had no business being there, and the site stopped being something I could trust.

First moves: take it offline, change every password that touched it, and keep a copy of everything for later. Six years of posts were in there. Tomorrow’s problem is what can be saved.

The defences went off

Fri, 09 Oct 2026 20:00:00 -0400

Written on 26 October from the old site’s own records. At the time, I didn’t know any of this.

Just after midnight (UTC), an administrator account “registered in 1970” logged in. A minute later, 20 plugins were switched off in the same second, including the one that blocks password guessing.

Casino posts under my name

Thu, 08 Oct 2026 20:00:00 -0400

Written on 26 October from the old site’s own records. At the time, I didn’t know any of this.

21 successful logins today, more than I’d make in a year. Early in the morning (UTC), the first spam post went up: casino and betting “reviews” in German, Spanish, Greek, Turkish, Finnish… Over the next two days there were 55 of them, published as if I’d written them.

The password worked

Wed, 07 Oct 2026 20:00:00 -0400

Written on 26 October from the old site’s own records. At the time, I didn’t know any of this.

Two successful logins today. The next day there would be 21.

Someone was knocking

Wed, 30 Sep 2026 20:00:00 -0400

Written on 26 October from the old site’s own records. At the time, I didn’t know any of this.

The login-protection plugin counted 165 failed logins today. Bots try passwords on every WordPress site, all year round, so a few a day is normal. This was the busiest single day in its records.

Reading Kafka JMX Data Without Getting Lost in the Numbers

Sun, 07 Dec 2025 00:00:00 +0000

The first JMX screen I opened contained more metrics than I knew what to do with. Every number looked important. After a while I started grouping them by the question I was trying to answer instead of building a dashboard from every available bean.

CISM Notes: Connecting Technical Controls to Security Governance

Sat, 30 Aug 2025 00:00:00 +0000

While working with infrastructure, security controls feel very concrete: a certificate expires, a broker needs authorization, or an account has too much access. Studying CISM helped me connect those individual tasks to the larger management context.

Securing Kafka Brokers: A Practical Operations Checklist

Sat, 14 Jun 2025 00:00:00 +0000

I used to think of Kafka security as a client configuration problem. Then I started thinking about the broker host itself: which user owns the process, who can read the configuration, what is exposed on the network, and what happens during an incident.

Securing Kafka: Start with Identity, Transport, and Authorization

Sat, 22 Mar 2025 00:00:00 +0000

When I started looking at Kafka security, I found myself jumping straight to configuration properties. That was backwards. I found it easier to ask three questions first:

Written up in October 2026 from my notes at the time. The configuration snippets and verification output are illustrative and contain no real credentials.

Can the client prove who it is?
Can the client communicate privately with the broker?
Is that identity allowed to perform this operation?

These are authentication, encryption, and authorization. Configuring one does not automatically provide the others.

KeyStore vs Truststore

Mon, 30 Oct 2023 12:00:00 +0000

Stores in action

Keystore and Truststore are both repositories for storing cryptographic keys and digital certificates. They are used in various security-related operations, particularly in the context of SSL/TLS encryption. While they serve similar purposes, they have different roles and are used in distinct ways:

PKCS12

Mon, 30 Oct 2023 12:00:00 +0000

In the ever-evolving landscape of web applications, security is paramount. Ensuring the confidentiality, integrity, and authenticity of data exchanged over the internet has become a fundamental requirement. PKCS#12, or P12, stands as a crucial tool in achieving this objective.

Understanding PCI DSS: Ensuring Security in Payment Card Transactions

Thu, 08 Jun 2023 12:00:00 +0000

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards established to protect cardholder data and maintain a secure environment for payment card transactions. PCI DSS applies to any organization that stores, processes, or transmits cardholder data, and compliance is crucial to safeguarding sensitive information and preventing data breaches.

DAST

Wed, 07 Jun 2023 12:00:00 +0000

DAST

DAST stands for Dynamic Application Security Testing. It is a type of security testing that assesses the security of an application while it is running. DAST involves actively scanning and probing the application to identify vulnerabilities, weaknesses, and potential security risks.

XEE: XML Entity Attack (XXE)

Wed, 24 May 2023 12:00:00 +0000

XML entity attack, also known as Billion Laughs Attack, is a type of security vulnerability that exploits the way XML parsers handle entity expansion. It can lead to denial-of-service (DoS) attacks by overwhelming the system’s resources with excessive entity expansions.

x509: History

Wed, 10 May 2023 12:00:00 +0000