Vibe Code Security: Penetration Testing, CI/CD and What to Check Before Launch

Your vibe-coded application is working. People can log in. The dashboard loads. Forms submit. APIs connect. The demo went well.

Now someone wants to put it live.

This is the point where testing whether the software works needs to become testing whether it is safe to operate. They are not the same thing.

A lot of AI-assisted development happens at incredible speed. Features that once took days can appear in minutes. The downside is that architecture, security controls, testing and deployment processes can easily fall behind the feature list.

Before a vibe-coded project starts handling real users, passwords, payments, customer records or commercially sensitive information, there are a few things worth checking properly.

Why AI Development Needs Security Testing 

There is nothing uniquely insecure about using AI to help write software. The issue is trust.

AI coding tools are designed to help produce working code quickly. They do not automatically know your organisation’s threat model, data requirements, compliance obligations, permission structure or operational risks unless those things have been properly designed into the project.

Current industry testing also shows that functional accuracy should not be confused with secure implementation. Code can be syntactically valid and work as expected while still containing security weaknesses.

That does not mean every second AI-built application is waiting to be hacked. It does mean “the AI said it was secure” is not a security testing methodology.

Start by understanding the attack surface

Before testing individual vulnerabilities, you need to understand what is actually exposed. What can an unauthenticated visitor access? What changes after someone logs in? Which APIs are publicly reachable? Where are files uploaded? Which systems receive user input? What external services are connected? Where is sensitive information stored? Which areas are available to administrators?

Mapping application entry points is an important early part of security testing because you cannot test an attack surface properly if you do not know what it contains.

For projects that have grown organically through prompts, this mapping stage can be particularly revealing. Features get added. Old endpoints remain. Temporary admin tools survive. Test routes are forgotten. Debugging functions stay enabled.

Before looking for clever vulnerabilities, first work out what is actually there.

Vibe code penetration testing

Penetration testing takes security testing beyond reading the code. The goal is to actively test the application and see whether weaknesses can actually be exploited.

That can include authentication, session handling, user permissions, APIs, file uploads, input handling, business logic, configuration, infrastructure and other exposed areas.

For example, an application may correctly hide another customer’s invoice in the interface. A penetration test asks a different question: can I access that invoice directly anyway?

A password reset screen may appear completely normal. The test asks whether its reset tokens expire properly, whether accounts can be enumerated or whether the workflow can be manipulated.

This distinction is important because security issues are often created by interactions between components rather than one obviously terrible line of code.

Web application security testing should actively evaluate security controls for weaknesses, technical flaws and vulnerabilities, rather than simply checking that functionality behaves normally.

Automated security scanning helps, but it is not the whole job

Security tooling should be part of the workflow. Static Application Security Testing, commonly called SAST, examines source code for potentially insecure patterns. Software Composition Analysis checks third-party libraries and dependencies for known vulnerabilities. Secret scanning looks for accidentally committed API keys, credentials and tokens. Dynamic Application Security Testing, or DAST, tests the running application from the outside.

Each catches different things. The mistake is thinking that passing one scanner means the application has been “security tested”.

Automated testing is excellent at finding certain known patterns. Human testing is still important for context, unusual workflows and business logic.

A scanner might confirm that the checkout endpoint does not contain an obvious injection vulnerability. It may not realise that changing quantity=1 to quantity=-10 gives the user a credit.

Software is creative. People trying to break it can be too.

Authentication is only half the job

A common vibe coding milestone is getting authentication working. Users can sign up. Users can log in. Great.

Now check authorisation.

Authentication answers: Who are you? Authorisation answers: What are you allowed to do?

That second question is where serious problems can appear. Every sensitive API and server-side action should enforce permissions properly. The application should not depend on a button being hidden in the browser as its main security control.

Administrator functionality deserves extra attention because a compromised admin account can turn a relatively small weakness into a much larger problem. This is also where multifactor authentication, sensible session handling, strong password processes and least-privilege access become relevant.

Protect the keys to everything

A modern web application can contain a small collection of very powerful secrets: database credentials, cloud access keys, payment service tokens, email credentials, AI provider API keys, private API secrets and deployment credentials.

These should not be hard-coded into the application or casually stored inside a repository. Production credentials should also provide only the access they genuinely need.

The same least-privilege principle should apply to credentials used in automated workflows, including limiting the permissions available to deployment tokens.

If a secret has previously been committed to source control or shared somewhere inappropriate, simply deleting the visible value may not be enough. Rotating the credential is generally the safer approach.

CI/CD turns deployment into a process, not a ritual

Continuous Integration and Continuous Delivery sounds very enterprise until you have watched someone deploy an important application by dragging files onto a server. Then it starts sounding quite reasonable.

CI/CD creates a repeatable path between a developer changing the code and that change reaching production. When code is pushed, the pipeline can automatically run unit tests, build the application, check dependencies, perform security scans and prepare a deployment.

Production releases can then require appropriate approvals before going live. This improves consistency and creates something equally important: a record of what actually happened.

Who changed the code? Which version was tested? Did the tests pass? What was deployed? Can we roll it back?

That becomes increasingly important once several people or AI coding tools have touched the same project.

The deployment pipeline needs security too

Automation does not automatically mean safe automation. CI/CD systems often have access to production servers, cloud accounts, repositories and deployment credentials. That makes the pipeline itself a valuable target.

CI/CD infrastructure should be treated as security-critical, with appropriate access controls, secrets management, monitoring and hardening.

AI-generated changes to workflow files deserve particular scrutiny. Build files, deployment scripts, container configurations and CI/CD workflow files can execute automatically within trusted environments, so changes in these areas need proper review.

In plain English: do not casually approve an AI-generated deployment file because the YAML looked convincing.

Add some gates before production

Not every change needs a committee meeting. But production should not be a free-for-all either.

Depending on the application, sensible controls might include protected production branches, peer approval for important changes, automated test requirements, dependency scanning, secret scanning and a staging deployment before production. For higher-risk systems, security testing can become an explicit release requirement.

The exact setup should match the application. An internal lunch ordering tool and a platform storing financial information do not need identical controls.

The point is to deliberately decide what level of risk is acceptable rather than discovering it after launch.

Production configuration matters just as much as code

Perfect code can still run in a badly configured environment.

Before launch, production configuration should be reviewed separately from the application itself. Debugging should be disabled where appropriate. Development tools should not accidentally remain public. Databases and administrative interfaces should not be exposed unnecessarily. Transport encryption should be configured correctly. Storage permissions need reviewing.

Production environments should also be cleared of unnecessary default functionality, development artefacts and debugging components before deployment.

These issues are easy to overlook when a project has spent most of its life running on a developer’s laptop or inside a rapid prototyping platform.

Security does not finish on launch day

A launch security audit is useful. A launch security audit followed by three years of neglect is less useful.

Dependencies change. New vulnerabilities are discovered. Credentials leak. Infrastructure evolves. New developers join. Old developers leave. Features get added.

Software needs maintenance. Dependency monitoring, patching, logs, backups, uptime monitoring and security alerts should continue after deployment.

Security continues after deployment because new vulnerabilities can be discovered in dependencies, infrastructure and other components over time.

Security is not a certificate you earn once. It is part of running software.

You can still keep the speed advantage

None of this means businesses should stop vibe coding. Quite the opposite.

AI-assisted development is opening up software development to ideas that might never have justified a traditional development budget. Internal teams can test concepts. Founders can validate products. Businesses can automate annoying manual processes. Developers can move significantly faster.

The trick is knowing when the project has moved beyond experimentation.

Once real customers, sensitive information, money or important business processes are involved, that fast prototype needs another layer of engineering around it: code review, security testing, penetration testing where appropriate, proper deployment, CI/CD, monitoring and maintenance.

That is the difference between something that happens to work today and software you are comfortable relying on tomorrow.

If your team has already built the first version, our vibe coding team at Shtudio can review what is there, identify the gaps and help get it ready for production without automatically sending you back to square one.