Topic starter
19/08/2026 3:28 pm
TL;DR: A 22B on-premise code model fine-tuned on 4,811 validated security triples reached 98.0% safe rate on C/C++ remediation and 85.1% on Python generation, statistically tying Claude Opus 4.8 on the remediation benchmark while showing the biggest gains came from dataset breadth, according to Symbiotic Security. The result shifts the conversation from model size to governance of training data, evaluation limits, and where secure code generation can run without exposing sensitive source.
Editorial analysis by NHI Mgmt Group, based on content published by Symbiotic Security: “Reaching Frontier Parity in Security Code Remediation with an On-Premise 22B Model”.
By the numbers:
- The model reaches a 98.0% safe rate on CyberSecEval for C/C++ remediation, measured by static analysis.
- The model reaches an 85.1% safe rate on SecurityEval for Python generation, measured by static analysis.
Key questions
Q: How should teams govern on-premise code models that remediate vulnerabilities?
A: Govern them as part of the software delivery control stack, not as a standalone AI tool.
Q: Why can a security code model look strong while still being risky?
A: Because static-analysis pass rates only confirm that a known rule did not fire, not that the patch is functionally correct or that every weakness class is covered.
Q: What breaks when remediation training data is too narrow?
A: The model overfits the patterns it has seen and fails when the target language or weakness class changes.
Practitioner guidance
- Validate remediation datasets before fine-tuning Require every training example to contain a vulnerable snippet, a correct patch, and a plausible rejected patch, then remove near-duplicates and cross-source overlap before training.
- Run secure code models inside the regulated boundary Keep inference and data preparation on systems that do not send source code to external APIs, especially where proprietary code or regulated workloads are involved.
- Separate static-analysis scores from security assurance Treat scan pass rates as an upper bound, then add functional testing and targeted review for weakness classes the analyzer does not cover well.
Bottom line: On-premise remediation models can approach frontier performance, but the result depends on validated data, not just larger weights or better tuning.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:11 pm
Secure remediation is now a governance problem, not just a model benchmark. Once code generation is used to fix vulnerabilities, the control question shifts to who can train on sensitive source, where the model runs, and how safety claims are validated. That is directly relevant to security teams running software delivery, because the same workflow can reduce risk or spread it depending on the quality of data governance. Practitioners should treat remediation models as part of the secure development control plane.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
A question worth separating out:
Q: Should organisations choose self-hosted code remediation over hosted APIs?
A: They should choose based on data sensitivity, regulatory constraints, and review maturity. Self-hosted deployment is attractive when source code cannot leave the perimeter, but it only works if the organisation can support high-quality training data, secure inference infrastructure, and independent validation of output quality. Otherwise, hosted and self-hosted both remain assurance problems, just in different places.
👉 Read our full editorial: On-premise code models can reach frontier parity in remediation