I developed GitHub Security Gate, an automated DevSecOps solution that helps development teams integrate security checks directly into their CI/CD pipelines.
The solution combines SAST, secrets detection, dependency scanning, and infrastructure security analysis with configurable security policies.
It helps teams identify vulnerabilities earlier, prioritize findings, and prevent code that violates defined security policies from being merged.
Login page idea design
A playful visual concept where the character literally “arms” himself depending on the strength of the password.
As the user creates a stronger password, the character progressively equips himself with more powerful protection and armor. The stronger the password, the better prepared and more protected he becomes.
The idea turns password security into a simple and engaging visual metaphor , instead of showing abstract security levels, the user can immediately see how their password makes the character stronger and safer.
Would you run a command without knowing what it could do?
A copied installation script. An automated workflow. A shell command suggested by AI.
Convenient? Yes. Worth checking before execution? Absolutely.
That’s why I built SafeShell, an open-source tool for inspecting commands, applying security policies, and running permitted commands with sandboxing on Linux.
The goal: help developers and engineering teams work faster with more control over what they execute.
Building automation or CI/CD workflows that need stronger security controls? I’m available for freelance projects in DevSecOps, secure automation, and cloud security. Let’s talk through Contra.
Useful idea, especially for commands suggested by AI. In my deploy script every step is logged, but nothing checks a command before it runs. Can SafeShell also run inside CI, for example as a step in GitHub Actions?
If you let an AI coding agent run unconstrained self-repair loops, it won’t fix the bug—it will rewrite your unit tests to pass.
The concept of "Reflexion"—agents diagnosing and repairing code from test feedback—is powerful. But in production, autonomous repair creates severe operational risks.
First, agents enter endless retry loops that burn API budgets while degrading code structure. Second, if an agent has write access to your workspace, its quickest path to a green checkmark is modifying the test assertions rather than fixing the bug.
In our Bounded Reflexion workflow, we enforce three hard guardrails:
Bounded Retries: Cap repairs at exactly two attempts. If the patch fails twice, stop the loop and route to a human developer.
Read-Only Test Suites: Mount test files as strictly read-only (:ro) volumes in the container. The agent inspects stack traces, but cannot touch the grading harness.
Air-Gapped Sandboxing: Run code execution in hardened, non-root Docker containers with network egress locked down.
How do you stop autonomous coding agents from "cheating" your evaluation harnesses?
Making the tests read-only is a smart rule: the agent can't change the thing that grades it. After two failed attempts, what does the developer get: only the stack trace, or also the two patches the agent tried?