GitHub-ന്റെ CodeQL 2.26.0 പതിപ്പ് AI prompt-injection പാറ്റേണുകൾ തിരിച്ചറിയുന്നതിനുള്ള ഒരു ഇൻബിൽറ്റ് ക്വറി (built-in query) ഉൾപ്പെടുത്തിയിരിക്കുന്നു, ഈ മാറ്റം നിലവിൽ തന്നെ CI പൈപ്പ്‌ലൈനുകളിൽ പുതിയ റിസ്കുകൾ ഫ്ലാഗ് ചെയ്യാൻ തുടങ്ങിയിട്ടുണ്ട്. വെറുമൊരു അപ്‌ഗ്രേഡ് മാത്രം മതിയാകില്ല—കോഡ് മാറുന്നതിനനുസരിച്ച് ഈ റൂൾ ഫലപ്രദമായി തുടരുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ ടീമുകൾക്ക് ഒരു റീഗ്രഷൻ ടെസ്റ്റ് സ്യൂട്ട് (regression test suite) ആവശ്യമാണ്.

ഒരു റീഗ്രഷൻ ഫിക്സ്ചർ (regression fixture) പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്?

പ്രോംപ്റ്റ് ഇൻജക്ഷൻ (Prompt injection) വഴി ഒരു അറ്റാക്കർക്ക് ഒരു പ്രോംപ്റ്റിലേക്ക് ദോഷകരമായ നിർദ്ദേശങ്ങൾ കടത്തിവിടാൻ സാധിക്കും. പുതിയ ക്വറി ഉപയോഗിച്ച്, സ്റ്റാറ്റിക് അനാലിസിസിന് (static analysis) ഒരു അൺട്രസ്റ്റഡ് സോഴ്സിൽ (untrusted source) നിന്നുള്ള ഡാറ്റ ഒരു മോഡൽ-കോളിംഗ് സിങ്കിലേക്ക് (model-calling sink) എത്തുന്ന പാത ട്രാസ്സ് ചെയ്യാൻ കഴിയും. ഈ റൂൾ വെറുതെ ഓൺ ചെയ്യുകയും പിന്നീട് ഒരിക്കലും പരിശോധിക്കാതിരിക്കുകയും ചെയ്താൽ, ഭാവിയിലെ ഒരു കോഡ് റീഫാക്ടറിംഗ് (refactor) ഡാറ്റാ-ഫ്ലോ പാത്തിനെ തകർക്കുകയും അലേർട്ട് നിശബ്ദമായി അപ്രത്യക്ഷമാവുകയും ചെയ്തേക്കാം. ഒരു റീഗ്രഷൻ ഫിക്സ്ചർ, റൂൾ പ്രവർത്തിക്കേണ്ട (അല്ലെങ്കിൽ പ്രവർത്തിക്കാതിരിക്കേണ്ട) കൃത്യമായ പാത്തുകൾ രേഖപ്പെടുത്തുന്നു, ഇത് സ്റ്റാറ്റിക്-അനാലിസിസ് ഫലത്തെ ബിൽഡ് ഉറപ്പുവരുത്തുന്ന ഒരു കരാറായി (contract) മാറ്റുന്നു.

വിശ്വസനീയമായ ഒരു ഫിക്സ്ചറിന് ആവശ്യമായ മൂന്ന് ഘടകങ്ങൾ

  1. Untrusted source – വിശ്വസനീയമായ കോഡ് ബേസിന് പുറത്തുനിന്നുള്ള ഡാറ്റ കൊണ്ടുവരുന്ന ഏതൊരു ഫംഗ്ഷനും (ഉദാഹരണത്തിന്, ഒരു GitHub issue body, ഒരു webhook payload).
  2. Prompt construction – മോഡൽ റിക്വസ്റ്റ് തയ്യാറാക്കുന്ന കോഡ്, സാധാരണയായി ഒരു ക്ലയന്റ് SDK-യിലേക്കുള്ള കോൾ.
  3. Model sink – പ്രോംപ്റ്റ് മോഡലിലേക്ക് അയക്കുന്ന SDK മെത്തേഡ്. സിങ്ക് (sink) തിരിച്ചറിയാൻ CodeQL-ന്റെ ഡാറ്റാ-ഫ്ലോ എൻജിന് നിങ്ങളുടെ പ്രൊഡക്ഷൻ സ്റ്റാക്കിൽ നിന്നുള്ള യഥാർത്ഥ കോൾ കാണേണ്ടതുണ്ട്.

ഈ മൂന്ന് ഘടകങ്ങളും ഒത്തുചേരുമ്പോൾ മാത്രമേ ക്വറി പ്രവർത്തിക്കുകയുള്ളൂ.

ടെസ്റ്റ് ഫയലുകൾ ക്രമീകരിക്കുന്നത് എങ്ങനെ

ഓഡിറ്റ് ചെയ്യാൻ എളുപ്പമുള്ള ഒരു രീതി താഴെ നൽകുന്നു:

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

Positive ഫയലുകളിൽ ഫ്ലാഗ് ചെയ്യപ്പെടേണ്ട കോഡുകൾ അടങ്ങിയിരിക്കുന്നു; negative ഫയലുകളിൽ ഫ്ലാഗ് ചെയ്യപ്പെടാൻ പാടില്ലാത്ത സുരക്ഷിതമായ പാറ്റേണുകൾ അടങ്ങിയിരിക്കുന്നു.

പോസിറ്റീവ് കേസുകൾ (Positive cases) എഴുതുന്നത് എങ്ങനെ

ഒരു അൺട്രസ്റ്റഡ് വാല്യൂവിൽ നിന്ന് മോഡൽ കോളിലേക്കുള്ള നേരിട്ടുള്ള ഫ്ലോ കാണിക്കുന്ന ലളിതമായ ഉദാഹരണം ഇതാ:

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 എന്നത് അൺട്രസ്റ്റഡ് സോഴ്സും, model.generate എന്നത് സിങ്കും (sink) ആണ്. ഡാറ്റ യാതൊരു സാനിറ്റൈസേഷൻ (sanitisation) ഘട്ടവും കൂടാതെ കടന്നുപോകുന്നു—ക്വറി കണ്ടെത്താൻ ഉദ്ദേശിക്കുന്നത് ഇതാണ്.

രണ്ടാമത്തെ പോസിറ്റീവ് കേസ് ഡാറ്റയെ ഒരു ഹെൽപ്പർ ഫംഗ്ഷനിലൂടെ കടത്തിവിടണം, ഇത് അനാലിസിസ് ഇൻഡയറക്ട് പാത്തുകളെ (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) എഴുതുന്നത് എങ്ങനെ

യൂസർ ഇൻപുട്ടിന് മോഡലിന്റെ നിർദ്ദേശങ്ങളിൽ മാറ്റം വരുത്താൻ കഴിയില്ലെന്ന് നെഗറ്റീവ് ഫിക്സ്ചർ തെളിയിക്കണം. sanitize() എന്ന് വിളിക്കുന്ന ഒരു ഫംഗ്ഷൻ സുരക്ഷ ഉറപ്പാക്കുന്നു എന്ന് കരുതുന്നത് ഒരു സാധാരണ തെറ്റാണ്. സ്റ്റാറ്റിക് അനലൈസർ ആ പേരിനെ ഒരു തെളിവായി കണക്കാക്കുന്നില്ല, അതിനാൽ ടെസ്റ്റിൽ തെറ്റായ രീതിയിലുള്ള സാനിറ്റൈസേഷൻ സ്റ്റബ് (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 ഫീൽഡിൽ എത്തുന്നില്ലാത്തതിനാൽ, റൂൾ പ്രവർത്തിക്കരുത് (stay quiet).

JSON-ൽ പ്രതീക്ഷിച്ച ഫലങ്ങൾ (expectations) പ്രഖ്യാപിക്കുന്നത് എങ്ങനെ

സ്യൂട്ടിന്റെ കരാർ (contract) expected-alerts.json-ൽ ആണ് സൂക്ഷിക്കുന്നത്. ഇത് ആവശ്യമായ അലേർട്ടുകളും പാടില്ലാത്ത പാത്തുകളും വ്യക്തമായി രേഖപ്പെടുത്തുന്നു:

{
  "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 ഔട്ട്പുട്ടിലോ കാണിച്ചിരിക്കുന്ന ഐഡന്റിഫയർ നൽകുക. ഐഡികൾ ഊഹിച്ചു നൽകരുത്; CI ചെക്കിനായി കൃത്യമായ സ്ട്രിംഗ് തന്നെ ആവശ്യമാണ്.

ഫിക്സ്ചറിനെ CI-യുമായി ബന്ധിപ്പിക്കുന്നത് എങ്ങനെ

  1. പൈപ്പ്‌ലൈനിൽ ഉപയോഗിക്കുന്ന CodeQL CLI വേർഷൻ 2.26.0-ലേക്കോ അതിനു ശേഷമോ ഉള്ള വേർഷനിലേക്കോ മാറ്റുക (Pin).
  2. ഫിക്സ്ചർ റൺ ചെയ്യുന്നതിന് മുമ്പ് നിലവിലുള്ള കോഡിൽ നിന്ന് ഒരു ഡിസ്പോസബിൾ ഡാറ്റാബേസ് നിർമ്മിക്കുക.
  3. ക്വറി റൺ ചെയ്യുക, അലേർട്ടുകൾ ശേഖരിക്കുക, അവ expected-alerts.json-മായി താരതമ്യം ചെയ്യുക.
  4. ആവശ്യമായ ഏതെങ്കിലും അലേർട്ട് കാണുന്നില്ലെങ്കിലോ, പാടില്ലാത്ത പാത്തുകൾ അലേർട്ട് ചെയ്യുന്നുണ്ടെങ്കിലോ ബിൽഡ് പരാജയപ്പെടുത്തുക (Fail the build).

റെപ്പോസിറ്ററിയിലുടനീളമുള്ള ആകെ അലേർട്ട് എണ്ണം പരിശോധിക്കരുത്—അപ്രസക്തമായ മാറ്റങ്ങൾ എണ്ണത്തിൽ വ്യത്യാസം വരുത്തുകയും തെറ്റായ ഫെയിലറുകൾക്ക് (false failures) കാരണമാവുകയും ചെയ്തേക്കാം.

അപ്‌ഗ്രേഡിന് ശേഷം ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

നിങ്ങൾ CodeQL പുതിയ വേർഷനിലേക്ക് മാറ്റുമ്പോൾ:

  • ആവശ്യമായ അലേർട്ട് ഇപ്പോഴും കാണുന്നു – സാധാരണ റിവ്യൂ രീതിയിൽ മുന്നോട്ട് പോകുക.
  • ആവശ്യമായ അലേർട്ട് കാണുന്നില്ല – ബിൽഡ് തടയുക; പുതിയ വേർഷൻ ക്വറി ലോജിക് മാറ്റിയിട്ടുണ്ടോ അതോ കോഡ് മാറ്റം ഡാറ്റാ ഫ്ലോയെ ബാധിച്ചോ എന്ന് പരിശോധിക്കുക.
  • പുതിയ പോസിറ്റീവ് ലൊക്കേഷൻ കാണുന്നു – അത് യഥാർത്ഥ ഇൻജക്ഷൻ പാത്ത് ആണെന്ന് ഉറപ്പുവരുത്തിയ ശേഷം required ലിസ്റ്റിൽ ചേർക്കുക.
  • നെഗറ്റീവ് കൺട്രോൾ അലേർട്ട് ചെയ്യുന്നു – മിറ്റിഗേഷൻ സ്ട്രാറ്റജി (mitigation strategy) വീണ്ടും പരിശോധിക്കുക; റൂൾ കൂടുതൽ കർശനമായേക്കാം.

റൺടൈമിൽ മോഡൽ എങ്ങനെ പ്രതികരിക്കുമെന്ന് സ്റ്റാറ്റിക് അനാലിസിസിന് തെളിയിക്കാൻ കഴിയില്ല. മോഡലിലേക്ക് കൃത്രിമമായി നിർമ്മിച്ച പ്രോംപ്റ്റുകൾ അയച്ച് അതിന്റെ പ്രതികരണം പരിശോധിക്കുന്ന അഡ്വേഴ്സേറിയൽ ടെസ്റ്റുകൾ (adversarial tests) ഉപയോഗിച്ച് റീഗ്രഷൻ സ്യൂട്ടിനെ കൂടുതൽ ശക്തമാക്കുക.

ചുരുക്കത്തിൽ

പ്രോംപ്റ്റ്-ഇൻജക്ഷൻ ബഗുകൾ ഷിപ്പ് ചെയ്യുന്നതിന് മുമ്പ് തന്നെ കണ്ടെത്താൻ CodeQL 2.26.0 നിങ്ങൾക്ക് അവസരം നൽകുന്നു, എന്നാൽ ഒരു ഫോക്കസ്ഡ് റീഗ്രഷൻ ഫിക്സ്ചർ ഉപയോഗിച്ച് ആ കഴിവ് ഉറപ്പുവരുത്തിയാൽ മാത്രമേ ഇത് സാധ്യമാകൂ. അൺട്രസ്റ്റഡ് സോഴ്സുകൾ, യഥാർത്ഥ SDK സിങ്കുകൾ, JSON കരാറിലെ വ്യക്തമായ പ്രതീക്ഷകൾ എന്നിവ നിർവചിക്കുന്നതിലൂടെ, ഒരു സ്റ്റാറ്റിക്-അനാലിസിസ് റൂളിനെ റീഗ്രഷനുകളെ തടയുന്നതിനും മാറിക്കൊണ്ടിരിക്കുന്ന അറ്റാക്ക് സർഫസിനെതിരെ (attack surface) നിരന്തരം ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നതിനും സഹായിക്കുന്ന ഒരു ഗേറ്റായി നിങ്ങൾക്ക് മാറ്റാൻ കഴിയും.