After relying more heavily on AI-generated code snippets in VS Code, I realized my old workflow was missing important safety checks. I wanted something lightweight, practical, and realistic for solo developers, not enterprise only security tooling that requires a team to maintain. This is what I landed on.
“Vibe coding” has become the default workflow for many developers. Instead of writing every function from scratch, developers increasingly use tools like ChatGPT, Claude, and AI powered IDE assistants to generate snippets, debug logic, and scaffold projects faster than ever before.
The productivity boost is real. So are the security risks.
Many developers assume the primary danger is AI hallucinating incorrect code. In reality, the larger issue is often workflow security. Secrets accidentally committed to Git repositories, unsafe dependencies copied from AI suggestions, and vulnerable authentication patterns are becoming increasingly common.
The good news: securing an AI assisted development workflow does not require enterprise level tooling or a dedicated security team. A few lightweight habits and automated checks can dramatically reduce your exposure.
What You Are Actually Up Against
AI generated code introduces a different kind of risk than traditional development. You are no longer only responsible for bugs you personally wrote. You also need to think about:
Hidden vulnerabilities in generated code
Fake or malicious software packages suggested by AI
Exposed API keys or environment variables
Weak authentication or database logic
Prompt injection vulnerabilities in AI-integrated apps
Overtrusting generated code without validation
“AI coding assistants are fast interns, not senior security engineers.”
They produce helpful code quickly, but they cannot reliably guarantee secure architecture, dependency integrity, or safe operational practices. This becomes especially important when developers copy and paste snippets directly from web based LLMs into production projects.
According to the OWASP Top 10 for LLM Applications, prompt injection, insecure output handling, and supply chain weaknesses are among the top concerns tied to AI assisted development.
Three Layers of Protection
A secure vibe coding workflow combines three layers of protection:
Secret protection
Supply chain validation
AI-focused vulnerability scanning
Each layer catches a different class of mistakes.
Layer 1: Protecting Secrets with .gitignore and Gitleaks
Your first line of defense is the .gitignore file. A properly configured .gitignore prevents sensitive local files from accidentally entering Git history and eventually being pushed to platforms like GitHub.
A secure baseline should include:
# Sensitive local environment configurations
.env
.env.local
.env.*.local
# Cryptographic keys and certificates
*.pem
*.key
*.pub
A note on broad ignore rules: You may see recommendations to add *.local as a catch-all. Be careful with this. That pattern can unintentionally ignore local documentation, config examples, or frontend localization files. Stick to explicit entries like .env.local and .env.*.local, and review any broad wildcard rules before committing them.
Environment files commonly contain API keys, database credentials, authentication tokens, and cloud access secrets. One overlooked .env file can expose an entire infrastructure stack.
The tracking problem most developers miss
If a file was already committed before being added to .gitignore, Git continues tracking it. To check whether Git is still tracking a secrets file, run this command:
macOS/Linux:
git ls-files | grep .env
Windows (PowerShell):
git ls-files | findstr .env
If results appear, remove the file from tracking without deleting it locally:
git rm --cached .env
This single check prevents a large number of accidental credential leaks.
For an additional layer, Gitleaks scans commits for exposed secrets before code is pushed. Even if you accidentally paste an API key into a tracked source file, Gitleaks can stop the commit before it reaches a remote repository.
Layer 2: Supply Chain Security for AI-Generated Dependencies
One of the most underestimated risks in AI assisted coding is dependency hallucination. AI tools sometimes recommend software packages that do not exist, use typosquatted names, contain malicious code, or closely mimic legitimate libraries. Attackers know developers trust AI suggestions, which makes fake packages an increasingly attractive target.
Note on smaller tools: The security tooling space moves fast. Smaller open source projects may become unmaintained, change ownership, or disappear. Always validate any security tool before integrating it into your workflow, especially tools with small communities and no official releases.
slopcheck
slopcheck is a Rust CLI tool that checks a project and its dependencies for indicators of AI generated code. It looks for commits attributed to a known LLM (Claude, Copilot, etc.), the presence of files like CLAUDE.md or AGENTS.md, and similar signals across your dependency tree. It currently supports Rust (via cargo metadata) and JavaScript (via package.json).
cargo install --git https://github.com/mat-1/slopcheck
slopcheck .
This is a small, independent project with 56 GitHub stars and no official releases published. Check the commit history and verify recent activity before running it in a sensitive environment. The tool itself warns against running it on untrusted projects, as it may fetch arbitrary sources.
Dependency auditing: cargo-audit and cargo-supply-chain
For Rust projects, two well maintained tools from the Rust Secure Code working group are the more reliable foundation:
cargo-audit scans your Cargo.lock against the RustSec advisory database:
cargo install cargo-audit
cargo audit
cargo-supply-chain maps author, contributor, and publisher data across your entire dependency graph, giving you visibility into who actually maintains what you are running:
cargo install cargo-supply-chain
cargo supply-chain crates
Both tools are actively maintained, widely used, and backed by the Rust security community.
Not using Rust? Equivalent tools exist for other ecosystems. For JavaScript, run npm audit. For Python, pip-audit and Safety both check installed packages against known vulnerability databases. osv-scanner from Google works across multiple languages and is worth adding regardless of your stack.
Before installing any package
Regardless of what your AI assistant recommends, verify the following before adding a dependency:
Maintainer reputation and identity
Download count and community adoption
Repository activity (last commit, open issues)
Known security advisories
Fewer dependencies means a smaller attack surface, easier patch management, and less supply chain exposure overall.
Layer 3: AI Vulnerability Scanning with Truscan
Traditional static analysis tools often miss vulnerabilities specific to AI assisted applications. That is where Truscan (trusys-llm-scan) fills a gap.
Truscan is an open source tool maintained by Spydra Tech. It uses Semgrep style pattern matching and heuristics to help identify patterns commonly associated with insecure AI assisted applications, including:
Prompt injection weaknesses
Unsafe SQL query patterns
Insecure LLM integrations
Weak input validation logic
Excessively permissive API handling
Install and run it with:
pip install trusys-llm-scan
trusys-llm-scan . --format console
As of this writing it is at version 1.0.7. It is newer and has a smaller community than established SAST tools, but it targets a specific gap that broader tools miss. Run it as an additional layer, not a replacement for broader static analysis.
What Truscan does not do: It does not deeply understand your AI architecture or guarantee secure design. It finds patterns, not logic flaws, business rule violations, or poorly designed authentication flows. Treat it as one signal among several, not a final verdict.
Semgrep: Why It Belongs in Your Pipeline
Semgrep appears in several steps of this workflow, so it is worth explaining what it actually does. Semgrep performs static analysis by scanning code for insecure patterns, risky functions, and known vulnerability behaviors - without running the code itself. It works across multiple languages and integrates cleanly into CI/CD pipelines. Think of it as a rule-based code reviewer that runs automatically on every push.
Practical Habits That Make a Real Difference
Treat AI Output as Untrusted Input
Never assume generated code is production-ready. Review:
Authentication flows
SQL queries
File handling logic
Dependency imports
Access control checks
If you would review a junior developer’s pull request line by line, review AI generated code the same way.
Keep Secrets Local
Never paste production credentials into prompts. Use placeholder values instead:
API_KEY=YOUR_API_KEY_HERE
Even trusted AI services should not become storage locations for sensitive infrastructure data.
Automate Security Checks Early
Manual security reviews do not scale. A layered GitHub Actions pipeline enforces consistency every time code is pushed:
Gitleaks for secrets scanning
Semgrep for static analysis
cargo-audit for Rust dependency verification (Rust projects only)
Truscan for AI-focused vulnerability scanning
Setting Up a Security Pipeline
A lightweight GitHub Actions workflow can automate most of these protections. Here is a practical starting point:
name: Security CI Pipeline
on: [push, pull_request]
jobs:
security-scans:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Run Gitleaks
uses: gitleaks/gitleaks-action@v2
- name: Run Semgrep
uses: semgrep/semgrep-action@v1
# Check https://github.com/semgrep/semgrep-action for the latest recommended version before publishing
# Only include the steps below if your project uses Rust dependencies
- name: Set up Rust
uses: dtolnay/rust-toolchain@stable
- name: Run cargo-audit
run: |
cargo install cargo-audit --locked
cargo audit
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: ‘3.11’
- name: Run Truscan
run: |
pip install trusys-llm-scan
trusys-llm-scan . --format console
Important: Only include the Rust specific steps (cargo-audit) if your project actually uses Rust dependencies. Copying this pipeline into a JavaScript or Python project without adjusting it will cause the workflow to fail on the Rust steps.
Catch Mistakes Before They Reach GitHub
Pre-commit scanning is one of the most effective additions to any vibe coding setup. The pre-commit framework combined with Gitleaks hooks and local Semgrep scans lets you catch mistakes before code ever reaches GitHub.
To add Gitleaks as a pre-commit hook, add this to .pre-commit-config.yaml:
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.4
hooks:
- id: gitleaks
Then run pre-commit install once and it runs automatically on every commit.
What These Tools Will Not Protect You From
This is the part most security articles skip. Automated scanning helps reduce mistakes, but it does not replace secure design or proper testing.
These tools will not:
Guarantee safe authentication logic. A scanner can flag an insecure pattern, but it cannot verify that your entire auth flow is correctly designed.
Prevent business logic flaws. If your discount code system lets users apply the same code 100 times, no scanner catches that.
Secure poorly designed APIs. Overly permissive endpoints, missing rate limits, and broken object-level authorization require design review, not just code scanning.
Replace penetration testing. Automated tools find known patterns. Skilled testers find things no rule set anticipated.
Stop developers from overriding warnings. If your team ignores scan results, the pipeline is theater.
Treat automated scans as guardrails, not guarantees.
Closing Thoughts
AI assisted development is not slowing down. Vibe coding can be productive, creative, and secure at the same time. The difference comes down to process.
The strongest developers are not the ones who avoid AI tools entirely. They are the ones who build safe habits around them.
Small improvements, securing .gitignore, auditing dependencies, validating generated logic, and automating checks, add up to a meaningful security advantage over time. Security works best when it becomes part of the workflow instead of something you bolt on before shipping.
the 'fast interns, not senior security engineers' framing nails it: the real risk was never the hallucinated function, it is the trusted workflow around it, and intern-level output has never needed senior-level habits more.