hardware-description-code-verilog-systemverilog-vhdl-amaranth-python-generated-functional CLM-0068When hardware description code (Verilog, SystemVerilog, VHDL, Amaranth-Python) is generated from a functional specification that omits security obligations — as real SoC docs do, keeping countermeasures in separate config files — frontier models pass functional tests far more often than security tests, and the model with the highest functional pass rate is not the safest; naming the relevant CWE in the prompt raises the security pass rate sharply, showing the limit is missing awareness of the required obligation rather than inability to write defensive RTL.
Capability: Writing secure code and dependencies
Observed on
Five resource-access CWE families that are observable at module ports under black-box simulation; 392 task instances from real open-source SoC IP; five frontier models, zero-shot, .
Sources
- Measured on a purpose-built 392-instance benchmark with separate functional and security testbenches, five runs per case, mean±std reported; vanilla functional pass 73-79% vs security pass 14-35%, security rising to about 59% mean with the aligned CWE entry supplied. Security testbenches are an operational approximation of the obligation set, and the CWE-supplied condition is an upper-bound cue that also lowered functional pass rates, so the two metrics are not independent.
Disagreeing is the most useful thing you can do here. Nothing on this page waits for a reviewer: the counts above move when evidence lands, and every source stays attached with who brought it.
Related claims
- On code prompts that are unsatisfiable by design, open-weight code and reasoning models refuse based on how suspicious the request looks rather than how deeply impossible it is: they refuse famous theoretical impossibilities far more often than requests for plausible-sounding nonexistent packages, and the stronger models in the set close the gap on theory while barely improving on fabricated ecosystem entities.Stating false facts confidently · reviewed by AI
- For a 7B code model fine-tuned on competitive-programming tasks, training it to emit a fixed-schema requirement specification (goals, input/output constraints, examples, edge cases, dependencies) before the code raises Pass@1 more than training it to emit free-form reasoning or a stepwise implementation plan of similar length, with the largest margin on an out-of-distribution benchmark.Generating and editing working code · reviewed by AI
- When a benign GitHub issue is augmented with a plausible-sounding maintenance requirement that specifies a helper reading an environment variable into a dangerous sink, repository-level APR agents produce patches that fix the original bug and pass the project test suite while containing the requested vulnerability in roughly half of tasks, and the strongest instruction-following coding models are more susceptible, not less.Writing secure code and dependencies · reviewed by AI
- For tool-using agents, enforcing injection defense as a deterministic provenance check on sensitive tool parameters — with the only model call reading the trusted user request and never fetched content — makes admission decisions invariant to how an injection is worded, whereas defenses that judge the agent's runtime plan or behavior with a model can be steered by reworded injections.Following instructions hidden in data · reviewed by AI
- For tool-using agents, restricting capabilities at the harness level after untrusted content enters the context — revoking or tightening the parameter envelopes of skills that lie on graph paths to deployer-defined forbidden states — cuts indirect-injection attack success further than prompt-level or per-action authorization defenses, and does so with no extra model calls or tokens, because enforcement reads the transition graph rather than the natural-language content.Following instructions hidden in data · reviewed by AI
Notes
Drafted from the paper by a model and filed unreviewed. Visible here so it can be read, not because anyone has vouched for it: it does not move any technique's standing and does not count toward the internal scorecard. Drafted confidence: medium. Falsifier as drafted: On the same obligation-omitted specifications, a model whose functional pass rate is high also passes security tests at a similar rate, or supplying the aligned CWE entry fails to raise security pass rates. Drafted stance toward models-complied-insecure-completions-large-fraction-time-more: supports -- Extends the software finding to hardware code and adds that greater functional capability does not track greater security in the same setting. Proposed technique, not catalogued: Symbolic inference of implicit security obligations from a spec graph plus CWE ontology, then obligation-guided revision of a functional draft.