Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
जमा करें
उपकरणब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
उपकरण/GitHubGitHub/foxirain/linux-kernel-codex-harness-v2
स्थैतिक विश्लेषणभेद्यता विश्लेषणखतरा खुफियाAI सुरक्षा
GitHubfoxirain/linux-kernel-codex-harness-v2

linux-kernel-codex-harness-v2

प्रोवेनेंस-जागरूक Linux कर्नेल भेद्यता अनुसंधान हार्नेस, जिसका उपयोग CVE-2026-53075 की जांच में किया गया है।

रिपॉजिटरी देखें

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
123 दिन पहलेअभी तक समीक्षित नहीं
साझा करें

Kernel Codex Harness v2

한국어 | English

CI

अनुसंधान उपकरण · मूल आयात: 3 अप्रैल 2026 · v2 दस्तावेज़ संशोधन: 11 जुलाई 2026

बाह्य संकेत: ध्यान आवंटन से प्रोवेनेंस-जागरूक ट्राइएज तक
मॉडल का ध्यान निर्देशित करने के लिए पुनरुत्पादनीय अवलोकनों का उपयोग करें, फिर समीक्षा कतारों को व्यवस्थित करने के लिए रिपॉजिटरी प्रोवेनेंस का उपयोग करें—कभी भी प्रमाण का दावा न करें।

परियोजना वंशावली— Kernel Codex Harness v1 · ध्यान आवंटन → Kernel Codex Harness v2 · प्रोवेनेंस-जागरूक ट्राइएज

परियोजना स्थिति. यह रिपॉजिटरी वास्तविक Linux कर्नेल भेद्यता अनुसंधान के लिए v1 के attention-allocation workflow को provenance-aware triage तक विकसित करने वाला LLM-सहायता प्राप्त अनुसंधान हार्नेस है। इस संस्करण का उपयोग CVE-2026-53075 के रूप में प्रकाशित भेद्यता की खोज के लिए किया गया था। यह स्वचालित भेद्यता डिटेक्टर, नवीनता निर्णायक, exploit सत्यापनकर्ता या कर्नेल सुरक्षा आश्वासन उपकरण नहीं है; अंतिम सत्यापन और रिपोर्टिंग मनुष्यों द्वारा की जाती है।

सार

सार— Linux कर्नेल जैसे बड़े कोडबेस को LLM में सीधे खोजने देने से संदर्भ बिखर जाता है, और खतरनाक API की उपस्थिति तथा वास्तविक शोषण क्षमता आसानी से भ्रमित हो जाती है। इस समस्या को दो-चरणीय प्रसंस्करण के रूप में परिभाषित करता है। मॉडल कॉल से पहले, पथ भार, शाब्दिक हिट, और कैश्ड syzbot ओवरलैप के साथ उम्मीदवार फ़ाइलों को रैंक करके ध्यान आवंटित किया जाता है। मॉडल प्रतिक्रिया के बाद, Git branch·HEAD·dirty state को प्रतिक्रिया से निकाले गए CVE·commit·known marker के साथ जोड़कर strong finding को provenance-aware review bucket में वर्गीकृत किया जाता है। इस हार्नेस का उपयोग वास्तविक Linux कर्नेल अनुसंधान में PPP के target network namespace अनुमति सत्यापन दोष की खोज के लिए किया गया था, जिसे के रूप में प्रकाशित किया गया। Triage अनुसंधान कतार को व्यवस्थित करने वाला heuristic है; विशेष रूप से, का अर्थ केवल यह है कि कोई ज्ञात संकेत या provenance समस्या नहीं मिली, यह novelty proof नहीं है। सभी findings के लिए userspace reachability, invariant break, और concrete impact का मानव पुनः-सत्यापन आवश्यक है।

Kernel Codex Harness v2
बाह्य संकेत
CVE-2026-53075
new_candidate

सूचकांक शर्तें— Linux कर्नेल, भेद्यता अनुसंधान, बाह्य संकेत, प्रोवेनेंस, heuristic ट्राइएज, LLM ऑर्केस्ट्रेशन, syzbot, Codex.

I. परिचय

कर्नेल सुरक्षा समीक्षा में दो अलग-अलग प्रकार की अनिश्चितताएँ होती हैं।

  1. पहले कहाँ देखें। पूरा सोर्स ट्री एक मॉडल संदर्भ में समाहित करने के लिए बहुत बड़ा है।
  2. मॉडल द्वारा उत्पन्न strong finding को कैसे संभालें। स्थानीय संशोधन, मौजूदा fix, ज्ञात CVE या अपूर्ण रिपॉजिटरी स्थिति निष्कर्षों को दूषित कर सकती है।

v1 की केंद्रीय समस्या पहली थी, अर्थात् attention allocation। v2 उस सिद्धांत को बनाए रखते हुए दूसरी समस्या को provenance-aware triage तक विस्तारित करता है। दोनों संस्करणों का उपयोग वास्तविक अनुसंधान में किया गया; v1-सहायता प्राप्त अनुसंधान CVE-2026-31720 तक और v2-सहायता प्राप्त अनुसंधान CVE-2026-53075 तक पहुँचा।

मॉडल के बाहर के अवलोकनों से अनुसंधान का दायरा सीमित करें, और मॉडल प्रतिक्रिया के बाद सत्यापन योग्य रिपॉजिटरी प्रोवेनेंस जोड़ें। किसी भी चरण का संकेत भेद्यता या नवीनता सिद्ध नहीं करता।

II. बाह्य संकेत और डिज़ाइन सिद्धांत

A. चरण 1 — अनुमान से पहले ध्यान आवंटन

Pre-inference बाह्य संकेत LLM निर्णय नहीं है, बल्कि मॉडल निष्पादन से पहले गणना किए गए अवलोकन हैं।

  • कर्नेल पथ और subsystem भार
  • usercopy, allocator, refcount, size, lock आदि शाब्दिक हिट
  • संग्रहीत syzbot JSON का file/subsystem ओवरलैप

समान सोर्स ट्री, प्रोफ़ाइल और कैश्ड syzbot JSON का उपयोग करके उम्मीदवार रैंक की पुनर्गणना की जा सकती है। यह स्कोर संभाव्यता या शोषण क्षमता नहीं है, बल्कि पहले कहाँ देखना है यह तय करने वाला सापेक्ष क्रम है।

B. चरण 2 — अनुमान के बाद प्रोवेनेंस-जागरूक ट्राइएज

Post-inference चरण strong model verdict में निम्नलिखित जानकारी जोड़ता है।

  • Git रिपॉजिटरी की उपस्थिति और status संग्रह की सफलता
  • branch और HEAD
  • रिपॉजिटरी और target फ़ाइल की dirty state
  • प्रतिक्रिया से निकाले गए CVE, commit hash, known-issue marker
  • प्रतिक्रिया में दिखाई देने वाले negation या unrelated-reference अभिव्यक्तियाँ

इस दस्तावेज़ में, post-inference बाह्य संकेत केवल उस प्रोवेनेंस को संदर्भित करता है जो मॉडल से स्वतंत्र रूप से एकत्र किया गया है, जैसे Git repository/status, branch, HEAD, dirty state, local commit ancestry। CVE·commit·known marker मॉडल प्रतिक्रिया से निकाले गए model-derived reference हैं, बाह्य संकेत या आधिकारिक तथ्य नहीं। Triage दोनों प्रकार के इनपुट को जोड़ता है लेकिन उनके स्रोत को अलग-अलग दर्ज करता है।

C. Heuristic Buckets, नवीनता प्रमाण नहीं

Strong finding को परिचालन रूप से निम्नलिखित review bucket में से एक में व्यवस्थित किया जाता है।

Bucketअर्थ
new_candidateवह उम्मीदवार जिसका provenance सत्यापित है और कोई dirty/known blocking signal नहीं मिला
known_issueवह उम्मीदवार जिसमें non-negated known reference है, या प्रतिक्रिया fix/upstream संबंध के रूप में इंगित करती है और वर्तमान HEAD में शामिल commit की पुष्टि हुई है
dirty_tree_suspectवह उम्मीदवार जिसमें dirty repository या dirty target के प्रभाव को खारिज नहीं किया जा सकता
provenance_unknownवह उम्मीदवार जिसके लिए Git repository, status या HEAD विश्वसनीय रूप से सत्यापित नहीं किया जा सका

सभी वर्गीकरण परिणामों का novelty_proven false है। new_candidate का अर्थ "नई भेद्यता" नहीं है, बल्कि वह कतार है जिसमें मनुष्य को पहले नवीनता अनुसंधान जारी रखना चाहिए।

D. Bug Class से पहले Reachability

ऑडिट पहले उन सीमाओं की जाँच करता है जो userspace से शुरू होती हैं, जैसे syscall, ioctl, netlink, procfs, filesystem, BPF, driver hook। उसके बाद ही UAF, OOB, refcount, race, info leak, capability check जैसे bug class का मूल्यांकन किया जाता है।

E. एक समय में एक अनुसंधान शाखा

एक अनुसंधान इकाई एक फ़ाइल और उसके निकटवर्ती caller·teardown·free path तक सीमित है। मॉडल द्वारा सुझाए गए manual follow-up अधिकतम दो बार तक सीमित हैं ताकि व्यापक खोज के बजाय सत्यापन योग्य छोटा पथ बना रहे।

F. आत्मविश्वास से अधिक साक्ष्य

Strong finding को कम से कम निम्नलिखित की व्याख्या करनी चाहिए।

  1. attacker-reachable entrypoint,
  2. attacker-controlled field या lifetime transition,
  3. टूटता हुआ object·length·state invariant,
  4. corruption, leak, privilege escalation जैसा ठोस impact,
  5. मौजूदा check हमले को क्यों नहीं रोकता।

Parser केवल verdict और next target को सामान्यीकृत करता है; यह इस साक्ष्य की पूर्णता को स्वचालित रूप से सिद्ध नहीं करता।

G. डिज़ाइन वंशावली

प्रारंभिक प्रवाह Protect AI के vulnhuntr द्वारा उपयोग किए गए फ़ाइल-स्तरीय विश्लेषण, सीमित संदर्भ विस्तार और संरचित आउटपुट के विचार से शुरू हुआ [1]। इस परियोजना में इसे userspace-reachable kernel surface, कर्नेल ऑब्जेक्ट lifetime, teardown path और syzbot ओवरलैप के अनुरूप पुनः डिज़ाइन किया गया। v2 का अतिरिक्त योगदान attention allocation के बाद रिपॉजिटरी प्रोवेनेंस का उपयोग करके finding triage चरण रखना है।

III. सिस्टम आर्किटेक्चर

Kernel Codex Harness v2 के लिए दो-चरणीय बाह्य संकेत आर्किटेक्चर

चित्र 1. Pre-inference बाह्य संकेत पुनरुत्पादनीय समीक्षा इकाइयों को रैंक करता है। Post-inference triage मॉडल-स्वतंत्र Git प्रोवेनेंस को मॉडल-व्युत्पन्न प्रतिक्रिया संदर्भों के साथ जोड़ता है, बिना बाद वाले को बाह्य संकेत या आधिकारिक तथ्य माने। मानव सत्यापन दोनों स्वचालित चरणों के बाहर रहता है।

तालिका I — प्रमुख मॉड्यूल जिम्मेदारियाँ

मॉड्यूलजिम्मेदारी
targeting.pyकर्नेल फ़ाइल खोज और path·lexical·syzbot संकेत स्कोरिंग
models.pyCandidate, Signal, syzbot-व्युत्पन्न ExternalSignal
bundle.pymanifest, session index, prompt/snippet bundle निर्माण
prompting.pyreachability और invariant-केंद्रित कर्नेल ऑडिट प्रॉम्प्ट
session.pypending review, history, follow-up depth स्थिति संग्रहण
ingest.pystrict verdict और single next target सामान्यीकरण
repo_state.pyGit branch, HEAD, status, dirty path, ancestry संग्रह
finding_triage.pyprovenance और known-reference आधारित heuristic bucket वर्गीकरण
autopilot.pyसमय-बजट आधारित Codex निष्पादन, ingest, archive, finding रिकॉर्डिंग
syzbot.pyसार्वजनिक syzbot HTML संग्रह और स्थानीय JSON cache निर्माण
cli.pyscan/review/doctor/autopilot कमांड कनेक्शन

IV. कार्यप्रणाली

A. उम्मीदवार खोज और स्कोरिंग

स्कैनर प्रोफ़ाइल के include directory के अंतर्गत .c और .h फ़ाइलों को पार करता है।

root@kitploit:~
Score(f) = Σ path_weight(f)
         + Σ line_signal_weight(f)
         + Σ syzbot_overlap_weight(f)

वर्तमान कार्यान्वयन line-level match को जोड़ता है और प्रॉम्प्ट में प्रदर्शित करने के लिए शीर्ष संकेतों की संख्या को सीमित करता है। स्कोर मॉडल के अनुसंधान क्रम को निर्धारित करता है, लेकिन यह भेद्यता संभावना के लिए कैलिब्रेटेड सांख्यिकीय मान नहीं है।

मुख्य स्थिर संकेत निम्नलिखित हैं।

  • ioctl, compat handler, file operation hook
  • copy_from/to_user और __user
  • kmalloc/kzalloc/kvmalloc, cache आवंटन और free path
  • refcount, atomic, kref
  • size·length गणना और memcpy श्रृंखला
  • lock, RCU, async lifetime
  • BPF, skb, XDP, netlink
  • capability और namespace check

B. प्रोफ़ाइल-संचालित दायरा

प्रोफ़ाइलफोकस
defaultkernel/mm/net/fs/security/io_uring/lib/drivers प्रारंभिक बिंदु
netnetlink, socket, skb, XDP
fsioctl, procfs, seq_file, debugfs
io_uringasync request lifetime और teardown
bpfverifier, map/program lifetime, BTF
driversioctl, DMA, MMIO और driver teardown

C. क्रैश इंटेलिजेंस

syzbot-fetch सार्वजनिक syzbot bug page से title, subsystem, bug type, file:line निकालकर JSON में संग्रहीत करता है। exact file overlap मजबूत ranking signal है, subsystem overlap कमजोर signal है। Live dashboard बदल सकता है, इसलिए पुनरुत्पादन इकाई fetch समय की संग्रहीत JSON है। Crash overlap variant hunting का संकेत है, भेद्यता का प्रमाण नहीं।

D. सत्र और समीक्षा अनुबंध

scan पूर्ण ranked candidate manifest और शीर्ष prompt bundle उत्पन्न करता है। --limit manifest में बनाए रखने के लिए उम्मीदवारों की संख्या है और --top पहले से उत्पन्न करने के लिए bundle की संख्या है। बाद के रैंक भी अनुरोध पर उत्पन्न किए जा सकते हैं।

मॉडल प्रतिक्रिया को निम्नलिखित verdict में से एक में सामान्यीकृत किया जाता है।

  • cve_candidate
  • plausible_security_bug
  • latent_bug
  • not_cve_candidate
  • needs_more_context

मैन्युअल review और autopilot समान review_state.json, निश्चित प्रतिक्रिया पथ और verdict parser का उपयोग करते हैं।

E. प्रोवेनेंस संग्रह और ट्राइएज

doctor और autopilot Git रिपॉजिटरी की उपस्थिति, status संग्रह की सफलता, branch, HEAD और dirty path की जाँच करते हैं। जिस स्थिति में provenance निर्धारित नहीं किया जा सकता, उसे clean नहीं माना जाता बल्कि provenance_unknown के रूप में संरक्षित किया जाता है।

Strong verdict का triage लगभग निम्नलिखित प्राथमिकता का पालन करता है।

  1. यदि provenance विश्वसनीय नहीं है तो provenance_unknown,
  2. यदि repository या target dirty है तो dirty_tree_suspect,
  3. यदि संबंधित CVE·non-negated marker है, या प्रतिक्रिया fix/upstream संबंध के रूप में इंगित करने वाला commit वर्तमान HEAD ancestor है तो known_issue,
  4. अन्यथा new_candidate.

"not a known issue", "unrelated to CVE-…" जैसी नकारात्मक·असंबंधित अभिव्यक्तियों का उपयोग known आधार के रूप में नहीं किया जाता। अंतिम निर्णय में मूल verdict के साथ branch, HEAD, status, dirty state, matched reference और reason दर्ज किए जाते हैं।

वर्तमान provenance-aware bucket वर्गीकरण और JSONL writer autopilot ingest पथ पर लागू होते हैं। मैन्युअल loop और ingest समान मूल session state और verdict parser का उपयोग करते हैं लेकिन bucket artifact नहीं बनाते।

V. कार्यान्वयन और उपयोग

A. आवश्यकताएँ

  • Python 3.11 या उच्चतर
  • Linux कर्नेल सोर्स ट्री
  • provenance/doctor/autopilot उपयोग के लिए Git
  • autopilot उपयोग के लिए Codex CLI और प्रमाणीकरण [3]
  • दूरस्थ syzbot संग्रह के लिए नेटवर्क कनेक्शन

Python runtime निर्भरता केवल मानक पुस्तकालय है।

B. स्थापना

root@kitploit:~
git clone https://github.com/foxirain/linux-kernel-codex-harness-v2.git
cd linux-kernel-codex-harness-v2

python3 -m venv .venv
source .venv/bin/activate
python -m pip install .
kernel-harness --help

अंतर्निहित प्रोफ़ाइल JSON wheel में शामिल हैं। अतिरिक्त नियम --config /path/to/profile.json के माध्यम से पारित किए जा सकते हैं।

C. न्यूनतम कार्यप्रवाह

root@kitploit:~
# 1. रिपॉजिटरी प्रोवेनेंस सत्यापित करें।
kernel-harness doctor /path/to/linux

# 2. रैंक किया गया सत्र बनाएं।
kernel-harness scan /path/to/linux \
  --profile net \
  --limit 80 \
  --top 20 \
  --out artifacts

# 3. एक केंद्रित समीक्षा का निरीक्षण और प्रस्तुत करें।
kernel-harness inspect artifacts/session-YYYYMMDDTHHMMSSZ --top 10
kernel-harness codex artifacts/session-YYYYMMDDTHHMMSSZ \
  --rank 1 \
  --include-snippet

मैन्युअल Codex प्रतिक्रिया runbook द्वारा निर्दिष्ट codex_response.txt में संग्रहीत करने के बाद निम्नलिखित कमांड से ingest की जा सकती है।

root@kitploit:~
kernel-harness loop artifacts/session-YYYYMMDDTHHMMSSZ --include-snippet
kernel-harness status artifacts/session-YYYYMMDDTHHMMSSZ

D. समय-बजट Autopilot

root@kitploit:~
kernel-harness autopilot artifacts/session-YYYYMMDDTHHMMSSZ \
  --duration 30m \
  --per-run-timeout 10m \
  --include-snippet \
  --require-clean-tree \
  --stop-on-finding

Codex sandbox डिफ़ॉल्ट read-only है। --require-clean-tree केवल तभी निष्पादन की अनुमति देता है जब Git repository, status, HEAD सत्यापित हों और working tree clean हो। --stop-on-finding केवल तभी रुकता है जब heuristic triage परिणाम new_candidate हो।

E. वैकल्पिक syzbot फ़ीड

root@kitploit:~
kernel-harness syzbot-fetch https://syzkaller.appspot.com/upstream \
  --out artifacts/syzbot/upstream.json \
  --limit 50

kernel-harness syzbot-stats artifacts/syzbot/upstream.json --top 15

kernel-harness scan /path/to/linux \
  --profile fs \
  --syzbot-json artifacts/syzbot/upstream.json \
  --out artifacts

F. सत्र आर्टिफैक्ट

root@kitploit:~
artifacts/session-<timestamp>/
├── SESSION.md
├── targets.json
├── finding_template.json
├── review_state.json
├── codex_response.txt              # प्रतिक्रिया pending होने पर मौजूद
├── bundles/
├── responses/
└── autopilot/
    ├── AUTOPILOT_STATUS.txt
    ├── AUTOPILOT_PROGRESS.txt
    ├── AUTOPILOT_BASELINE.json
    ├── AUTOPILOT_FINDINGS.txt
    ├── AUTOPILOT_FINDINGS_NEW.txt
    ├── AUTOPILOT_KNOWN_ISSUES.txt
    ├── AUTOPILOT_SUSPECTS.txt
    ├── AUTOPILOT_PROVENANCE_UNKNOWN.txt
    ├── AUTOPILOT_FINDINGS.jsonl
    ├── prompts/
    ├── exec/
    ├── parse_errors/
    └── findings/
        ├── new/
        ├── known/
        ├── suspects/
        └── unknown/

AUTOPILOT_FINDINGS.jsonl verdict, bucket, reason, branch, HEAD, provenance स्थिति, matched reference और finding/archive पथ को post-processing योग्य रूप में संरक्षित करता है।

VI. परिचालन परिणाम और सत्यापन

v2 ने विस्तारित संरचना को वास्तविक Linux कर्नेल भेद्यता अनुसंधान पर लागू किया।

तालिका II — प्रकाशित भेद्यता परिणाम

सार्वजनिक परिणामप्रभावित क्षेत्रगंभीरता / CVSSभेद्यताअनुसंधान मॉडल
CVE-2026-53075PPP · drivers/net/ppp/ppp_generic.cHigh 8.8 · CVSS 3.1 (Linux CNA)Unattached administrative ioctls में target network namespace के स्वामी user namespace के विरुद्ध CAP_NET_ADMIN जाँच का अभाव थाFinding v2-सहायता प्राप्त अनुसंधान के दौरान सामने आई; सत्यापन और प्रकटीकरण मानव-नेतृत्व में रहे
CVSS स्रोत (2026-08-09 को सत्यापित)
  • CVE-2026-53075: Linux CNA CVE रिकॉर्ड · CVSS 3.1 · 8.8 High · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
  • आधिकारिक प्रकाशित स्कोर और vector को स्थानांतरित किया गया; अलग से पुनर्गणना नहीं की गई।

16 regression test सुरक्षा पहचान सटीकता benchmark नहीं हैं, बल्कि software contract और तैनाती क्षमता पर केंद्रित हैं।

  • allocator और built-in profile संसाधन प्रतिगमन
  • negative verdict और सामान्य गद्य में CVE अभिव्यक्तियाँ strong finding में नहीं बदलतीं
  • manual follow-up सीमा और rank ordering
  • pending target के बिना stale response archive
  • read-only sandbox डिफ़ॉल्ट और positive CLI तर्क
  • missing/non-Git/status-failure का fail-closed provenance
  • dirty target, known reference, negation, unrelated CVE triage
  • वर्गीकरण मेटाडेटा का session history और JSONL संरक्षण
  • parse-error और finding artifact अनुबंध
  • स्थापित wheel से प्रोफ़ाइल स्कैन smoke test
root@kitploit:~
python -m unittest discover -s tests -v
python -m pip wheel . --no-deps --wheel-dir dist
python -m pip install --force-reinstall dist/*.whl

GitHub Actions Python 3.11 और 3.12 पर regression test चलाता है, wheel स्थापित करता है, और 6 पैकेज्ड प्रोफ़ाइल तथा डिफ़ॉल्ट स्कैन का smoke-test करता है। उपरोक्त सार्वजनिक मामला वास्तविक अनुसंधान से प्राप्त परिचालन परिणाम है, लेकिन यह प्रतिनिधि Linux tree corpus पर मापा गया precision, recall, exploitability या CVE discovery rate benchmark नहीं है।

VII. सुरक्षा विचार

  • Codex sandbox डिफ़ॉल्ट read-only है और इसे बनाए रखने की अनुशंसा की जाती है।
  • यदि clean provenance महत्वपूर्ण है, तो doctor के बाद --require-clean-tree का उपयोग करें।
  • non-Git या status/HEAD सत्यापन विफलता को clean के रूप में न समझें।
  • --dangerously-bypass-approvals-and-sandbox का उपयोग पृथक प्रयोगात्मक वातावरण के बिना न करें।
  • source comment और identifier भी मॉडल इनपुट हैं, इसलिए prompt injection की संभावना पर विचार करें।
  • CVE·commit स्ट्रिंग केवल प्रतिक्रिया संदर्भ हैं, आधिकारिक पुष्टि नहीं।
  • finding प्रकाशित या रिपोर्ट करने से पहले मनुष्य reachability, invariant, impact और affected version को पुनः सत्यापित करता है।

VIII. सीमाएँ और वैधता के लिए खतरे

  1. शाब्दिक विश्लेषण। वास्तविक C AST, call graph, interprocedural data flow का निर्माण नहीं करता।
  2. स्कोर पूर्वाग्रह। टिप्पणियाँ, मैक्रो, दोहराए गए token और बड़ी फ़ाइलें स्कोर पर अत्यधिक प्रभाव डाल सकती हैं।
  3. Reachability अंतर। kernel config, privilege, namespace, device उपलब्धता को स्वचालित रूप से मॉडल नहीं करता।
  4. बाह्य डेटा नाजुकता। syzbot एकीकरण सार्वजनिक HTML संरचना परिवर्तनों से प्रभावित होता है।
  5. केवल स्थानीय प्रोवेनेंस। Git ancestry वर्तमान checkout के HEAD पर आधारित है और सभी upstream·vendor history का प्रतिनिधित्व नहीं करता।
  6. प्रतिक्रिया-व्युत्पन्न संदर्भ। CVE और known marker मॉडल प्रतिक्रिया से निकाले जाते हैं, इसलिए चूक, भ्रम या संदर्भ गलतफहमी की संभावना है।
  7. Heuristic triage। new_candidate और known_issue दोनों अंतिम नवीनता निर्णय नहीं हैं।
  8. मॉडल निर्भरता। परिणाम की गुणवत्ता मॉडल, prompt interpretation और उपलब्ध रिपॉजिटरी संदर्भ पर निर्भर करती है।
  9. मूल्यांकन दायरा। वर्तमान परीक्षण software regression को सत्यापित करते हैं। प्रकाशित CVE मामला वास्तविक उपयोग परिणाम है, लेकिन सुरक्षा पहचान प्रदर्शन के सांख्यिकीय मूल्यांकन का स्थान नहीं लेता।

IX. विकास और पूर्वव्यापी

v1(repository) बाह्य संकेत के साथ LLM attention आवंटित करने की समस्या पर केंद्रित था, और वास्तविक v1-सहायता प्राप्त अनुसंधान में [CVE

टूल डाउनलोड करें