Devops on Samarthya

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.

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.

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.

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.

Kafka JMX: What to Enable and What It Actually Measures

Sat, 11 Oct 2025 00:00:00 +0000

Kafka was running, producers were sending messages, and yet I still felt I was operating it by looking at the console and guessing. I wanted numbers that could tell me whether the broker was busy, whether consumers were falling behind, and whether replication was healthy.

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: 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.

Kafka Cluster Fundamentals: Brokers, Topics, and Partitions

Sat, 18 Jan 2025 00:00:00 +0000

I spent a fair amount of time looking at Kafka command output before the vocabulary settled in my head. Once I understood the difference between a broker, a topic, and a partition, the cluster stopped looking like one large mysterious system.

ZooKeeper Explained: Coordination Behind a Kafka Cluster

Sat, 23 Nov 2024 00:00:00 +0000

When I first came across ZooKeeper in a Kafka deployment, I treated it as another dependency that had to be started before Kafka. That explanation was not good enough. I wanted to know what it was actually doing when a broker disappeared or a controller changed.

A Maintainable Ansible Playbook Structure

Sat, 14 Sep 2024 00:00:00 +0000

My first Ansible playbook was a single file. It installed packages, created users, copied configuration, and restarted services. It was a reasonable starting point. The problem began when every change required editing the same file, which had quietly become a miniature operating system.

Ansible Magic Variables: Useful Context Without Guesswork

Sat, 08 Jun 2024 00:00:00 +0000

The first time I saw hostvars inside a Jinja expression I thought Ansible had become much cleverer than I was. It was useful, but it also made the playbook harder to read. After a few such expressions, I went back and learned what Ansible calls magic variables.

Ansible Configuration: Make the Defaults Explicit

Sat, 16 Mar 2024 00:00:00 +0000

When I first used Ansible, I was happy that it worked without a configuration file. Later, the same playbook behaved differently depending on which folder I ran it from. That was the point at which I stopped treating the defaults as magic and created a small project-level ansible.cfg.

Getting Started with Ansible: From One Command to a Playbook

Sun, 21 Jan 2024 00:00:00 +0000

I had been writing shell commands for every small infrastructure change. It worked, until I needed to repeat the same change on another machine and could no longer remember which command I had run first. That was my reason for starting with Ansible.

Snapshot & Restore

Wed, 26 Feb 2020 08:58:21 +0000

If you have a production grade elastic cluster it is always recommended to do a regular backup as a standard practice.

Snapshot is a backup of information, that can be be used to restore the last known good state of the system