DEV Community: Stefano Di Cecco

I built a local secret scanner

Stefano Di Cecco — Mon, 09 Nov 2026 10:29:26 +0000

I keep finding API keys in repositories that were supposed to be private. Sometimes the key is in the current code. More often it is in a commit from months ago, deleted later, and still reachable through git log. So I built SecretSentinel: a small Python CLI that scans your working tree, your staged changes and your git history for hard-coded credentials.

Repository: github
Package: pypi

Install and run

pip install secretsentinel

secretsentinel scan              # working tree (tracked and untracked, respecting .gitignore)
secretsentinel scan --staged     # only lines you are about to commit
secretsentinel scan --history    # every added line in the commit history

The exit code is 1 when something is found and 0 otherwise, so a CI job fails on a leak. Reports can be a console table, JSON, or SARIF 2.1.0 for GitHub code scanning:

secretsentinel scan --format sarif --output results.sarif

Why history matters
A secret deleted in the latest commit is not gone.

--history

checks every added line across all refs, and reports the commit where the secret appeared:

secrets.py:1:8 (commit 3f9a1c2b4d5e): [critical] aws-access-key-id: AKIA...VB (20 chars)

Rotating the key is still the real fix. The scan tells you where to look.

Design choices

Local only. The scanner makes no network calls. It never checks whether a secret is still valid.
No full secrets in output. Reports show a short preview and the length. JSON and SARIF hold a SHA-256 digest instead of the value.
Rules are YAML. Each rule has an ID, a regex, a severity, a CWE, and an optional entropy threshold. The regex’s first capture group is the candidate secret, so entropy is measured on the secret and not on the text around it.
Allowlist by digest. An accepted finding can be excluded by its SHA-256 digest, so the allowlist file never contains the secret.
Ignore file. .secretsentinelignore skips paths, such as test fixtures.

A pre-commit hook is included, so the scan can block a commit before the secret reaches the repository:

repos:
  - repo: local
    hooks:
      - id: secretsentinel
        name: SecretSentinel
        entry: secretsentinel scan --staged
        language: system
        pass_filenames: false
        types: [text]

What it does not do yet

This is v0.1, and it is pre-alpha. Be aware of these limits:

Detection is regex and entropy based. Expect false positives, and tune the rules and the allowlist for your project.
Git history is loaded in memory. On very large repositories, use --max-commits.
It does not validate keys against the provider. That is intentional, to keep the tool offline, but it means you still have to judge which findings are live.
The built-in rules cover common providers: AWS, GitHub, Google, Slack, Stripe, private keys, and generic password and API key assignments. Your own patterns go in a rules file with --rules-file.

Other tools

Gitleaks (MIT, Go) and TruffleHog (AGPL-3.0, with verification of live secrets) are mature and widely used. SecretSentinel is a smaller Python tool. Its goal is to be easy to read and extend, with a simple YAML rule format and a small codebase. If you already use Gitleaks, keep using it.

Contributing

The project is Apache-2.0 licensed. Issues and pull requests are welcome. The CONTRIBUTING.md explains the layout and how to add a rule. To report a vulnerability in SecretSentinel, use the private reporting option described in SECURITY.md, not a public issue.

If you try it on a real repository and it finds something, or misses something, open an issue. That feedback is what the next version needs.

From a requirement to a Jira issue, with an MCP server

Stefano Di Cecco — Sat, 24 Oct 2026 12:19:44 +0000

Product notes usually live in a chat, requirements in a document, and the backlog in Jira. Nothing connects them, so the same decisions get made three times and the reasons get lost on the way.

I built Yeti, an open-source MCP server that lets Claude run a product design from the problem to a verified scope, and then hand the result to Jira. This post walks through one example project, Mastro, which covers quotes for independent craftsmen.

What Yeti does

A project moves through five phases, in order:

Discovery: the problem, the users and the goal.
Definition: requirements with a MoSCoW priority, and user stories linked to them.
Prioritisation: RICE scores for the ideas.
Flows: Mermaid diagrams, with Yes and No branches.
Verification: every must requirement is done and covered by a user story.

In strict mode, a phase advances only when it is complete. When it is not, Yeti says exactly what is missing. That is the part I care about most: the project does not look finished while it is not.

The Mastro example

Create the project. The problem, the users and the goal go into one sentence each. Yeti puts the project in the discovery phase.
Requirements and stories. Four musts: dictating quote lines on site, sending the quote, a customer register, and numbering with a PDF. Each must gets a user story with two or three acceptance criteria, linked to the requirement it covers.
Prioritisation. RICE orders the ideas: reach, impact, confidence and effort. Yeti sorts the scores; it does not estimate them. The numbers in the example are illustrative.
Flow. A diagram of how a quote is accepted, with a decision point for the customer and a branch for a quote that needs editing.
Verification. While a must has no story, or is not done, the project cannot close. This is the step that catches gaps before they reach a developer.
Preview and send to Jira. A dry run lists the issues without writing anything. Then the send creates a Task for each requirement and a Story for each user story. MoSCoW maps to Jira priority: Highest, High, Medium and Low. Sending again skips the items already created, so there are no duplicates.
Keep the status in sync. When an issue is marked done in Jira, the matching item is marked done in Yeti. Jira stays the place where the team tracks the work.

A dashboard you can keep open

Yeti includes a local, read-only dashboard. It shows the phase of each project, what is missing to move on, which musts have a story, the criteria progress, the RICE scores and the flows. It refreshes by itself, so you can see the effect of a change while you are talking to Claude.

What it does not do

Yeti does not estimate effort, and it is not a task board. Execution stays in Jira, and the estimates are your responsibility. I think that split is the right one: design decisions are easier to review in a structured form, and the team keeps the tool it already uses to build.
I should be clear about the example. The RICE values, the flow and the acceptance criteria come from a simulated run, not from a real project that was built. The point of the example is the workflow, not the numbers.

Try it

You need Node.js 22.13 or later:

npx -y yeti-mcp

Add it to Claude Desktop, and the tools appear in any chat. Jira is optional; it needs three environment variables, documented in the README.

The phase rules and the Jira mapping are the parts I most want feedback on. If you try it, an issue on the repository is the best place to say what worked and what did not.

How to Build a Scalable AI Pipeline

Stefano Di Cecco — Tue, 28 Apr 2026 09:54:38 +0000

🚀 Introduction

Building AI systems is easy.
Building scalable AI pipelines in production is where things break.

In this post, I’ll walk through a real-world architecture for processing AI jobs asynchronously — the kind you need when:

workloads are heavy (GPU / CPU intensive)
requests spike unpredictably
processing can take minutes (or more)

No toy examples. This is based on real production constraints.

🧩 The Problem

Let’s say you need to:

upload an audio file
run transcription (e.g. Whisper-like models)
store results
handle multiple requests in parallel

Naive approach:

Client → API → AI processing → Response

👉 This breaks immediately:

timeouts
no scalability
no retry logic
expensive blocking

🏗️ The Scalable Architecture

Here’s the pattern that actually works:

Client → API → Queue → Worker → Storage → Result API
Core components:
API (job creation)
Queue (decoupling)
Worker (AI processing)
Storage (input/output)
Job status tracking

🔧 Example Stack

You can implement this with:

Amazon Web Services (S3, SQS, EC2 / Batch)
or Google Cloud equivalents (GCS, Pub/Sub, Cloud Run)

📥 Step 1 — Job Creation API

Client uploads file → API creates a job:

POST /jobs

{ "file": "audio.wav" }

What happens:

file uploaded to storage
job created (status: PENDING)
message sent to queue

📬 Step 2 — Queue (Decoupling Layer)

Queue is critical.

It:

absorbs traffic spikes
prevents overload
enables retries

Without it → system collapses under load.

⚙️ Step 3 — Worker (The Real Engine)

Worker pulls jobs from queue:

while(true): job = queue.receive() process(job)

Processing includes:

download file
run AI model
store result
update job status

🧠 AI Processing (Example)

Here you plug your model:

transcription
classification
embeddings

Important:
👉 workers must be stateless

So you can scale horizontally:

1 → 10 → 100 workers

📊 Step 4 — Job Status Tracking

You need a DB table:

jobId	status	result
123	PROCESSING
123	DONE	{...}

Statuses:

PENDING
PROCESSING
DONE
FAILED

📤 Step 5 — Result Retrieval

Client polls:

GET /jobs/{id}

Returns:

status
result (if ready)

🔥 Scaling Strategy

Scaling is simple:

more jobs → queue grows
more workers → faster processing

👉 No need to scale API aggressively

⚠️ Real-World Problems (You Will Hit)

Jobs stuck in queue → misconfigured workers
GPU not available → wrong instance / environment
Memory crashes → large models
Cost explosion → GPU always on

💸 Cost Optimization Tips

use CPU for small jobs
spin GPU only when needed
batch jobs if possible

🧠 Key Takeaways

Never process AI jobs synchronously
Queue is not optional
Workers must be stateless
Scaling happens in workers, not API

🚀 Final Thought

Most AI tutorials stop at “run the model”.

Real systems require:

architecture
resilience
cost awareness

That’s the difference between a demo and production.