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.

Sast on Samarthya

SSDLC when exploits are cheap: a working concept

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

Why this post #

Why this post
#