CodeQL 2.26.0 Adds Prompt-Injection Query – Build a CI Regression Fixture to Guard It

GitHub-ன் CodeQL 2.26.0, AI prompt-injection முறைகளைக் கண்டறியும் ஒரு built-in query-ஐச் சேர்த்துள்ளது, மேலும் இந்த மாற்றம் ஏற்கனவே CI pipelines-களில் புதிய அபாயங்களைக் (risks) சுட்டிக்காட்டத் தொடங்கியுள்ளது. வெறும் upgrade மட்டும் போதுமானதல்ல—குறியீடு (code) மாறும்போது அந்த விதி (rule) தொடர்ந்து பயனுள்ளதாக இருப்பதை உறுதி செய்ய, குழுக்களுக்கு ஒரு regression test suite தேவைப்படுகிறது.

ஒரு regression fixture ஏன் முக்கியமானது

Prompt injection மூலம் ஒரு தாக்குதலாளி (attacker), ஒரு மொழி மாதிரி (language model) பின்னர் பின்பற்றும் தீய வழிமுறைகளை (malicious instructions) ஒரு prompt-க்குள் நுழையச் செய்யலாம். புதிய query மூலம், static analysis மூலம் நம்பகமற்ற மூலத்திலிருந்து (untrusted source) ஒரு model-calling sink வரை தரவை (data) கண்காணிக்க முடியும். இந்த விதியை (rule) வெறும் ஆன் (on) செய்துவிட்டு ஒருபோதும் சரிபார்க்கவில்லை என்றால், பிற்காலத்தில் செய்யப்படும் ஒரு refactor, தரவுப் பாதையை (data-flow path) உடைத்துவிடக்கூடும், இதனால் எச்சரிக்கை (alert) அமைதியாக மறைந்துவிடும். ஒரு regression fixture, விதியைத் தூண்ட வேண்டிய (அல்லது தூண்டக் கூடாத) துல்லியமான பாதைகளைப் பதிவு செய்து, static-analysis முடிவை build உறுதிப்படுத்தும் ஒரு ஒப்பந்தமாக (contract) மாற்றுகிறது.

ஒரு நம்பகமான fixture-க்கான மூன்று கூறுகள்

1. Untrusted source – நம்பகமான code base-க்கு வெளியே இருந்து தரவைக் கொண்டு வரும் எந்தவொரு function-ம் (எ.கா., ஒரு GitHub issue body, ஒரு webhook payload).
2. Prompt construction – model request-ஐத் தொகுக்கும் குறியீடு, இது பொதுவாக ஒரு client SDK-க்கான அழைப்பாக இருக்கும்.
3. Model sink – prompt-ஐ model-க்கு அனுப்பும் SDK method. CodeQL-ன் data-flow engine உங்கள் production stack-லிருந்து ஒரு உண்மையான அழைப்பைக் (real call) காண வேண்டும் அப்போதுதான் sink-ஐ அடையாளம் காண முடியும்.

இந்த மூன்றும் இருக்கும்போது மட்டுமே query செயல்படும்.

சோதனை கோப்புகளை (test files) ஒழுங்கமைத்தல்

ஒரு வழக்கமான அமைப்பு (conventional layout) இந்த suite-ஐ ஆய்வு செய்ய எளிதாக்கும்:

security-fixtures/prompt-injection/
├─ positive/
│  ├─ direct-flow.ts
│  └─ helper-flow.ts
├─ negative/
│  └─ trusted-instruction.ts
└─ expected-alerts.json

Positive கோப்புகள் எச்சரிக்கப்பட வேண்டிய (flagged) குறியீட்டைக் கொண்டிருக்கும்; negative கோப்புகள் அமைதியாக இருக்க வேண்டிய பாதுகாப்பான முறைகளைக் (safe patterns) கொண்டிருக்கும்.

positive cases எழுதுதல்

மிக எளிமையான உதாரணம், ஒரு நம்பகமற்ற மதிப்பிலிருந்து (untrusted value) model call-க்குச் செல்லும் நேரடிப் பாதையைக் காட்டுகிறது:

import { model } from "./supported-client";

declare function loadIssueBody(id: number): Promise<string>;

export async function summarize(id: number) {
  const untrusted = await loadIssueBody(id);
  return model.generate({
    system: "Summarize the issue",
    user: untrusted,
  });
}

இங்கு loadIssueBody என்பது நம்பகமற்ற மூலம் (untrusted source), model.generate என்பது sink ஆகும், மேலும் தரவு எந்தவித sanitisation படிநிலையும் இன்றிச் செல்கிறது—இதுதான் query கண்டறிய வடிவமைக்கப்பட்டுள்ளது.

இரண்டாவது positive case, தரவை ஒரு helper function வழியாக வழிநடத்த வேண்டும், இதன் மூலம் பகுப்பாய்வு (analysis) மறைமுகப் பாதைகளையும் (indirect paths) பின்தொடர்கிறது என்பதை நிரூபிக்கலாம்:

function wrapUserInput(input: string) {
  return { system: "Summarize the issue", user: input };
}

export async function summarizeViaHelper(id: number) {
  const raw = await loadIssueBody(id);
  return model.generate(wrapUserInput(raw));
}

இரண்டு கோப்புகளும் positive/ என்பதன் கீழ் இருக்க வேண்டும்.

negative case எழுதுதல்

பயனர் உள்ளீடு (user input) model-ன் வழிமுறையை மாற்ற முடியாது என்பதை negative fixture நிரூபிக்க வேண்டும். sanitize() என்று அழைக்கப்படும் ஒரு function பாதுகாப்பை உறுதி செய்யும் என்று கருதுவது ஒரு பொதுவான தவறு. static analyzer அந்தப் பெயரை ஒரு ஆதாரமாக (proof) எடுத்துக்கொள்ளாது, எனவே சோதனை எந்தவொரு தவறான misleading sanitisation stub-ஐயும் தவிர்க்க வேண்டும்:

export async function safeSummarize(id: number) {
  const trusted = "Summarize the issue";
  const user = await loadIssueBody(id); // not used in the system prompt
  return model.generate({
    system: trusted,
    user: "Static placeholder",
  });
}

நம்பகமற்ற தரவு system புலத்தை (field) ஒருபோதும் சென்றடையாததால், விதி அமைதியாக இருக்க வேண்டும்.

JSON-இல் எதிர்பார்ப்புகளைத் (expectations) declare செய்தல்

இந்த suite-ன் ஒப்பந்தம் (contract) expected-alerts.json-இல் உள்ளது. இது தேவையான எச்சரிக்கைகளையும் (required alerts), வெளிப்படையாகத் தடைசெய்யப்பட்ட பாதைகளையும் (forbidden paths) பட்டியலிடுகிறது:

{
  "required": [
    {
      "ruleId": "USE_ACTUAL_RULE_ID",
      "pathSuffix": "positive/direct-flow.ts"
    },
    {
      "ruleId": "USE_ACTUAL_RULE_ID",
      "pathSuffix": "positive/helper-flow.ts"
    }
  ],
  "forbiddenPathSuffixes": [
    "negative/trusted-instruction.ts"
  ]
}

USE_ACTUAL_RULE_ID-க்கு பதிலாக CodeQL ஆவணங்கள் அல்லது SARIF output-இல் காட்டப்பட்டுள்ள அடையாளங்காட்டியைக் (identifier) குறிப்பிடவும். ID-களைக் கணிக்க வேண்டாம்; CI check-க்கு துல்லியமான string மிக முக்கியம்.

fixture-ஐ CI-உடன் இணைத்தல் (Hooking)

1. pipeline-இல் பயன்படுத்தப்படும் CodeQL CLI பதிப்பை 2.26.0 (அல்லது அதற்குப் பிந்தைய பதிப்பிற்கு) நிலைநிறுத்தவும் (Pin).
2. fixture-ஐ இயக்குவதற்கு முன், தற்போதைய checkout-லிருந்து ஒரு தற்காலிகத் தரவுத்தளத்தை (disposable database) உருவாக்கவும்.
3. query-ஐ இயக்கி, எச்சரிக்கைகளைப் பெற்று, அவற்றை expected-alerts.json-உடன் ஒப்பிடவும்.
4. ஏதேனும் தேவையான எச்சரிக்கை மறைந்தாலோ அல்லது தடைசெய்யப்பட்ட பாதை எச்சரிக்கையைத் தூண்டினாலோ, build-ஐத் தோல்வியடையச் செய்யவும் (Fail).

முழு repository-க்கும் மொத்த எச்சரிக்கை எண்ணிக்கையை (total alert count) உறுதிப்படுத்த வேண்டாம்—தொடர்பற்ற மாற்றங்கள் எண்ணிக்கையை அதிகரித்து தவறான தோல்விகளுக்கு (false failures) வழிவகுக்கலாம்.

upgrade செய்த பிறகு கவனிக்க வேண்டியவை

நீங்கள் CodeQL-ஐ புதிய பதிப்பிற்கு upgrade செய்யும்போது:

• தேவையான எச்சரிக்கை இன்னும் தோன்றினால் – வழக்கமான ஆய்வைத் தொடரவும்.
• தேவையான எச்சரிக்கை மறைந்துவிட்டால் – build-ஐத் தடுக்கவும்; புதிய பதிப்பு query logic-ஐ மாற்றியதா அல்லது குறியீடு மாற்றம் data flow-ஐ உடைத்ததா என்பதை ஆராயவும்.
• புதிய positive இடம் தோன்றினால் – அது உண்மையான injection பாதை என்பதை உறுதிப்படுத்திய பிறகு, அதை required பட்டியலில் சேர்க்கவும்.
• Negative control எச்சரிக்கையைத் தூண்டத் தொடங்கினால் – mitigation strategy-ஐ மீண்டும் சரிபார்க்கவும்; விதி இன்னும் கடுமையாக்கப்படலாம்.

runtime-இல் மாதிரி (model) எவ்வாறு வினைபுரியும் என்பதை static analysis-ஆல் நிரூபிக்க முடியாது. மாதிரிக்குத் திட்டமிடப்பட்ட prompts-களை (crafted prompts) அனுப்பி, அதன் பதிலைச் சரிபார்க்கும் adversarial tests மூலம் regression suite-ஐ முழுமையடையச் செய்யவும்.

சுருக்கம் (Takeaway)

CodeQL 2.26.0, prompt-injection பிழைகளை அவை பயன்பாட்டிற்கு வரும் முன்பே கண்டறியும் திறனை உங்களுக்கு வழங்குகிறது, ஆனால் ஒரு முறையான regression fixture மூலம் அந்தத் திறனை நீங்கள் உறுதிப்படுத்தினால் மட்டுமே இது சாத்தியம். நம்பகமற்ற மூலங்கள் (untrusted sources), உண்மையான SDK sinks மற்றும் JSON ஒப்பந்தத்தில் தெளிவான எதிர்பார்ப்புகளை வரையறுப்பதன் மூலம், நீங்கள் ஒரு static-analysis விதியை, regression-களைத் தடுக்கும் மற்றும் வேகமாக மாறிவரும் attack surface-ன் மீது தொடர்ச்சியான கவனத்தைச் செலுத்தும் ஒரு நுழைவாயிலாக (gate) மாற்றுகிறீர்கள்.