Teaching an Old LLM Secure Coding: Localized Preference Optimization on Distilled Preferences

Mohammad Saqib Hasan; Niranjan Balasubramanian; Saikat Chakraborty; Santu Karmaker

REVIEW 4 major objections 5 minor 14 references

Teaching an Old LLM Secure Coding: Localized Preference Optimization on Distilled Preferences

T0 review · 4 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper shows that localizing preference optimization to tokens that differ between secure and insecure code cuts insecure LLM-generated files by 19 to 40 percent while improving code utility.

desk verdict Solid empirical recipe with a useful dataset, but the LPO loss as written is inconsistent with the prose and the difflib masks include non-security tokens, so the localization story needs work. read the letter →

arxiv 2506.00419 v2 pith:KJVKR5SP submitted 2025-05-31 cs.CR cs.SE

Mohammad Saqib Hasan , Saikat Chakraborty , Santu Karmaker , Niranjan Balasubramanian This is my paper

classification cs.CRcs.SE

keywords securecodegenerationlocalizedpreferenceoptimizationtoken-levelmaskingdistilleddatasetCWEcoveragesecurityreasoningDiSCoLPO

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Code produced by LLMs is frequently insecure, and standard alignment methods spread their loss across all tokens, so the small set of tokens that actually introduces a vulnerability gets a weak signal. This paper introduces two coupled pieces: DiSCo, a pipeline that distills 9,987 insecure/secure Python code pairs with security reasoning from frontier LLMs using CWE knowledge and static analyzer feedback; and LPO, a localized preference optimization that masks the preference loss to the security-relevant tokens and adds a supervised regularizer over the remaining tokens to protect code quality. The authors report that models trained on DiSCo and aligned with LPO reduce the percentage of insecure files by 19 to 40 percent across four secure coding benchmarks and improve pass@k by 3 to 10 percent on two coding benchmarks, outperforming SFT, DPO, SimPO, and SafeCoder on 15 of 16 model-benchmark combinations. If this is correct, secure code generation can be achieved at alignment time in a small model, without relying on a separate repair or refinement step.

What carries the argument

The load-bearing mechanism is the masked preference loss. With m+ and m− the binary security-token masks, the objective is $\mathcal{L}_{\mathrm{LPO}} = -\mathbb{E}_{(x,y^+,y^-,R)\sim D}[\log\sigma(\Delta - \gamma) + \alpha\, m^+ \odot \log \pi_\theta(y^+, R\mid x)]$, where $\Delta = \frac{\beta}{|y^+|} m^+ \odot \log \pi_\theta(y^+, R\mid x) - \frac{\beta}{|y^-|} m^- \odot \log \pi_\theta(y^-, R\mid x)$. The masks are computed once per pair by difflib's token-level delta between the insecure and secure code, under the assumption that the differing tokens are exactly the security-relevant ones. The preference term localizes the gradient to those tokens, while the regularizer supervises the non-masked tokens of the secure response so the model does not over-engineer code or otherwise sacrifice utility.

What would settle it

Construct a set of preference pairs whose secure and insecure versions are identical except for a pure non-security change such as renaming a local variable or reformatting, train LPO on those pairs, and measure whether the insecurity rate on Security Eval changes; if the model becomes more secure, the gain cannot be attributed to localizing on security tokens.

Watch

Extended reading notes

Core claim

The central claim is that the localized structure of secure-code preferences should drive the alignment objective. LPO computes binary masks m+ and m− over the winning and losing responses by taking the difflib token delta between the secure and insecure versions, then applies the SimPO-style preference loss only to those masked tokens while regularizing with an SFT loss on the complement of m+; the shared security reasoning trace R is masked out entirely. On the paper's evaluations this yields the best security-utility trade-off in 15 of 16 model-benchmark combinations, with StarCoder2's insecurity falling from 56.3 percent to 11.4 percent on Security Eval and from 65.8 percent to 12.6 percent on LLMSecEval, while HumanEvalX pass@1 rises from 33.2 to 38.9. The authors further claim that a billion-scale model tuned this way is markedly more secure than frontier models: GPT-4o, GPT-4o-mini, and Claude-3.5-Sonnet show 46.6 to 61.2 percent insecurity on Security Eval despite explicit security-aware prompting.

Load-bearing premise

The masks are built on the assumption that every token difflib marks as different between the insecure and secure code is security-relevant, so differences from formatting, renaming, or unrelated refactoring would send the loss to the wrong places.

Editorial extensions

If this is right

LPO-trained models beat the best baseline among SFT, DPO, SimPO, and SafeCoder in 15 of 16 model-benchmark security settings, with up to a 64 percent relative reduction in insecure generations for StarCoder2.
The security reasoning trace R is load-bearing: ablating it drops StarCoder2's HumanEvalX pass@1 from 38.9 to 18.8, showing that having the model articulate the vulnerability and fix before generating code preserves utility.
DiSCo alone, even with plain SFT, reduces insecure files by roughly 5 to 25 percent and issues per 100 generations by 20 to 300 on the four security benchmarks, making it a reusable data resource independent of LPO.
LPO's gains survive out-of-distribution: training on DiSCo with the evaluation CWEs removed still reduces StarCoder2's insecurity from 56.3 to 16.6 percent on Security Eval, indicating broad CWE coverage transfers.
Frontier models remain less secure than the tuned small model: GPT-4o, GPT-4o-mini, and Claude-3.5-Sonnet score 46.6 to 61.2 percent insecurity on Security Eval, versus 11.4 percent for the best LPO-tuned StarCoder2.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Inference: The same masked-preference mechanism should transfer to other coding preferences with long shared contexts, such as bug-fix pairs or style-consistency edits, where a global loss would dilute the sparse signal.
Inference: Because the mask relies on string diffs, pairing LPO with a data-flow-aware diff (for example, using analyzer taint paths to identify vulnerable spans) could make localization robust to refactoring and formatting changes that currently misdirect the loss.
Inference: The paper's own limitation note implies that repository-level, long-context coding tasks are the natural next test; the reported 19 to 40 percent reductions may look different once code is embedded in larger files with dependencies.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The paper gives you two things: a dataset (DiSCo) that is genuinely useful, and an alignment recipe (SFT with security reasoning + LPO) that consistently beats SFT, DPO, SimPO, and SafeCoder on four security benchmarks. The gains are large—19–40% relative reduction in insecure files—and they hold across four base models. That is a real result, and the release of code and data makes it easy to build on.

What is new is the distillation pipeline: you sample CWE/issue/package tuples from security knowledge bases, prompt a frontier LLM for insecure/secure pairs with reasoning, then refine with CodeQL/Bandit feedback. That produces 10k instances covering 431 CWE categories. The LPO loss is a variant of SimPO with token masks and an SFT regularizer—modest algorithmic delta, but applied to a problem where it helps.

Now the soft spots. The formal LPO equation in Section 5.2 is wrong as written: the regularizer is written as +α m+ ⊙ logπ, but the prose says it should be over the complement of m+ (and the sign should be a negative NLL). A reader cannot reproduce the loss from the paper. That's a significant technical error, not a typo, because the term as written would push probability down on the masked tokens.

The bigger conceptual worry is the mask computation. The masks are just difflib token differences between y+ and y−. Your own example in Figure 3 shows the secure version adding try/except, timeout, raise_for_status, return None, and a print wrapper—none of these are about the TLS/SSL issue. difflib will mark all of them as security-relevant, so LPO is not actually localizing to security tokens; it is shaping the whole edit block. The gains may still be real, but the paper's interpretation—that LPO succeeds because it propagates loss to security-relevant tokens—is not supported by the mask construction. You'd need a mask-quality check or an alternative like token-level attribution.

The ablation table also changes β and γ when removing the regularizer, so the regularizer's contribution is confounded with hyperparameters. And there are no error bars anywhere, though the consistency across models compensates somewhat.

None of this kills the paper. The dataset alone justifies a citation. The empirical result looks robust. But it needs a careful revision: fix the loss, show that masks actually align with security edits, and clean up the ablation. I'd send it to review.

Referee Report

4 major / 5 minor

Summary. The paper introduces DiSCo, a pipeline for distilling 10k Python (insecure, secure) code pairs from GPT-4o using CWE/security-analyzer knowledge and a refinement loop, together with LPO, a preference optimization loss that masks token-level differences between secure and insecure responses and adds an SFT regularizer. The authors evaluate on four base models across four security benchmarks and two code utility benchmarks, reporting large reductions in insecure generations and modest utility gains, and compare against SafeCoder, DPO, SimPO, and frontier LLMs. The main claims are that DiSCo plus LPO reduces insecure files by about 19-40% on external security benchmarks while improving code quality by 3-10% on coding benchmarks, and that LPO outperforms the other alignment methods in 15 of 16 model-benchmark combinations.

Significance. If the claims are supported, the paper makes a practical contribution: a released synthetic preference dataset with broad CWE coverage, a reproducible training recipe, and a novel loss designed for localized security edits. The evaluation is broad (four base models, four security benchmarks, two utility benchmarks, ablations, out-of-distribution test), and the data/code release lowers the barrier for follow-up work. The central conceptual novelty, however, depends on the validity of the token masks used to localize the preference signal; the current manuscript provides only indirect evidence for that validity. The dataset itself and the empirical recipe may still be useful even if the localization mechanism is imperfect, but the scientific claim as stated needs additional support.

major comments (4)

[Section 5.2, LPO loss equation] The displayed LPO loss writes the regularizer as α m+ ⊙ log πθ(y+,R|x) and labels it 'SFT objective', while the prose immediately before it states that the regularizer is L_SFT over the rest of the y+ tokens, computed via the complement of the mask m+. The equation as printed applies the SFT term to exactly the same security-relevant tokens that receive the preference signal, not to their complement. This is not a purely cosmetic typo: Table 3 shows that removing the regularizer changes InSec from 11.4 to 8.0 and pass@1 from 38.9 to 27.4, so the regularizer is doing load-bearing work, and its correct mathematical form must be unambiguous. Please correct the displayed equation (e.g., use (1−m+)⊙log πθ) or, if the implementation actually uses m+, explain why the regularizer is on the masked tokens and revisit the 'w/o regularization' ablation accordingly.
[Section 5.2, Appendix C, Figure 3, Table 6] The masks m+ and m− are computed by difflib on tokenized y+ and y− under the assumption that tokens unique to y+ are exactly the security-improving tokens and tokens unique to y− are exactly the insecurity-causing tokens. The paper's own data weaken this assumption. Figure 3's secure version adds try/except, timeout, raise_for_status, return None, and a print/if wrapper around the call, none of which are needed for the TLS/SSL fix, and refactors the request call; Table 6 reports an average character diff of 152 and that secure code is on average 2.6 lines longer. difflib will therefore mark as security-relevant a substantial number of tokens that are formatting, refactoring, or defensive-programming changes. The paper has not demonstrated that LPO's gains come from security-localized optimization rather than from a generic diff-masked preference loss plus length renormalization. Please add a mask-quality analysis: for example, compute precision/recall of difflib masks on a random sample against human or LLM annotations of security-relevant edits, or compare LPO against a variant whose masks are derived from the vulnerable API calls or from analyzer findings. Without such evidence, the central attribution of the method's success to security localization is under-supported.
[Section 7, Table 1] The headline claim that LPO outperforms SFT, DPO, SimPO, and SafeCoder in 15 of 16 model-benchmark combinations is based on point estimates without confidence intervals or significance tests. The security benchmarks are small: Asleep has 29 prompts, LLMSecEval 81, and Security Eval 121, with 5 samples per prompt, so the number of valid generations is moderate and differences of a few percentage points can be noise. This is not merely theoretical: for Phi-2 on Asleep, LPO reports InS=73.9 while SFT reports 64.3, DPO 64.1, and SimPO 66.9, so the one counterexample is a sizable gap. Please report bootstrap confidence intervals or paired significance tests across the five sampled generations, and discuss the Phi-2/Asleep result explicitly rather than folding it into an aggregate claim.
[Section 7.3 and Table 1] The statement that DiSCo and LPO 'also improve overall code quality' is made relative to the off-the-shelf base models, but for the effect of LPO itself the relevant comparison is to SFT on DiSCo, since LPO is always applied after SFT. By that comparison LPO often degrades utility substantially: for Mistral-7B, HumanEvalX pass@1 drops from 37.1 (SFT) to 28.7 (LPO) and pass@5 from 51.2 to 49.4; for CodeLlama-7B, HumanEvalX pass@5 drops from 58.5 to 53.0; for Phi-2, MBXP pass@1 drops from 57.5 to 57.2. The paper should clearly separate the utility gains attributable to DiSCo/SFT from the utility changes attributable to LPO, and should not imply that LPO itself preserves or improves utility in all configurations.

minor comments (5)

[Appendix E, DPO baseline] The DPO loss function is displayed with the label 'LSimPO', which is confusing since the section is describing DPO; the label should be L_DPO.
[Appendix C] The text says that tokenizing y+ and y− 'results in fixed size embeddings' and then computes a delta between these 'embeddings'. The masks are in fact computed from token indices, not from embedding vectors; please rephrase to avoid implying that embedding vectors are involved.
[Section 6.1 and Table 1] The benchmark labeled 'DiSCo' in Table 1 is the held-out split of the same distillation distribution as the training data. This is fine as a sanity check, but the main text should state explicitly, at the point of first use, that this is an in-distribution test set and should not be pooled with the external benchmarks when discussing generalization.
[Table 5] The column ordering in Table 5 is easy to misread: the 'Error' column is placed to the left of 'Datasets', and for the first row the value 12.7 is the percentage of erroneous datapoints, not an InSec value. Please reorder or relabel the columns so the reader can parse the ablation with respect to both data quality and downstream performance.
[Section 6.4 and Appendix F] The hyperparameters β=10.0, γ=5.4, α=0.05 for LPO are given without sensitivity analysis. Since these interact with the mask computation, a short sensitivity study (e.g., varying α, which controls the utility/security trade-off) would substantially strengthen the practical guidance.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: LPO is an empirical training recipe evaluated on external benchmarks and held-out data, with no derived quantity forced by construction.

full rationale

The paper's derivation chain is empirical rather than definitional. DiSCo is synthesized from GPT-4o using security-knowledge prompts and analyzer-based refinement (Section 4), and LPO is a preference loss over token masks computed by difflib between the secure and insecure training responses (Section 5.2, Appendix C). The masks are derived from training pairs, not from test labels or benchmark answers, so the reported InSec and I@100 reductions are not forced by construction. Evaluation is performed on external security benchmarks (Security Eval, Asleep, LLMSecEval) and external coding benchmarks (HumanEvalX, MBXP), plus a held-out DiSCo-Test split (Sections 6.1 and 6.3); none of these are used to fit the loss hyperparameters. The paper explicitly acknowledges the synthetic data can be noisy and states that "evaluation signals on this dataset can only be seen as noisy indicators" and that "we must use other datasets (as we did in this paper) for careful evaluation" (Limitations), which it does. The main substantive risk noted by a careful reader—that difflib masks may mark formatting or refactoring tokens as security-relevant—is a validity/attribution assumption about the mask, not a circular step in the derivation: the paper does not define 'security-relevant' as 'diff tokens' and then use that definition to conclude the security results; it independently measures security with CodeQL and Bandit. There are no load-bearing self-citations, no imported uniqueness theorems, and no fitted parameter renamed as a prediction. The central claims therefore stand as an empirically tested training recipe with no significant circularity.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The central claim rests on the assumptions that token diffs mark security relevance, static analyzers are a valid security oracle, GPT-4o with one refinement yields usable training data, and security reasoning before code helps. The only fitted values are the LPO hyperparameters β, γ, α; no constants are derived and then 'predicted'.

free parameters (3)

LPO reward scale β = 10.0
Chosen for LPO across all models; Appendix F. Not tuned per model, but a hand-set constant.
LPO target margin γ = 5.4
Hand-set margin in the SimPO-style loss; Appendix F.
Regularizer weight α = 0.05
Weight of the SFT term in LPO; Appendix F.

assumptions (4)

domain assumption The token-level diff between y+ and y- identifies all and only the security-relevant tokens.
Used to build masks m+ and m- in LPO. Stated in Section 5.2 and Appendix C; if diff includes non-security changes, the loss is misdirected.
domain assumption Static analyzers CodeQL and Bandit give an adequate measure of code security for both data refinement and evaluation.
Used throughout Section 4.2 and 6.3; analyzers have known false positives and negatives, so this is a domain assumption.
domain assumption One round of LLM refinement guided by analyzer feedback is sufficient to make y+ a good training target, even though 12.7% still contain issues.
Section 4.2 and Table 5; the authors deliberately keep the noisy data.
domain assumption Requiring security reasoning R before generating code improves secure code generation.
Design of the SFT stage, Section 5.1, tested in ablation; not derived from first principles.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Teaching an Old LLM Secure Coding: Localized Preference Optimization on Distilled Preferences." pith.science (2026). https://pith.science/paper/KJVKR5SP

@misc{pith2026250600419,
  author       = {Pith},
  title        = {Pith review of: Teaching an Old LLM Secure Coding: Localized Preference Optimization on Distilled Preferences},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KJVKR5SP}},
  note         = {Machine review of arXiv:2506.00419}
}

read the original abstract

LLM generated code often contains security issues. We address two key challenges in improving secure code generation. First, obtaining high quality training data covering a broad set of security issues is critical. To address this, we introduce a method for distilling a preference dataset of insecure and secure code pairs from frontier LLMs, along with a security reasoning that explains the issues and the fix. The key idea here is to make use of security knowledge sources to devise a systematic prompting strategy that ensures broad coverage. Second, aligning models to secure code requires focusing on localized regions of code. Direct preference optimization methods, like SimPO, are not designed to handle these localized differences and turn out to be ineffective. We address this with a new localized preference optimization algorithm that masks the security related tokens in both the winning (secure) and losing (insecure) responses. To prevent loss in code quality, we also add a regularizer. Evaluations show that both training on our dataset, DiSCo, and the new preference optimization algorithm, LPO, yield substantial reductions in code insecurity while also improving overall code quality. Code and dataset are available at https://github.com/StonyBrookNLP/disco-lpo.

Figures

Figures reproduced from arXiv: 2506.00419 by the authors.

**Figure 1.** Our Methodology:(1)We extract security information from open domain sources such as (CWE-ID, Issue, Description) and Package info to create prompts. These prompts are fed into frontier models to generate our dataset DiSCo. To improve security of generated secure code, we feed it through an analyzer, obtain feedback and prompt the LLM to refine it. (2) Our final DiSCo contains pairs of (Task Instruction, Secure Code … view at source ↗

**Figure 2.** [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗

**Figure 3.** DiSCo Example:This is an example from the dataset DiSCo generated for evaluation with the elements:(a) task instruction x, (b) insecure code y −, (c) secure code y + and (d) reasoning R. Red portions in insecure code correspond to tokens that lead to insecurity, green portions in secure code correspond to tokens that improve security. Rest of the segments, common across both, have no relation to security. for tokens… view at source ↗

Figures from the paper (2 more)

**Figure 4.** Figure 4: Full CWE Analysis for Starcoder2 baselines and LPO tuned on DiSCo for all the benchmarks. ... def get_file_info(filename): try: return os.popen(f"file {filename}").read() except Exception as e: return str(e) ... ... def get_file_info(filename): try [PITH_FULL_IMAGE:fi…

**Figure 5.** Figure 5: Example of over-engineering due to refinement: The left portion shows a small portion of a secure code datapoint from DiSCo after one round of iteration. It contains CWE-78 vulnerability, corresponding to the os command injection security issue as user input is being d…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

14 extracted references · 8 canonical work pages

[1]

Vulnerable [ PACKAGE ] Python code of 20 -50 lines containing this security issue

work page
[2]

Reasoning on why this code is vulnerable

work page
[3]

Secure / fixed version of this code with minimal change

work page
[4]

Reasoning on why the second version is fixed

work page
[5]

Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri

Training language models to follow instruc- tions with human feedback.Advances in neural in- formation processing systems, 35:27730–27744. Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. 2022. Asleep at the keyboard? assessing the security of github copilot’s code contributions. In2022 IEEE Symposium on Security and Pr...

work page 2022
[7]

Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Tal Remez, Jérémy Rapin, et al

Direct preference optimization: Your language model is secretly a reward model.Advances in Neu- ral Information Processing Systems, 36. Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Tal Remez, Jérémy Rapin, et al. 2023. Code llama: Open foundation models for code.arXiv preprint arXiv:23...

arXiv 2023
[8]

In 32nd USENIX Security Symposium (USENIX Secu- rity 23), pages 2205–2222

Lost at c: A user study on the security impli- cations of large language model code assistants. In 32nd USENIX Security Symposium (USENIX Secu- rity 23), pages 2205–2222. Inbal Shani. 2023. Survey reveals ai’s impact on the developer experience. https://github.blog/news- insights/research/survey-reveals-ais-impact-on-the- developer-experience/. Mohammed L...

arXiv 2023
[13]

Complete the following code : ```python [ PROMPT ]

A short instruction summary ( one or two sentence ) that can be used by a language model to generate either of the code . There should be no comment in the code . Reasoning should be within one or two sentence . The security issue should be implicit . The issue should not be mentioned in the instruction summary . Give your answer in following format : VUL...

work page 2022

Show all 14 references

[768]

Jinjun Peng, Leyi Cui, Kele Huang, Junfeng Yang, and Baishakhi Ray

IEEE. Jinjun Peng, Leyi Cui, Kele Huang, Junfeng Yang, and Baishakhi Ray. 2025. Cweval: Outcome-driven eval- uation on functionality and security of llm code gen- eration.arXiv preprint arXiv:2501.08200. Rafael Rafailov, Archit Sharma, Eric Mitchell, Christo- pher D Manning, S...

2025 arXiv
[2020]

InProceedings of the 17th International Conference on Mining Software Repositories, MSR ’20, page 508–512, New York, NY , USA

A c/c++ code vulnerability dataset with code changes and cve summaries. InProceedings of the 17th International Conference on Mining Software Repositories, MSR ’20, page 508–512, New York, NY , USA. Association for Computing Machinery. Nat Friedman. 2021. Introducing github co...

2021 arXiv
[2021]

file {filename}

dataset, which consisted of only prompts for Python programming language, by including other languages and increasing the number of testcases by 35 times. The problems are designed to be sim- pler than HumanEvalX and assess the fundamental programming abilities of LLMs and not...

2024
[2022]

Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, et al

Multi-lingual evaluation of code generation models.arXiv preprint arXiv:2210.14868. Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, et al. 2021. Program synthesis with large language mo...

arXiv
[2023]

InProceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, pages 6737–6749, Singapore

Personalized distillation: Empowering open- sourced LLMs with adaptive learning for code gen- eration. InProceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, pages 6737–6749, Singapore. Association for Com- putational Linguistics. Mark Chen, ...

2023 arXiv
[2024]

In Proceedings of the 62nd Annual Meeting of the As- sociation for Computational Linguistics (Volume 1: Long Papers), pages 4571–4585, Bangkok, Thailand

StepCoder: Improving code generation with reinforcement learning from compiler feedback. In Proceedings of the 62nd Annual Meeting of the As- sociation for Computational Linguistics (Volume 1: Long Papers), pages 4571–4585, Bangkok, Thailand. Association for Computational Ling...

2024

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

Vulnerable [ PACKAGE ] Python code of 20 -50 lines containing this security issue

work page

[2] [2]

Reasoning on why this code is vulnerable

work page

[3] [3]

Secure / fixed version of this code with minimal change

work page

[4] [4]

Reasoning on why the second version is fixed

work page

[5] [5]

Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri

Training language models to follow instruc- tions with human feedback.Advances in neural in- formation processing systems, 35:27730–27744. Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. 2022. Asleep at the keyboard? assessing the security of github copilot’s code contributions. In2022 IEEE Symposium on Security and Pr...

work page 2022

[6] [7]

Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Tal Remez, Jérémy Rapin, et al

Direct preference optimization: Your language model is secretly a reward model.Advances in Neu- ral Information Processing Systems, 36. Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Tal Remez, Jérémy Rapin, et al. 2023. Code llama: Open foundation models for code.arXiv preprint arXiv:23...

arXiv 2023

[7] [8]

In 32nd USENIX Security Symposium (USENIX Secu- rity 23), pages 2205–2222

Lost at c: A user study on the security impli- cations of large language model code assistants. In 32nd USENIX Security Symposium (USENIX Secu- rity 23), pages 2205–2222. Inbal Shani. 2023. Survey reveals ai’s impact on the developer experience. https://github.blog/news- insights/research/survey-reveals-ais-impact-on-the- developer-experience/. Mohammed L...

arXiv 2023

[8] [13]

Complete the following code : ```python [ PROMPT ]

A short instruction summary ( one or two sentence ) that can be used by a language model to generate either of the code . There should be no comment in the code . Reasoning should be within one or two sentence . The security issue should be implicit . The issue should not be mentioned in the instruction summary . Give your answer in following format : VUL...

work page 2022