GitHub ਦੇ CodeQL 2.26.0 ਵਿੱਚ ਇੱਕ built-in query ਜੋੜੀ ਗਈ ਹੈ ਜੋ AI prompt-injection patterns ਦੀ ਪਛਾਣ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਸ ਬਦਲਾਅ ਕਾਰਨ CI pipelines ਪਹਿਲਾਂ ਹੀ ਨਵੇਂ ਜੋਖਮਾਂ (risks) ਨੂੰ ਫਲੈਗ ਕਰ ਰਹੀਆਂ ਹਨ। ਸਿਰਫ਼ ਅੱਪਗ੍ਰੇਡ ਕਰਨਾ ਹੀ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ—ਟੀਮਾਂ ਨੂੰ ਇੱਕ regression test suite ਦੀ ਲੋੜ ਹੈ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਏ ਕਿ ਕੋਡ ਦੇ ਵਿਕਸਿਤ ਹੋਣ ਦੇ ਨਾਲ-ਨਾਲ ਇਹ ਨਿਯਮ (rule) ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣਿਆ ਰਹੇ।

ਇੱਕ regression fixture ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

Prompt injection ਇੱਕ ਹਮਲਾਵਰ ਨੂੰ ਅਜਿਹੀਆਂ ਮਾਲੀਸ਼ੀਅਸ (malicious) ਹਦਾਇਤਾਂ ਨੂੰ prompt ਵਿੱਚ ਲੁਕਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਪਾਲਣਾ ਲੈਂਗੂਏਜ ਮਾਡਲ ਬਾਅਦ ਵਿੱਚ ਕਰਦਾ ਹੈ। ਨਵੀਂ query ਦੇ ਨਾਲ, static analysis ਅਣਭਰੋਸੇਯੋਗ ਸਰੋਤ (untrusted source) ਤੋਂ ਮਾਡਲ-ਕਾਲਿੰਗ sink ਤੱਕ ਡੇਟਾ ਦਾ ਪਤਾ ਲਗਾ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਨਿਯਮ ਨੂੰ ਸਿਰਫ਼ ਚਾਲੂ ਕਰ ਦਿੱਤਾ ਜਾਵੇ ਅਤੇ ਕਦੇ ਵੀ ਵੈਰੀਫਾਈ ਨਾ ਕੀਤਾ ਜਾਵੇ, ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਕੋਡ ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਕੋਈ ਵੀ refactor data-flow path ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ ਅਤੇ ਅਲਰਟ ਚੁੱਪਚਾਪ ਗਾਇਬ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ regression fixture ਉਹਨਾਂ ਸਹੀ ਪਾਥਾਂ (paths) ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ ਜੋ ਨਿਯਮ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ (ਜਾਂ ਨਹੀਂ ਕਰਨੇ ਚਾਹੀਦੇ), ਜਿਸ ਨਾਲ static-analysis ਦੇ ਨਤੀਜੇ ਨੂੰ ਇੱਕ ਅਜਿਹੇ ਕੰਟਰੈਕਟ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜਿਸ ਨੂੰ build ਲਾਗੂ ਕਰਦਾ ਹੈ।

ਇੱਕ ਭਰੋਸੇਯੋਗ fixture ਦੇ ਤਿੰਨ ਤੱਤ

  1. Untrusted source – ਕੋਈ ਵੀ ਫੰਕਸ਼ਨ ਜੋ ਭਰੋਸੇਯੋਗ code base ਤੋਂ ਬਾਹਰੋਂ ਡੇਟਾ ਲਿਆਉਂਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ, ਇੱਕ GitHub issue body, ਇੱਕ webhook payload)।
  2. Prompt construction – ਉਹ ਕੋਡ ਜੋ ਮਾਡਲ ਰਿਕਵੈਸਟ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ client SDK ਨੂੰ ਕੀਤੀ ਗਈ ਕਾਲ।
  3. Model sink – ਉਹ SDK method ਜੋ prompt ਨੂੰ ਮਾਡਲ ਨੂੰ ਭੇਜਦਾ ਹੈ। CodeQL ਦੇ data-flow engine ਨੂੰ sink ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਤੁਹਾਡੇ production stack ਤੋਂ ਇੱਕ ਅਸਲੀ ਕਾਲ ਦੇਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਜਦੋਂ ਇਹ ਤਿੰਨੋਂ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ, ਉਦੋਂ ਹੀ query ਚੱਲਦੀ ਹੈ।

ਟੈਸਟ ਫਾਈਲਾਂ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨਾ

ਇੱਕ ਰਵਾਇਤੀ ਲੇਆਉਟ (layout) suite ਨੂੰ ਆਡਿਟ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ:

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

Positive ਫਾਈਲਾਂ ਵਿੱਚ ਉਹ ਕੋਡ ਹੁੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਫਲੈਗ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ; negative ਫਾਈਲਾਂ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਪੈਟਰਨ ਹੁੰਦੇ ਹਨ ਜੋ ਚੁੱਪ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ।

Positive cases ਲਿਖਣਾ

ਸਭ ਤੋਂ ਸਧਾਰਨ ਉਦਾਹਰਣ ਇੱਕ ਅਣਭਰੋਸੇਯੋਗ ਮੁੱਲ (untrusted value) ਤੋਂ ਮਾਡਲ ਕਾਲ ਤੱਕ ਸਿੱਧਾ ਫਲੋਅ ਦਿਖਾਉਂਦੀ ਹੈ:

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 ਸਟੈਪ ਦੇ ਲੰਘ ਜਾਂਦਾ ਹੈ—ਬਿਲਕੁਲ ਉਹੀ ਜਿਸ ਨੂੰ ਫੜਨ ਲਈ 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 ਲਿਖਣਾ

Negative fixture ਨੂੰ ਇਹ ਸਾਬਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਯੂਜ਼ਰ ਇਨਪੁਟ ਮਾਡਲ ਦੀ ਹਦਾਇਤ ਨੂੰ ਬਦਲ ਨਹੀਂ ਸਕਦਾ। ਇੱਕ ਆਮ ਗਲਤੀ ਇਹ ਮੰਨਣਾ ਹੈ ਕਿ sanitize() ਨਾਮ ਦਾ ਫੰਕਸ਼ਨ ਸੁਰੱਖਿਆ ਦੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ। Static analyzer ਨਾਮ ਨੂੰ ਸਬੂਤ ਵਜੋਂ ਨਹੀਂ ਮੰਨਦਾ, ਇਸ ਲਈ ਟੈਸਟ ਨੂੰ ਕਿਸੇ ਵੀ ਗੁੰਮਰਾਹਕੁੰਨ 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 ਵਿੱਚ ਉਮੀਦਾਂ (expectations) ਘੋਸ਼ਿਤ ਕਰਨਾ

Suite ਦਾ ਕੰਟਰੈਕਟ 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 ਆਉਟਪੁੱਟ ਵਿੱਚ ਦਿਖਾਏ ਗਏ identifier ਨਾਲ ਬਦਲੋ। IDs ਦਾ ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ; CI ਚੈੱਕ ਲਈ ਸਹੀ string ਮਹੱਤਵਪੂਰਨ ਹੈ।

Fixture ਨੂੰ CI ਨਾਲ ਜੋੜਨਾ

  1. Pipeline ਵਿੱਚ ਵਰਤੀ ਗਈ CodeQL CLI version ਨੂੰ 2.26.0 (ਜਾਂ ਇਸ ਤੋਂ ਬਾਅਦ) 'ਤੇ ਪਿੰਨ (pin) ਕਰੋ।
  2. Fixture ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ checkout ਤੋਂ ਇੱਕ disposable database ਬਣਾਓ।
  3. Query ਚਲਾਓ, ਅਲਰਟਸ ਕੈਪਚਰ ਕਰੋ, ਅਤੇ ਉਹਨਾਂ ਦੀ expected-alerts.json ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
  4. ਜੇਕਰ ਕੋਈ ਲੋੜੀਂਦਾ ਅਲਰਟ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ ਜਾਂ ਜੇਕਰ ਕੋਈ ਮਨ੍ਹਾ ਕੀਤਾ ਗਿਆ ਪਾਥ ਅਲਰਟ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ build ਨੂੰ ਫੇਲ (fail) ਕਰ ਦਿਓ।

ਪੂਰੇ ਰੈਪੋਜ਼ੀਟਰੀ (repository) ਵਿੱਚ ਕੁੱਲ ਅਲਰਟ ਕਾਊਂਟ ਦਾ ਦਾਅਵਾ ਨਾ ਕਰੋ—ਗੈਰ-ਸੰਬੰਧਿਤ ਬਦਲਾਅ ਸੰਖਿਆ ਨੂੰ ਵਧਾ ਸਕਦੇ ਹਨ ਅਤੇ ਗਲਤ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੇ ਹਨ।

ਅੱਪਗ੍ਰੇਡ ਤੋਂ ਬਾਅਦ ਕੀ ਦੇਖਣਾ ਹੈ

ਜਦੋਂ ਤੁਸੀਂ CodeQL ਨੂੰ ਨਵੇਂ ਵਰਜ਼ਨ 'ਤੇ ਅੱਪਗ੍ਰੇਡ ਕਰਦੇ ਹੋ:

  • ਲੋੜੀਂਦਾ ਅਲਰਟ ਅਜੇ ਵੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ – ਆਮ ਰਿਵਿਊ ਨਾਲ ਅੱਗੇ ਵਧੋ।
  • ਲੋੜੀਂਦਾ ਅਲਰਟ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ – build ਨੂੰ ਰੋਕੋ; ਜਾਂਚ ਕਰੋ ਕਿ ਕੀ ਨਵੇਂ ਵਰਜ਼ਨ ਨੇ query logic ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਹੈ ਜਾਂ ਕੀ ਕੋਡ ਬਦਲਾਅ ਨੇ data flow ਨੂੰ ਤੋੜ ਦਿੱਤਾ ਹੈ।
  • ਨਵਾਂ positive ਸਥਾਨ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ – ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ ਕਿ ਇਹ ਇੱਕ ਅਸਲੀ injection path ਹੈ, ਇਸਨੂੰ required ਸੂਚੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ।
  • Negative control ਅਲਰਟ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ – mitigation strategy ਦੀ ਮੁੜ ਜਾਂਚ ਕਰੋ; ਨਿਯਮ ਹੋਰ ਸਖ਼ਤ ਹੋ ਗਿਆ ਹੋ ਸਕਦਾ ਹੈ।

Static analysis ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਮਾਡਲ runtime 'ਤੇ ਕਿਵੇਂ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰੇਗਾ। Regression suite ਨੂੰ adversarial