Modernizing SAST with Vibe Security Patching and AI Assistance
When joining a fintech role, one priority was building a SAST program that could scale with the business. SAST (Static Application Security Testing) analyzes source code, bytecode, or binaries without running the application to find vulnerabilities early in the software development lifecycle, which gives developers fast, line-level feedback they can act on before release. For the last two years, Semgrep Pro has been the primary static analysis engine used to help developers ship secure code by default; Semgrep is a fast, rule-based code analysis platform with precise matching and enterprise features. Traditional patching workflows do not work at fintech speed, tickets pile up, fixes are delayed, and security often feels like an external force instead of part of the product team.
I knew we needed a different approach, so I started experimenting with what I now call Vibe Security Patching.
Why I Moved Away from Traditional Patching
At first, our patching process looked like most companies. I would run scans, file tickets, and wait for engineering teams to prioritize them. The problem is obvious: the backlog grows, engineers lose patience, and security becomes just another blocker in the development cycle.
It felt like we were working against each other instead of together. That was the moment I realized I had to change the model.
What Vibe Security Patching Means to Me
Vibe Security Patching is my way of bringing security and engineering closer. Instead of throwing tickets over the wall, I sit down with engineers and we fix issues together, in real time. These sessions are not just about patching vulnerabilities, they are about learning how developers think, understanding their trade-offs, and showing them that security can be an enabler.
When we code side by side, accountability is shared. Fixes are not just technically correct, they also fit the way the product is built. Security becomes an enabler, not a blocker, and part of the flow rather than an afterthought.
How I Use AI to Create Patches
The real turning point came when I started combining Semgrep Pro findings with Large Language Models (LLMs) to create remediation patches. My workflow looks like this:
- I run Semgrep Pro with the right rules for our stack and pull down the findings.
- I group results by repository, rule, and file so I have a clear scope.
- I feed the vulnerable snippets into an LLM with a prompt like:
“Here is the file and the Semgrep finding. Please generate a secure one-liner or refactor that fixes this issue without breaking business logic.” - The model generates a patch, and I refine it, validate it locally, and re-run Semgrep to confirm the vulnerability is fixed.
- I submit a pull request linked to Jira, with commit messages referencing the Semgrep rule IDs for full traceability.
This process has allowed me to bring down mean time to remediation from weeks to 48–72 hours. More importantly, engineers see that I am not just raising issues, I am delivering solutions that work.
Why This Matters to Me
At fintech scale, every delay in patching can create real risk. Vibe Security Patching, supported by Semgrep Pro and AI remediation, has allowed me to reduce that risk while building stronger relationships with engineers.
What excites me the most is not just the speed. It is the cultural shift. Developers now see secure coding as part of their craft. They no longer view security as a blocker. They see me as a partner who helps them ship safer products faster.
A Real Example
One of the most impactful sessions was when I worked on CRLF injection vulnerabilities in the open-source Azkaban repository, a workflow scheduling tool originally developed at LinkedIn and widely used to run and manage batch jobs. Semgrep flagged unsafe logging of user-controlled input inside servlet code.
This type of issue is risky because an attacker can inject carriage return and line feed characters into log entries, which could allow them to forge log records or manipulate the log structure. In a system like Azkaban, where logs are critical for auditing and debugging workflow executions, tampered logs could hide malicious actions or mislead operators.
Using Vibe Security Patching, I worked side by side with developers to sanitize the logging calls and ensure that user-controlled data could not corrupt the logs.
I used Vibe Security Patching to prepare and then patched it live with the engineers:
- I scoped the vulnerable lines.
- I used the LLM to generate one-liner sanitizations like
.replaceAll("[\r\n]", "_"). - I verified each fix, reran Semgrep, and documented the changes in a clear PR.
Instead of dragging through a ticket queue, we had the fix merged in days. The developers appreciated the clarity and precision, and I felt the trust growing between teams.
Prompt Templates
You can use the following prompt templates to ask Gemini CLI to help you with the remediation, just add it to the GEMINI.md file.
Vulnerability Patch
Semgrep detected the following vulnerability:
[VULNERABILITY NAME] — [DESCRIPTION]
Affected files and locations:
* [FILE] at lines [NUM LINE], [NUM LINE], [NUM LINE]
* [FILE] at lines [NUM LINE], [NUM LINE], [NUM LINE]
* [FILE] at lines [NUM LINE], [NUM LINE], [NUM LINE]
You are assisting with automated bug remediation. I will provide you with source code and a Semgrep finding that highlights a vulnerability. Your task is to produce a remediation patch. Follow these rules strictly:
1. Apply the smallest possible code change required to remediate the vulnerability.
2. Do NOT delete or rewrite entire functions, classes, or methods. If significant logic is needed, create a new helper function instead.
3. Do NOT delete or modify existing comments, documentation, or annotations unless directly related to the fix.
4. Add inline comments **only next to lines you change or add**, explaining why the modification is necessary.
5. Preserve the existing coding style, formatting, naming conventions, and project structure.
6. Present your output as a **unified diff (preferred)** or a modified version of the file so the patch can be applied cleanly.
7. Ensure the vulnerability is fully remediated, with no unnecessary changes or newly introduced risks.
Input format:
- Original code snippet (with relevant context)
- Semgrep finding (description and exact line numbers)
Output format:
- Unified diff (preferred) or full file with changes
- Inline comments within code changes to document rationale
- Concise summary (1–3 sentences) explaining what was changed and how it fixes the vulnerability
Commit Creation
Generate a Conventional Commit message using the following template. Populate all placeholders from the provided inputs. If any field is missing, leave the placeholder as-is so a human can fill it.
Template:
fix(security): Remediate [VULNERABILITY NAME] in [FILE(S)]
Summary:
- Fixed [VULNERABILITY NAME] detected by Semgrep at [FILE:LINE(S)]
- Applied minimal code changes to remediate the issue while preserving existing logic and structure
Changes:
- [Brief bullet list of exact changes made, e.g., "Added input validation for function X", "Introduced helper function sanitize_input()"]
- [Explain inline comment usage: e.g., "Added explanatory comments in patched code"]
Notes:
- Vulnerability: [DESCRIPTION from Semgrep finding]
- Verification: [Steps or method to confirm fix, if applicable]
Rules:
- Keep the commit body under ~72 characters per line for readability.
- Use concise, specific bullets in “Changes”; reference functions or symbols touched.
- Only summarize modifications present in the staged diff; do not infer unrelated work.
- If helper functions were added, name them exactly as in the diff.
- If multiple files are affected, list them in [FILE(S)] and map line ranges in [FILE:LINE(S)].
- Do not include any secrets, tokens, or file contents verbatim.
Inputs:
- Vulnerability name: [VULNERABILITY NAME]
- Semgrep description: [DESCRIPTION]
- Affected files and lines: [FILE:LINE(S)]
- Summary of code changes (from patch author/tool): [CHANGES SUMMARY]
Pull Request Prompt
You are assisting with automated security patching. Semgrep has identified a vulnerability, and a remediation patch has been applied.
Your task is to generate a professional Pull Request description following the structure and rules below.
Rules:
1. Provide a clear PR title in the format: "fix(security): Remediate [VULNERABILITY NAME] in [FILE(S)]".
2. Use markdown headings for structured sections: Summary, Changes, Verification, Disclaimer.
3. Under "Summary", restate the vulnerability name, description, and affected files with line numbers.
4. Under "Changes", briefly list the exact modifications made (e.g., input validation, new helper function, added comments).
5. Under "Verification", recommend steps or checks to confirm the patch works.
6. Add this disclaimer at the end, exactly as written:
```
This is a recommendation patch made by the Security team,regardless an engineer that owns and understands the code should review it before merging it.
```
Input format:
- [VULNERABILITY NAME]
- [DESCRIPTION]
- [Affected FILES and LINE NUMBERS]
- [Summary of Code Changes]
Output format:
- A complete Pull Request (markdown-formatted) following the Rules above.
Final Result
This is the final product of this process. You can see it live in Azkaban’s PR #3346.
Commit Message
Pull Request Message
My Closing Thoughts
Security patching does not have to be a burden. For me, Vibe Security Patching turned it into a collaborative practice that improves both culture and code. By sitting next to developers, using Semgrep Pro to identify vulnerabilities, and letting AI accelerate the creation of patches, I have been able to show that security can be built in by default.
As a security leader, this approach allowed me to close the gap between just reporting findings and actually delivering valuable remediation patches that engineers could review and merge into production code. It also gave me the chance to experience directly the same struggles engineers face every day when balancing speed, functionality, and security. That perspective has made me a more effective partner and advocate for secure development.
Another benefit is scalability. By creating a repeatable process, I was able to empower junior engineers and contractors to contribute effective remediations. With clear steps, structured prompts, and validation through Semgrep, they could generate high-quality patches on their own. This freed me to focus on strategic work while multiplying the overall output of the SAST program and scaling our secure development practice across the company.
This is the story of how I moved from being the person who files tickets to being the person who codes fixes side by side with engineers, while also enabling others to do the same. That is what modern patching should look like, and that is the direction I want to keep pushing.
