GitHub ના CodeQL 2.26.0 માં એક ઇન-બિલ્ટ ક્વેરી ઉમેરવામાં આવી છે જે AI prompt-injection પેટર્નને ઓળખે છે, અને આ ફેરફારને કારણે CI પાઇપલાઇન્સ નવા જોખમોને ફ્લેગ કરવાનું શરૂ કરી દીધું છે. માત્ર અપગ્રેડ પૂરતું નથી—ટીમોને એવા રિગ્રેસન ટેસ્ટ સ્યુટની જરૂર છે જે ખાતરી આપે કે કોડ વિકસિત થવાની સાથે નિયમ અસરકારક રહે.

રિગ્રેસન ફિક્સ્ચર (regression fixture) શા માટે મહત્વનું છે

Prompt injection દ્વારા હુમલાખોર પ્રોમ્પ્ટમાં નુકસાનકારક સૂચનાઓ ઉમેરી શકે છે જે લેંગ્વેજ મોડેલ પાછળથી અનુસરે છે. નવી ક્વેરી સાથે, સ્ટેટિક એનાલિસિસ અવિશ્વસનીય સ્ત્રોત (untrusted source) થી મોડેલ-કોલિંગ સિંક (model-calling sink) સુધીના ડેટાને ટ્રેસ કરી શકે છે. જો નિયમ ફક્ત ચાલુ કરવામાં આવે અને ક્યારેય ચકાસવામાં ન આવે, તો પછીનું રિફેક્ટર ડેટા-ફ્લો પાથને તોડી શકે છે અને એલર્ટ શાંતિથી અદૃશ્ય થઈ શકે છે. રિગ્રેસન ફિક્સ્ચર એવા ચોક્કસ પાથને કેપ્ચર કરે છે જે નિયમને ટ્રિગર કરવા જોઈએ (અથવા ન કરવા જોઈએ), જેનાથી સ્ટેટિક-એનાલિસિસના પરિણામને એક કરાર (contract) માં ફેરવી શકાય છે જેને બિલ્ડ અમલમાં મૂકે છે.

વિશ્વસનીય ફિક્સ્ચરના ત્રણ ઘટકો

  1. Untrusted source – કોઈપણ ફંક્શન જે વિશ્વાસપાત્ર કોડ બેઝની બહારથી ડેટા લાવે છે (દા.ત., GitHub issue body, a webhook payload).
  2. Prompt construction – મોડેલ રિક્વેસ્ટ તૈયાર કરતો કોડ, જે સામાન્ય રીતે ક્લાયન્ટ SDK નો કોલ હોય છે.
  3. Model sink – SDK મેથડ જે પ્રોમ્પ્ટને મોડેલ પર મોકલે છે. CodeQL ના ડેટા-ફ્લો એન્જિનને સિંકને ઓળખવા માટે તમારા પ્રોડક્શન સ્ટેકમાંથી વાસ્તવિક કોલ જોવાની જરૂર છે.

જ્યારે આ ત્રણેય હાજર હોય ત્યારે જ ક્વેરી ફાયર થાય છે.

ટેસ્ટ ફાઇલોનું આયોજન

પરંપરાગત લેઆઉટ સ્યુટને ઓડિટ કરવામાં સરળ રાખે છે:

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

Positive ફાઇલોમાં એવો કોડ હોય છે જેને ફ્લેગ (flag) થવો જોઈએ; 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 એ સિંક છે, અને ડેટા કોઈપણ સેનિટાઇઝેશન સ્ટેપ વગર પસાર થાય છે—જે બરાબર ક્વેરી પકડવા માટે ડિઝાઇન કરવામાં આવી છે.

બીજો પોઝિટિવ કેસ ડેટાને હેલ્પર ફંક્શન દ્વારા રૂટ કરવો જોઈએ, જે સાબિત કરે છે કે એનાલિસિસ પરોક્ષ પાથને અનુસરે છે:

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 ફિલ્ડ સુધી પહોંચતો નથી, તેથી નિયમ શાંત રહેવો જોઈએ.

JSON માં અપેક્ષાઓ જાહેર કરવી

સ્યુટનો કરાર 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 (અથવા તેનાથી વધુ) પર પિન કરો.
  2. ફિક્સ્ચર ચલાવતા પહેલા વર્તમાન ચેકઆઉટમાંથી ડિસ્પોઝેબલ ડેટાબેઝ બનાવો.
  3. ક્વેરી ચલાવો, એલર્ટ્સ કેપ્ચર કરો અને તેની સરખામણી expected-alerts.json સાથે કરો.
  4. જો કોઈ જરૂરી એલર્ટ અદૃશ્ય થઈ જાય અથવા જો કોઈ પ્રતિબંધિત પાથ એલર્ટ કરવા લાગે, તો બિલ્ડ ફેલ કરો.

રિપોઝિટરીમાં કુલ એલર્ટ કાઉન્ટનો આશ્વાસન (assert) ન કરો—અસંબંધિત ફેરફારો સંખ્યા વધારી શકે છે અને ખોટા ફેલ્યોર (false failures) નું કારણ બની શકે છે.

અપગ્રેડ પછી શું ધ્યાન રાખવું

જ્યારે તમે CodeQL ને નવા વર્ઝન પર અપગ્રેડ કરો છો:

  • જરૂરી એલર્ટ હજુ પણ દેખાય છે – સામાન્ય રિવ્યુ સાથે આગળ વધો.
  • જરૂરી એલર્ટ અદૃશ્ય થઈ જાય છે – બિલ્ડ બ્લોક કરો; તપાસો કે નવા વર્ઝને ક્વેરી લોજિક બદલ્યું છે કે કોડ ફેરફારથી ડેટા ફ્લો તૂટી ગયો છે.
  • નવું પોઝિટિવ લોકેશન દેખાય છે – તે સાચો ઇન્જેક્શન પાથ છે તેની ખાતરી કર્યા પછી તેને required લિસ્ટમાં ઉમેરો.
  • નેગેટિવ કંટ્રોલ એલર્ટ કરવા લાગે છે – મિટિગેશન વ્યૂહરચનાની ફરી તપાસ કરો; નિયમ વધુ કડક બની ગયો હોઈ શકે છે.

સ્ટેટિક એનાલિસિસ રનટાઇમ પર મોડેલ કેવી રીતે પ્રતિક્રિયા આપશે તે સાબિત કરી શકતું નથી. રિગ્રેસન સ્યુટને એડવર્સરીયલ ટેસ્ટ્સ (adversarial tests) સાથે પૂરક બનાવો જે ખરેખર મોડેલને તૈયાર કરેલા પ્રોમ્પ્ટ્સ મોકલે છે અને પ્રતિસાદની ચકાસણી કરે છે.

સારાંશ

CodeQL 2.26.0 તમને પ્રોમ્પ્ટ-ઇન્જેક્શન બગ્સ શિપ થાય તે પહેલાં પકડવાની ક્ષમતા આપે છે, પરંતુ ફક્ત ત્યારે જ જો તમે તે ક્ષમતાને ફોકસ કરેલા રિગ્રેસન ફિક્સ્ચર સાથે લોક કરો. અવિશ્વસનીય સ્ત્રોતો, વાસ્તવિક SDK સિંક્સ અને JSON કરારમાં સ્પષ્ટ અપેક્ષાઓ વ્યાખ્યાયિત કરીને, તમે સ્ટેટિક-એનાલિસિસ નિયમને એક ગેટમાં ફેરવી શકો છો જે રિગ્રેસન્સને અટકાવે છે અને ઝડપથી વિકસતા એટેક સરફેસ પર સતત ધ્યાન કેન્દ્રિત કરવા માટે મજબૂર કરે છે.