GPT-5.6 Sol Shows Why a Better Model Isn’t a Uniformly Safer Model
Veracode Research’s latest secure-coding test finds GPT-5.6 Sol with a 15-point Python gain beneath modest aggregate movement, evidence that cyber capability and secure-code generation do not move in lockstep.
OpenAI calls GPT-5.6 Sol its “strongest cybersecurity model yet.” Veracode’s extension test finds it scoring only two percentage points higher overall on secure-code generation than GPT-5.5, but it scores 15 points higher in Python. That is exactly why a better model should not be assumed to be a uniformly safer code generator.
This expands on Veracode’s 2026 GenAI Code Security research, which found that secure-code performance remained stubbornly flat despite models becoming extraordinarily good at producing code that’s almost syntactically perfect. Across four testing snapshots and more than 100 models, the average security pass rate was 56%; GPT-5.5 led the Summer 2026 leaderboard at 68%. The Sol results sharpen rather than reverse that finding: security is starting to move, but unevenly.
What changed from GPT-5.5 to GPT-5.6?
On Veracode’s extension test, GPT-5.6 Sol reached 70% secure overall, compared with 68% for GPT-5.5. Underneath that modest aggregate gain, Python moved from 70% to 85% secure and cross-site scripting (CWE-80) improved from 50% to 60%. C# and Java did not share the gain, JavaScript was unchanged, and log injection (CWE-117) remained a pronounced weakness.
The 15-point Python gain must be read narrowly: in this controlled secure-coding test, Sol selected secure Python implementations materially more often. It does not mean real-world Python applications suddenly became 15% safer, nor does it establish a universal improvement across software development. It tells us where this model’s secure-coding behavior changed and where it did not.
OpenAI reports much larger gains in other dimensions. SEC-Bench Pro rises from 45.8% to 71.2%, ExploitBench from 47.9% to 73.5%, and Capture-the-Flag challenges from 88.1% to 96.7% from GPT-5.5 to Sol. Those are substantial gains in cyber capability: proof-of-concept generation, exploitation, and cybersecurity problem solving. They are important, but they are not the same measurement as secure code generation.
OpenAI also reports BenchCAD using a Python tool rising from 55.8% to 83.4%. BenchCAD is a computer-use evaluation, not a security benchmark, so it cannot explain Veracode’s Python result. It is nevertheless a useful independent signal that Sol’s Python-mediated problem solving changed sharply in the same model generation.
That uneven movement across languages may be the most important result in the test. GPT-5.6 Sol did not become uniformly safer; its secure-coding behavior changed shape. Python improved sharply. XSS improved. Other languages did not improve with them. The aggregate 70% score compresses those differences into one number, but for security teams the differences are the point. A Python team, a Java team, and a team repeatedly fighting injection or logging flaws may experience the same model release very differently.
A model has a security profile, not a security score.
Why does it matter?
The numbers answer different questions. Cyber capability asks what a model can do. Secure-coding testing asks which implementation choices it makes during ordinary code generation. Trust asks whether we have enough evidence to rely on those behaviors for a particular purpose.
The 2026 GenAI Code Security report established that better coding did not automatically mean safer coding. Sol now shows that even when security improves, it may improve locally rather than uniformly. Capability can rise globally while security moves across languages, vulnerability classes, and implementation boundaries.
One plausible explanation is relatively simple: Sol may be choosing safer implementations more often without having become uniformly better at security reasoning. There is a meaningful difference between a model knowing that a pattern is insecure and choosing the secure alternative when nobody explicitly asks about security. A model can explain output encoding, parameterized SQL, or safe deserialization and still fail to choose those patterns by default. What matters is whether those safer choices now win more often when the model is simply asked to write code.
Python may expose that shift relatively clearly. Many risky Python choices are compact and explicit: unsafe deserialization with pickle, eval or exec, shell=True, string-built SQL, unsafe YAML loading, or bypassing framework-native escaping. These are the kinds of behaviors that can be expressed as precise secure-development guidance, so a relatively small set of stronger defaults could move Python behavior noticeably without implying a universal breakthrough in security reasoning.
Security-specific behavior is already being engineered directly into AI coding systems. Anthropic says Claude Code’s /security-review uses a “specialized security-focused prompt” covering issues including SQL injection and XSS. OpenAI has similarly made security an explicit engineering focus through Aardvark and Codex Security. That does not tell us why Sol improved so sharply in Python. But it does show that secure behavior is increasingly something providers can shape deliberately and not merely something we wait to emerge as models become smarter.
What is the impact?
The immediate enterprise implication is that “we use the best model” is not a security strategy. A model can deserve more confidence for one task without earning more trust everywhere. A Python-heavy engineering organization and a Java platform team may see materially different security outcomes from the same model release. So may teams whose recurring risks cluster around output encoding, logging, cryptography, authentication, or other boundaries.
A model upgrade is a security-relevant change event. If the model changes, the distribution of secure and insecure implementation choices can change even when the developer, repository, and functional requirement do not.
Before making a major model or agent upgrade the new default, regression-test it against the languages, frameworks, and vulnerability classes that matter to your environment. Use the stronger model, but verify how its security behavior changed.
Trust should be equally specific. A useful claim is not simply “we trust GPT-5.6 Sol.” It is closer to: we have evidence that this model version, operating under these controls, behaves acceptably for these tasks, and we independently verify the software before release. A benchmark can inform trust. It cannot authorize a release.
This is where independent verification still matters. Provider-side secure defaults should reduce insecure code upstream. Static analysis, software composition analysis, dynamic testing, and application risk management then provide evidence about the software that actually exists and the risk an organization is preparing to accept.
GPT-5.6 Sol is demonstrably stronger on OpenAI’s cyber evaluations. Veracode’s extension results suggest that some secure-coding behavior improved sharply in Python, while other weaknesses did not improve with it.
The next question for AI code security is not simply, “How well did the model score?” It is, “Where did its security behavior change, what evidence supports that conclusion, and what still requires independent verification?”
Organizations need a reliable security backstop: independent evidence that shows what changed, what risk remains, and where they need to act.
Explore the full findings in the Veracode 2026 GenAI Code Security Report.
Research Note
The GPT-5.6 Sol results reported in this article are from Veracode follow-up testing conducted in August 2026 using the methodology established for the 2026 GenAI Code Security Report. These results post-date the published report.