Vibe Coding and Security: How ARES Closes the Gaps AI Opens
45% of AI-generated code has vulnerabilities. Structured governance changes that statistic.
In 2025, Veracode published a study that shook the industry: approximately 45% of code generated by AI models contains serious security vulnerabilities. Not minor bugs — exploitable vulnerabilities. SQLi, XSS, weak authentication, hardcoded secrets in client code. Vibe coding, without governance, is a silent factory of attack surface.
The problem is not that AI is malicious. It is that it generates code that works on the happy path — and nobody asked it to think about the adversarial path.
The most common risk vectors
- SQL injection and XSS from missing input validation — AI generates the happy flow, not the adversarial flow
- Hardcoded secrets and credentials — API keys, tokens, passwords in code that goes to repositories
- Client-side only authentication — easily bypassed from any HTTP client
- Slopsquatting — installation of packages with AI-invented names that can be captured by attackers
- Dependencies with known vulnerabilities — AI suggests libraries without verifying their current security status
- Sensitive data exposed in logs and API responses — information that shouldn't leave the server
How ARES acts as a security governance layer
ARES is not a security scanner — for that there are specialized tools like Snyk, Semgrep, or Dependabot that you should use in parallel. What ARES contributes is something different: governance of the change process that dramatically reduces the probability of vulnerabilities reaching production.
- Evidence-based risk scoring before integrating — not intuition or 'the code looks clean'
- Detection of architectural risks in the context of the complete system, not just the generated fragment
- Mandatory test plan before integrating — including adversarial cases, not just the happy path
- Traceable record of every change — enables post-facto audits and detection of accumulated insecure patterns
- Structured emergency brake — the process forces pause and evaluation before executing impulsive patches
What ARES doesn't replace
Being honest about limitations is part of credibility. ARES is not a direct solution against slopsquatting — for that you need strict lockfiles, SBOMs, and manual review of dependency manifests. It doesn't replace mandatory SAST/DAST or automated secret scanning. What it does is create the governance environment in which those tools make sense and are used consistently.
| Risk vector | ARES coverage | Complementary tool |
|---|---|---|
| SQLi / XSS / weak auth | High — systemic prevention | SAST (Semgrep, SonarQube) |
| Hardcoded secrets | Medium — review process | Secret scanning (GitGuardian) |
| Slopsquatting | Medium-low — integration context | Socket.dev, Dependabot |
| Architectural drift | Very high — main focus | — |
| Overconfidence in code | High — evidence scoring | Selective code review |
The combination of ARES + specialized security tools creates a security posture that neither can achieve alone. ARES provides process governance; the tools provide automated technical detection.
Interested in the solution?
More perspectives