It Runs, but Is It Safe? Four Security Questions to Ask Before Commissioning Custom Software

Almost every development team now writes code with AI. Quotes arrive faster and so does delivery. One thing has not improved alongside them: AI-generated code security. Testing published this summer shows that AI-written code almost always runs, yet close to half of it carries a known security vulnerability, and that share has barely moved in a year. For a business owner commissioning software, this is not a technical detail for engineers. It is something to settle before signing, because when a system fails, it is your brand that faces the customer.
Running is not the same as safe: two reports, one conclusion

Security firm Veracode published its annual GenAI Code Security Report in late July 2026. The result is blunt. Models now produce syntactically correct code nearly 100% of the time, but the average share that passes security testing is 56%, against 55% a year earlier. Roughly 44% of code generation tasks introduce a known vulnerability. The best model reaches only 68%, and more than half of the models tested sit between 50% and 53%. Large models average 53% and medium and small models 51%, a negligible gap. The report's conclusion: syntax is effectively solved, but secure coding is not following the same curve.
IOActive ran a larger test in spring 2026: 27 models and AI coding tools, 730 real-world programming prompts, 27 programming languages. Average security performance was 59%, 31.6% of code samples were fully exploitable, and no model produced fully secure output.
Two teams, two methods, and the numbers land in the same range: about four in every ten pieces of AI-written code need someone to check them.
AI fails most where it hurts most

Not every vulnerability is equally serious. Veracode's data shows AI does well at preventing SQL injection and choosing cryptographic algorithms, with pass rates of 83% and 87%. Against cross-site scripting (XSS) the pass rate is 15%, and against log injection only 12%.
IOActive points to areas where nearly every model fails:
- Authentication and permissions: who can see which data and who can change which settings.
- Rate limiting: whether brute-force password attempts and request floods are blocked.
- Deployment and infrastructure configuration: vulnerability rates here run from 70% to 97%.
These are the core of a membership system, an order back office or a payment integration. One unfiltered form field or one admin screen without an identity check is enough to leak customer data.
"Write secure code" does not work. Process does.

Many people assume that adding "please write secure code" to the prompt is enough. IOActive found that simple reminders like this were often ineffective and sometimes counterproductive. What worked was building security rules into system-level configuration and tooling, which improved security performance by up to 25 percentage points.
Veracode's recommendations also focus on process, not on waiting for smarter models: include security in model selection, verify code as it is written instead of scanning just before launch, fix the most exploitable high-risk flaws first, and govern AI coding as a real software input, with a policy on which models are used, where, how output is checked and who is accountable.
In other words, the security of AI-written code depends on the discipline of the development team, not on which new model they use.
Four AI-generated code security questions to ask before commissioning custom software

You do not need to read code. You need to ask the right questions and write the answers into the contract or the acceptance criteria.
1. Which AI tools do you write code with, and how are the security rules configured?
A good answer mentions a fixed list of tools, security rules written into tool configuration, and the cases where AI is not used. "We use the latest model" is not an answer.
2. What security checks does code pass before launch?
At minimum, automated vulnerability scanning and human code review. Ask for a summary of scan results in the acceptance documents, not just the word "tested".
3. Who writes and who reviews login, permissions, payments and deployment settings?
These high-risk areas should be reviewed line by line and signed off by a senior engineer. AI can draft them, but a named person must be responsible.
4. If a vulnerability is found after launch, who fixes it, how fast and at what cost?
Vulnerabilities do not always surface at acceptance. Security patches during the warranty period, notification deadlines and later maintenance fees should all be agreed before signing.
If staff inside your company have already built small tools with AI, the same questions apply. See our earlier piece, Built It With AI? When Vibe-Coded Tools Should Move to Professional Development.
Closing: AI writes fast, people hold the line

AI makes custom development faster and more affordable, and that is good news. But part of the time saved has to be spent on checking. Whether a system deserves trust depends less on how fast it was built than on whether someone can explain where each line of defence sits when something goes wrong.
When TitApeX takes on a custom system, security checks and accountability are written into the process and the delivery documents. If you are evaluating a development project, take a look at our services or talk to us.

Comments