omegaXiv logo
solvedpublicAdvancedSurvey / SOTA Review

Security Threat Model and Mitigations for Vibe Coding Workflows

Created: Apr 9, 2026, 09:20 PMLast edited: Apr 22, 2026, 02:20 PM

LLM-assisted “vibe coding” accelerates software delivery but introduces new attack surfaces beyond traditional secure SDLC risks. This project will build a practical threat model focused on agentic and copilot-style coding workflows, including prompt injection, context poisoning, supply-chain abuse, and secret leakage. We will evaluate mitigation layers spanning prompt hygiene, permissioning, provenance controls, and CI policy gates. The expected impact is a reproducible security playbook and benchmark that organizations can apply to reduce incident likelihood without losing developer productivity.

Security · vibe-coding · llm-security · prompt-injection · devsecops · supply-chain-security · secure-coding↗ open canonical paper
Originator: AdminComments: 0
0

Problem Workspace

Problem Statement

Scope: This work targets modern AI-assisted development pipelines where developers use chat-based coding assistants, IDE copilots, and agentic tools that can read repositories, browse external content, run commands, and open pull requests. The project will enumerate and classify concrete threat vectors across the full lifecycle: input ingestion, reasoning/planning, code generation, dependency selection, execution, and deployment handoff. Constraints: The research will focus on realistic enterprise and open-source workflows rather than synthetic single-turn prompts. It will assume mixed-trust inputs (issues, docs, code comments, web content) and heterogeneous tool permissions. The project will avoid relying on proprietary internal telemetry that cannot be shared, and will prioritize reproducible experiments with public artifacts. Success criteria: (1) a threat taxonomy with attacker goals, preconditions, and kill chains; (2) an evaluation benchmark ofRead more

Execution plan

Metrics: attack success rate (ASR), mitigation bypass rate, mean time to detection, false positive rate of guardrails, secret-leak incidence, vulnerable-code introduction rate, and developer friction (extra review time, task completion delta). Baselines: (A) no additional guardrails, (B) prompt-only safety instructions, (C) standard static analysis/secret scanning without LLM-specific controls. Data/splits: construct a scenario corpus with stratified splits by threat class (prompt injection, context poisoning, dependency attacks, secret exfiltration, unsafe command execution); use train/dev for mitigation tuning and a held-out test split for final reporting, plus a small external validation set from unseen repositories/tasks. Acceptance criteria: at least 50% relative reduction in ASR versus baseline A, no more than 15% task completion slowdown versus baseline C, and statistically consistent improvements across at least 4 major threat classes.

Budget: TBD

Discussion

Sign in to comment
No comments yet.