تقوية VS Code: أوقف تسرب متغيرات البيئة

معظم تسربات الأسرار داخل فرق التطوير لا تأتي من اختراقات درامية، بل من عادات يومية عادية: لصق التوكنات داخل launch.json، وترك ملفات .env قابلة للبحث داخل المحرر، ومزامنة إعدادات خاطئة، أو منح الثقة لمساحة عمل قبل فهم ما بداخلها.

1. تعامل مع Workspace Trust كحد أمني حقيقي

أسهل خطأ هو فتح مستودع غير مألوف ومنحه فورًا نفس مستوى الثقة الذي تمنحه لمشاريعك الداخلية. ميزة Workspace Trust موجودة لسبب واضح: منع المهام والإضافات وواجهات التصحيح من العمل من دون سياق.

ابدأ بإخفاء ملفات الأسرار من التصفح والبحث اليومي:

    {
  "security.workspace.trust.enabled": true,
  "security.workspace.trust.untrustedFiles": "prompt",
  "files.exclude": {
    "**/.env": true,
    "**/.env.*": true
  },
  "search.exclude": {
    "**/.env": true,
    "**/.env.*": true
  }
}

  

هذا لا يغني عن إدارة أسرار حقيقية، لكنه يزيل فئة المشاكل الناتجة عن فتح الملف الخاطئ أو نسخ القيمة الخاطئة في اللحظة الخاطئة.

2. ضع الأسرار في ملفات env لا في إعدادات التصحيح

أسوأ نمط شائع هو كتابة بيانات الاعتماد مباشرة داخل launch.json. هذا الملف سهل الالتزام، وسهل المزامنة، وسهل المشاركة. الحل الأبسط هو إبقاء الأسرار في ملف env محلي، والاكتفاء بقيم غير حساسة داخل إعدادات التصحيح:

    {
  "version": "0.2.0",
  "configurations": [
    {
      "name": "API: secure debug",
      "type": "node",
      "request": "launch",
      "program": "${workspaceFolder}/src/server.ts",
      "runtimeExecutable": "node",
      "envFile": "${workspaceFolder}/.env.local",
      "env": {
        "LOG_LEVEL": "debug"
      }
    }
  ]
}

  

بهذه الطريقة يبقى سير العمل سريعًا، لكن يصبح من الأصعب بكثير أن ينتهي توكن حي داخل Git.

3. نظف المهام قبل أن تتحول إلى معيار للفريق

ملفات المهام مسار شائع آخر للتسرب. قد تبدأ المهمة كاختصار محلي، ثم تتحول بهدوء إلى قالب يشاركه الفريق، ومعها تنتقل أي أسرار مزروعة داخلها.

    {
  "version": "2.0.0",
  "tasks": [
    {
      "label": "run migrations",
      "type": "shell",
      "command": "pnpm prisma migrate deploy",
      "options": {
        "env": {
          "NODE_ENV": "development"
        }
      },
      "problemMatcher": []
    }
  ]
}

  

إذا رأيت يومًا قيمة مثل DATABASE_URL=... أو مفتاح API حقيقي داخل مهمة، فتعامل مع ذلك كخطأ إنتاجي لا كاختيار شخصي.

4. أضف فحصًا بسيطًا قبل الالتزام

لا تحتاج إلى منصة أسرار ضخمة لتلتقط أكثر الأخطاء شيوعًا. فحص صغير قبل الالتزام يكفي غالبًا لإيقاف الأنماط الفاضحة قبل مغادرة الجهاز:

    #!/usr/bin/env bash
set -euo pipefail

if git diff --cached --name-only | xargs rg -n --pcre2 "(API_KEY|SECRET|TOKEN|DATABASE_URL)="; then
  echo "Potential secret detected in staged files."
  exit 1
fi

  

هذا الفحص ليس مثاليًا، لكنه فعال جدًا في القضاء على أكثر أشكال التسرب إحراجًا وشيوعًا.

قائمة نهائية سريعة

إذا أردت خط أساس عملي، فابدأ بهذه النقاط:

• فعّل Workspace Trust ولا تتجاوز التنبيهات بلا تفكير
• أخفِ ملفات .env من التصفح والبحث اليومي
• استخدم envFile بدل الأسرار المضمنة داخل إعدادات التصحيح
• اجعل ملفات المهام قابلة للمشاركة من دون إحراج
• أضف فحص أسرار خفيفًا قبل الالتزام

هذه القائمة لن تجعل VS Code مثاليًا، لكنها ستقضي على الأخطاء الكسولة والمتكررة التي تسبب الجزء الأكبر من تسربات أسرار المطورين.