ਢਲਾਣਾਂ 'ਤੇ ਹਮਲੇ

ਸਲੌਪਸਕੁਏਟਿੰਗ ਹਮਲੇ: ਕਿਵੇਂ ਇੱਕ ਏਆਈ ਗਲਤੀ ਤੁਹਾਡੀ ਸਾਫਟਵੇਅਰ ਸਪਲਾਈ ਚੇਨ ਵਿੱਚ ਇੱਕ ਨਵਾਂ ਰਸਤਾ ਬਣ ਗਈ

ਵਿਸ਼ਾ - ਸੂਚੀ

ਪੜ੍ਹਨਯੋਗ ਪੋਸਟਾਂ

ਦਿਲਚਸਪੀ ਵਾਲੀਆਂ ਨਵੀਨਤਮ ਪੋਸਟਾਂ

ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਮੱਸਿਆ

ਅਗਲੀ ਵਾਰ ਇੱਕ AI ਸਹਾਇਕ ਇੰਸਟਾਲ ਕਰਨ ਲਈ ਇੱਕ ਪੈਕੇਜ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹੈ, ਕੀ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਜਾਂਚ ਕਰਨ ਜਾ ਰਹੇ ਹੋ ਕਿ ਕੀ ਉਹ ਪੈਕੇਜ ਮੌਜੂਦ ਹੈ? ਜ਼ਿਆਦਾਤਰ ਡਿਵੈਲਪਰਾਂ ਨੇ ਨਹੀਂ ਕੀਤਾ। ਸੁਝਾਅ ਅਤੇ ਤਸਦੀਕ ਵਿਚਕਾਰ ਉਹ ਪਾੜਾ ਬਿਲਕੁਲ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸਲੋਪਸਕਵੇਟਿੰਗ ਹਮਲੇ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਸਲੋਪਸਕਵੇਟਿੰਗ ਦੇ ਵਿਕਾਸ ਅਤੇ ਵਿਹਾਰਕ ਸਲੋਪਸਕਵੇਟਿੰਗ ਰੋਕਥਾਮ ਦੋਵਾਂ ਨੂੰ ਸਮਝਣਾ ਐਪਸੇਕ ਅਤੇ ਡੇਵਸੈਕਓਪਸ ਟੀਮਾਂ ਲਈ ਇੱਕ ਅਸਲ ਤਰਜੀਹ ਬਣ ਗਈ ਹੈ।

ਝੁਕ ਕੇ ਬੈਠਣ ਵਾਲਾ ਹਮਲਾ ਕੀ ਹੁੰਦਾ ਹੈ?

ਇੱਕ ਢਲਾਣ ਵਾਲਾ ਹਮਲਾ ਇੱਕ ਰੂਪ ਹੈ ਟਾਈਪੋ ਸਕੈਟਿੰਗ (ਇੱਕ ਡੋਮੇਨ ਜਾਂ ਪੈਕੇਜ ਨਾਮ ਨੂੰ ਰਜਿਸਟਰ ਕਰਨ ਦਾ ਅਭਿਆਸ ਜੋ ਇੱਕ ਆਮ ਗਲਤ ਸਪੈਲਿੰਗ ਦੁਆਰਾ ਇੱਕ ਜਾਇਜ਼ ਨਾਮ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਬੇਨਤੀਆਂ ਦੇ ਬਜਾਏ ਬੇਨਤੀਆਂ, ਉਮੀਦ ਹੈ ਕਿ ਇੱਕ ਉਪਭੋਗਤਾ ਦੀ ਆਪਣੀ ਟਾਈਪੋ ਉਹਨਾਂ ਨੂੰ ਸਿੱਧਾ ਇਸ ਤੱਕ ਪਹੁੰਚਾਉਂਦੀ ਹੈ), ਪਰ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਅੰਤਰ ਦੇ ਨਾਲ ਕਿੱਥੋਂ ਗਲਤੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਟਾਈਪੋਸਕੈਟਿੰਗ ਮਨੁੱਖੀ ਟਾਈਪਿੰਗ ਗਲਤੀਆਂ ਦਾ ਸ਼ੋਸ਼ਣ ਕਰਦੀ ਹੈ। ਇੱਕ ਸਲੋਪਸਕੈਟਿੰਗ ਹਮਲਾ ਵੱਡੇ ਭਾਸ਼ਾ ਮਾਡਲਾਂ ਦੁਆਰਾ ਕੀਤੀਆਂ ਗਈਆਂ ਗਲਤੀਆਂ ਦਾ ਸ਼ੋਸ਼ਣ ਕਰਦਾ ਹੈ: ਇੱਕ LLM ਇੱਕ ਪੈਕੇਜ ਨਾਮ ਨੂੰ "ਭਰਮ" ਕਰਦਾ ਹੈ ਜੋ ਬਿਲਕੁਲ ਜਾਇਜ਼ ਲੱਗਦਾ ਹੈ ਪਰ ਕਿਸੇ ਵੀ ਜਨਤਕ ਰਜਿਸਟਰੀ ਵਿੱਚ ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਅਤੇ ਇੱਕ ਹਮਲਾਵਰ ਚੰਗੇ ਇਰਾਦੇ ਵਾਲੇ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਸਹੀ ਨਾਮ ਨੂੰ ਰਜਿਸਟਰ ਕਰਕੇ ਪਹਿਲਾਂ ਉੱਥੇ ਪਹੁੰਚ ਜਾਂਦਾ ਹੈ। 

ਇੱਕ ਆਮ ਸਲੋਪਸਕਵੇਟਿੰਗ ਹਮਲੇ ਦੇ ਪਿੱਛੇ ਵਿਧੀ ਸਰਲ ਹੈ, ਅਤੇ ਇਹੀ ਸਾਦਗੀ ਇਸਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣਾਉਂਦੀ ਹੈ:

  • ਇੱਕ ਡਿਵੈਲਪਰ ਇੱਕ AI ਸਹਾਇਕ ਨੂੰ ਕੋਡਿੰਗ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ।
  • ਇਹ ਮਾਡਲ ਇੱਕ ਅਜਿਹਾ ਹੱਲ ਤਿਆਰ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕ ਅਜਿਹੇ ਪੈਕੇਜ ਨੂੰ ਆਯਾਤ ਕਰਦਾ ਹੈ ਜਾਂ ਸਥਾਪਤ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹੈ ਜੋ ਕਦੇ ਮੌਜੂਦ ਨਹੀਂ ਸੀ।
  • ਇੱਕ ਹਮਲਾਵਰ ਜਿਸਨੇ ਦੇਖਿਆ ਹੈ ਕਿ ਕਈ ਮਾਡਲ ਇੱਕੋ ਭਰਮ ਨਾਮ ਨੂੰ ਦੁਹਰਾਉਂਦੇ ਰਹਿੰਦੇ ਹਨ, ਉਹ ਉਸ ਪੈਕੇਜ ਨੂੰ npm, PyPI, ਜਾਂ ਕਿਸੇ ਹੋਰ ਜਨਤਕ ਰਜਿਸਟਰੀ ਵਿੱਚ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਖਤਰਨਾਕ ਕੋਡ ਹੁੰਦਾ ਹੈ। ਇਹ ਉਹ ਪਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਭਰਮ ਇੱਕ ਅਸਲ ਸਲੋਪਸਕਵੇਟਿੰਗ ਹਮਲੇ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।
  • ਅਗਲਾ ਡਿਵੈਲਪਰ ਜਿਸਨੂੰ ਉਹੀ ਸੁਝਾਅ ਮਿਲਦਾ ਹੈ ਅਤੇ ਉਹ ਇਸਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰਦਾ, ਉਹ ਹੁਣ-ਅਸਲੀ ਪੈਕੇਜ ਸਥਾਪਤ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਉਹਨਾਂ ਦੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਇੱਕ ਪਿਛਲਾ ਦਰਵਾਜ਼ਾ ਹੈ।

"ਸਲੌਪਸਕੁਏਟਿੰਗ" ਸ਼ਬਦ ਪਾਈਥਨ ਸਾਫਟਵੇਅਰ ਫਾਊਂਡੇਸ਼ਨ ਦੇ ਸੁਰੱਖਿਆ ਡਿਵੈਲਪਰ-ਇਨ-ਰੈਜ਼ੀਡੈਂਸ ਸੇਥ ਲਾਰਸਨ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਐਂਡਰਿਊ ਨੇਸਬਿਟ ਦੁਆਰਾ ਇਸ ਪੈਟਰਨ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ ਪ੍ਰਸਿੱਧ ਕੀਤਾ ਗਿਆ ਸੀ: ਇੱਕ "ਪੈਕੇਜ ਭਰਮ" ਇੱਕ ਹਮਲੇ ਦੇ ਵੈਕਟਰ ਵਿੱਚ ਬਦਲ ਗਿਆ।

ਢਲਾਣਾਂ ਵਾਲਾ ਵਿਕਾਸ: ਕਿਵੇਂ ਇੱਕ ਖੋਜ ਉਤਸੁਕਤਾ ਇੱਕ ਅਸਲ ਖ਼ਤਰੇ ਵਿੱਚ ਵਧੀ

ਸਲੌਪਸਕੁਐਟਿੰਗ ਦੇ ਵਿਕਾਸ ਬਾਰੇ ਜੋ ਗੱਲ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਉਹ ਸਿਰਫ਼ ਸੰਕਲਪ ਨਹੀਂ ਹੈ; ਇਹ ਹੈ ਕਿ ਇਹ ਕਿੰਨੀ ਜਲਦੀ ਇੱਕ ਖੋਜ ਨਿਰੀਖਣ ਤੋਂ ਹਮਲੇ ਦੇ ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ, ਮਾਪਣਯੋਗ ਵਰਗ ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਗਿਆ।

2023: ਪਹਿਲਾ ਚੇਤਾਵਨੀ ਸੰਕੇਤ। ਸੁਰੱਖਿਆ ਖੋਜਕਰਤਾ ਬਾਰ ਲਾਨਿਆਡੋ ਦੇਖਿਆ ਕਿ ਕਈ LLMs ਨੇ ਵਾਰ-ਵਾਰ ਇੱਕ ਪੈਕੇਜ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ ਜਿਸਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਜੱਫੀ ਪਾਉਣ ਵਾਲਾ ਚਿਹਰਾ-ਕਲਿੱਪ, ਜੋ ਮੌਜੂਦ ਨਹੀਂ ਹੈ (ਅਸਲ ਪੈਕੇਜ ਇਸ ਨਾਲ ਸਥਾਪਿਤ ਹੈ ਪਾਈਪ ਇੰਸਟਾਲ -U “huggingface_hub[cli]”). ਜੋਖਮ ਨੂੰ ਦਰਸਾਉਣ ਲਈ, ਉਸਨੇ ਉਸ ਪੈਕੇਜ ਦਾ ਇੱਕ ਖਾਲੀ ਸੰਸਕਰਣ ਇੱਕ ਜਨਤਕ ਰਜਿਸਟਰੀ ਵਿੱਚ ਅਪਲੋਡ ਕੀਤਾ। ਤਿੰਨ ਮਹੀਨਿਆਂ ਦੇ ਅੰਦਰ, ਇਸਨੂੰ 30,000 ਤੋਂ ਵੱਧ ਡਾਊਨਲੋਡ ਪ੍ਰਾਪਤ ਹੋਏ, ਬਿਨਾਂ ਕਿਸੇ ਪ੍ਰਚਾਰ ਦੇ। ਇਹ ਭਰਮ ਵਾਲਾ ਨਾਮ ਅਲੀਬਾਬਾ ਦੀ ਖੋਜ ਨਾਲ ਜੁੜੇ ਇੱਕ ਭੰਡਾਰ ਦੇ README ਵਿੱਚ ਵੀ ਸਾਹਮਣੇ ਆਇਆ, ਜਿਸ ਤੋਂ ਪਤਾ ਚੱਲਿਆ ਕਿ ਇਹ "ਨਕਲੀ" ਨਾਮ ਅਸਲ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਕਿਵੇਂ ਲੀਕ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਆਉਣ ਵਾਲੇ ਢਲਾਣ ਵਾਲੇ ਹਮਲਿਆਂ ਲਈ ਮੰਚ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹਨ।

2024: ਜੋਖਮ ਇੱਕ ਖੋਜਕਰਤਾ ਦੇ ਬਲੌਗ ਪੋਸਟ ਤੋਂ ਮੁੱਖ ਧਾਰਾ ਤਕਨੀਕੀ ਕਵਰੇਜ ਵੱਲ ਵਧਦਾ ਹੈ। ਮਾਰਚ 2024 ਵਿੱਚ, ਰਜਿਸਟਰ ਇਸ ਬਾਰੇ ਰਿਪੋਰਟ ਕੀਤੀ ਗਈ ਕਿ ਕਿਵੇਂ ਏਆਈ ਮਾਡਲ ਭਰੋਸੇ ਨਾਲ ਸਾਫਟਵੇਅਰ ਪੈਕੇਜ ਨਾਮਾਂ ਦੀ ਕਾਢ ਕੱਢ ਰਹੇ ਸਨ ਜੋ ਡਿਵੈਲਪਰ ਉਸ ਸਮੇਂ ਡਾਊਨਲੋਡ ਕਰ ਰਹੇ ਸਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਮਾਲਵੇਅਰ ਨਾਲ ਜ਼ਹਿਰੀਲੇ ਸਨ। ਉਹ ਕਵਰੇਜ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਜੋ ਪ੍ਰਗਟ ਹੋਇਆ ਉਸ ਲਈ ਘੱਟ ਅਤੇ ਇਸਨੇ ਜੋ ਸੰਕੇਤ ਕੀਤਾ ਉਸ ਲਈ ਜ਼ਿਆਦਾ ਮਾਇਨੇ ਰੱਖਦਾ ਸੀ: ਹੱਗਿੰਗਫੇਸ-ਕਲੀਅਰ ਕੇਸ ਹੁਣ ਇੱਕ ਵਾਰ ਦੀ ਉਤਸੁਕਤਾ ਨਹੀਂ ਰਿਹਾ; ਇਹ ਮੁੱਖ ਧਾਰਾ ਤਕਨੀਕੀ ਪ੍ਰੈਸ ਲਈ ਝੰਡੀ ਦੇਣ ਲਈ ਕਾਫ਼ੀ ਗੰਭੀਰ ਪੈਟਰਨ ਦਾ ਪਹਿਲਾ ਸੰਕੇਤ ਸੀ, ਵੱਡੇ ਪੱਧਰ ਦੇ ਅਕਾਦਮਿਕ ਅਧਿਐਨ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਇੱਕ ਸਾਲ ਬਾਅਦ ਦਾਇਰੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੇਗਾ।

2025: ਸਮੱਸਿਆ ਦਾ ਪਹਿਲਾ ਸਖ਼ਤ, ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਮਾਪ। ਕਾਗਜ "ਸਾਡੇ ਕੋਲ ਤੁਹਾਡੇ ਲਈ ਇੱਕ ਪੈਕੇਜ ਹੈ! ਕੋਡ ਜਨਰੇਟਿੰਗ LLM ਦੁਆਰਾ ਪੈਕੇਜ ਭਰਮਾਂ ਦਾ ਇੱਕ ਵਿਆਪਕ ਵਿਸ਼ਲੇਸ਼ਣ" (Spracklen et al., 'ਤੇ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ USENIX ਸੁਰੱਖਿਆ ਸਿੰਪੋਜ਼ੀਅਮ) ਨੇ 576,000 ਪਾਈਥਨ ਅਤੇ ਜਾਵਾ ਸਕ੍ਰਿਪਟ ਕੋਡ ਨਮੂਨਿਆਂ ਵਿੱਚ 16 ਕੋਡ-ਜਨਰੇਸ਼ਨ ਮਾਡਲਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ, ਦੋਵੇਂ ਵਪਾਰਕ (GPT-4, GPT-3.5) ਅਤੇ ਓਪਨ ਸੋਰਸ (CodeLlama, DeepSeek, WizardCoder, Mistral)। ਇਹ ਖੋਜਾਂ ਸਲੋਪਸਕਵੇਟਿੰਗ ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਇੱਕ ਸਪੱਸ਼ਟ ਬਿੰਦੂ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ, ਇਸਨੂੰ ਕਿੱਸੇ ਤੋਂ ਡੇਟਾ ਵੱਲ ਲੈ ਜਾਂਦੀਆਂ ਹਨ:

  • 19.7% ਮਾਡਲਾਂ ਦੁਆਰਾ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੇ ਗਏ ਪੈਕੇਜ ਮੌਜੂਦ ਨਹੀਂ ਸਨ।
  • ਓਪਨ-ਸੋਰਸ ਮਾਡਲ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਾਰ ਭਰਮ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ (21.7% ਔਸਤਨ) ਵਪਾਰਕ ਮਾਡਲਾਂ ਨਾਲੋਂ (5.2%).
  • ਸਭ ਤੋਂ ਭੈੜੇ ਅਪਰਾਧੀ, ਕੋਡਲਾਮਾ 7B ਅਤੇ ਕੋਡਲਾਮਾ 34B, ਆਪਣੇ ਇੱਕ ਤਿਹਾਈ ਤੋਂ ਵੱਧ ਆਉਟਪੁੱਟ ਵਿੱਚ ਭਰਮ ਵਿੱਚ ਡੁੱਬੇ ਹੋਏ ਸਨ।
  • ਟੈਸਟ ਕੀਤੇ ਗਏ ਸਾਰੇ ਮਾਡਲਾਂ ਵਿੱਚ, ਖੋਜਕਰਤਾਵਾਂ ਨੇ ਲੌਗ ਇਨ ਕੀਤਾ 205,000 ਵਿਲੱਖਣ ਭਰਮ ਵਾਲੇ ਪੈਕੇਜ ਨਾਮ, ਇੱਕ ਪੂਲ ਜੋ ਕਈ ਈਕੋਸਿਸਟਮਾਂ ਵਿੱਚ ਲਗਾਤਾਰ ਢਲਾਣ ਵਾਲੇ ਹਮਲਿਆਂ ਨੂੰ ਬਾਲਣ ਦੇਣ ਲਈ ਕਾਫ਼ੀ ਵੱਡਾ ਹੈ।
  • ਰੋਕਥਾਮ ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਢੁਕਵਾਂ ਇੱਕ ਵੇਰਵਾ: ਮੋਟੇ ਤੌਰ 'ਤੇ 38% ਭਰਮ ਭਰੇ ਨਾਵਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਅਸਲੀ ਪੈਕੇਜਾਂ ਨਾਲ ਮਿਲਦੇ-ਜੁਲਦੇ ਸਨ, ਜਿਸ ਨਾਲ ਇਹ ਸੰਭਾਵਨਾ ਘੱਟ ਜਾਂਦੀ ਹੈ ਕਿ ਕੋਈ ਵੀ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਦੇਖ ਲਵੇ।

ਅਧਿਐਨ ਤੋਂ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਵੇਰਵਾ, ਅਤੇ ਸ਼ਾਇਦ ਇਸ ਕਾਰਨ ਕਰਕੇ ਕਿ ਸਲੋਪਸਕਵੇਟਿੰਗ ਦਾ ਵਿਕਾਸ ਘੱਟਣ ਦੀ ਬਜਾਏ ਤੇਜ਼ ਹੋਇਆ ਹੈ, ਇਹ ਹੈ ਕਿ ਭਰਮ ਵਾਲੇ ਨਾਮ ਬੇਤਰਤੀਬ ਨਹੀਂ ਹਨ, ਅਤੇ ਉਹ ਹਰ ਕੋਸ਼ਿਸ਼ 'ਤੇ ਨਹੀਂ ਬਦਲਦੇ। ਇੱਕੋ ਜਿਹੇ ਪ੍ਰੋਂਪਟ ਦਿੱਤੇ ਜਾਣ 'ਤੇ ਉਹੀ ਮਾਡਲ ਉਹੀ ਕਾਢ ਕੀਤੇ ਨਾਮ ਦੁਹਰਾਉਂਦੇ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਹਮਲਾਵਰ ਨੂੰ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੁੰਦੀ। ਉਹਨਾਂ ਨੂੰ ਸਿਰਫ਼ ਮਾਡਲ ਵਿਵਹਾਰ ਨੂੰ ਦੇਖਣ, ਉਹਨਾਂ ਨਾਵਾਂ ਦੀ ਪਛਾਣ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਦੁਹਰਾਉਂਦੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਅਸਲੀ ਡਿਵੈਲਪਰ ਦੇ ਅਜਿਹਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਨੂੰ ਰਜਿਸਟਰ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਦੁਹਰਾਉਣਯੋਗਤਾ ਦੇ ਫਾਲੋ-ਅੱਪ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਪਾਇਆ ਗਿਆ ਕਿ ਜਦੋਂ ਖੋਜਕਰਤਾਵਾਂ ਨੇ ਇੱਕੋ ਜਿਹੇ ਪ੍ਰੋਂਪਟ ਨੂੰ ਦਸ ਵਾਰ ਦੁਬਾਰਾ ਚਲਾਇਆ, ਤਾਂ ਹਰ ਇੱਕ ਦੌੜ 'ਤੇ 43% ਭਰਮ ਵਾਲੇ ਪੈਕੇਜ ਨਾਮ ਦਿਖਾਈ ਦਿੱਤੇ, ਅਤੇ 58% ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਦੁਹਰਾਏ ਗਏ, ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ ਭਰਮ ਇੱਕ ਵਾਰ ਦੇ ਸ਼ੋਰ ਦੀ ਬਜਾਏ ਦੁਹਰਾਉਣ ਯੋਗ ਕਲਾਕ੍ਰਿਤੀਆਂ ਹਨ। ਉਹ ਦੁਹਰਾਉਣਯੋਗਤਾ ਉਹ ਹੈ ਜੋ ਇੱਕ ਵਾਰ ਦੇ ਭਰਮ ਨੂੰ ਇੱਕ ਸਕੇਲੇਬਲ ਸਲੋਪਸਕਵੇਟਿੰਗ ਹਮਲੇ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ।

2026: ਅਲੱਗ-ਥਲੱਗ ਪੈਕੇਜਾਂ ਤੋਂ ਆਟੋਨੋਮਸ ਏਜੰਟਾਂ ਤੱਕ। ਇਸ ਸਾਲ ਨੇ ਹੁਣ ਤੱਕ ਦਾ ਸਭ ਤੋਂ ਸਪੱਸ਼ਟ ਸਬੂਤ ਪੇਸ਼ ਕੀਤਾ ਹੈ ਕਿ ਸਲੌਪਸਕੁਏਟਿੰਗ ਹੁਣ ਇੱਕ ਡਿਵੈਲਪਰ ਦੁਆਰਾ ਸੁਝਾਏ ਗਏ ਇੱਕ ਕਾਪੀ-ਪੇਸਟ ਤੱਕ ਸੀਮਤ ਨਹੀਂ ਹੈ ਪਾਈਪ ਇੰਸਟਾਲ ਕਰੋ or npm ਇੰਸਟਾਲ ਹੁਕਮ। ਜਨਵਰੀ 2026 ਵਿੱਚ, ਖੋਜਕਰਤਾ ਚਾਰਲੀ ਏਰਿਕਸਨ ਏਕੀਡੋ ਸਿਕਿਓਰਿਟੀ ਵਿਖੇ ਪਾਇਆ ਗਿਆ ਕਿ ਏਆਈ ਕੋਡਿੰਗ ਏਜੰਟ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਭਰਮ ਵਾਲੇ ਐਨਪੀਐਮ ਪੈਕੇਜ ਦਾ ਹਵਾਲਾ ਦਿੰਦੇ ਹੋਏ ਨਿਰਦੇਸ਼ ਫੈਲਾ ਚੁੱਕੇ ਸਨ, ਪ੍ਰਤੀਕਿਰਿਆ-ਕੋਡਸ਼ਿਫਟ (ਇੱਕ ਅਜਿਹਾ ਨਾਮ ਜੋ ਦੋ ਅਸਲੀ ਔਜ਼ਾਰਾਂ ਨੂੰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਮਿਲਾਉਂਦਾ ਹੈ, jscodeshift ਅਤੇ ਰੀਐਕਟ-ਕੋਡਮੋਡ), 237 ਰਿਪੋਜ਼ਟਰੀਆਂ ਵਿੱਚ, ਏਜੰਟ ਅਜੇ ਵੀ ਇਸਨੂੰ ਰੋਜ਼ਾਨਾ ਸਥਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ। ਏਰਿਕਸਨ ਨੇ ਖੁਦ ਨਾਮ ਰਜਿਸਟਰ ਕੀਤਾ, ਰੱਖਿਆਤਮਕ ਤੌਰ 'ਤੇ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਕੋਈ ਹਮਲਾਵਰ ਇਸਨੂੰ ਹਥਿਆਰ ਬਣਾ ਸਕੇ। ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਇੱਕ ਅਸਲ ਖਤਰਨਾਕ ਪੈਕੇਜ ਜਿਸਦਾ ਨਾਮ ਹੈ ਅਣਵਰਤੇ-ਆਯਾਤ, ਜਾਇਜ਼ ਦੀ ਥਾਂ 'ਤੇ ਭਰਮ ਵਿੱਚ ਐਸਲਿੰਟ-ਪਲੱਗਇਨ-ਅਣਵਰਤੇ-ਆਯਾਤ, 2026 ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਲਗਭਗ 233 ਹਫਤਾਵਾਰੀ ਡਾਊਨਲੋਡ ਰਿਕਾਰਡ ਕਰ ਰਿਹਾ ਸੀ, ਭਾਵੇਂ ਕਿ npm ਇਸਨੂੰ ਸੁਰੱਖਿਆ ਹੋਲਡ ਦੇ ਅਧੀਨ ਰੱਖਦਾ ਹੈ, ਇਹ ਇੱਕ ਸੰਕੇਤ ਹੈ ਕਿ ਇੱਕ ਸਲੌਪਸਕੈਟਿੰਗ ਹਮਲਾ ਕਿੰਨੀ ਦੇਰ ਤੱਕ ਪੀੜਤਾਂ ਨੂੰ ਖਿੱਚਦਾ ਰਹਿ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਇਸਨੂੰ ਫਲੈਗ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਵੀ। ਹਾਲ ਹੀ ਵਿੱਚ, ਜੁਲਾਈ 2026 ਵਿੱਚ, ਖੋਜਕਰਤਾਵਾਂ ਨੇ ਇੱਕ ਸੰਬੰਧਿਤ ਤਕਨੀਕ ਦਾ ਵਰਣਨ ਕੀਤਾ, ਜਿਸਨੂੰ "ਹੈਲੂਸਕੈਟਿੰਗ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਇੱਕ AI ਭਰਮ ਨੂੰ ਇੱਕ ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਸ਼ਨ ਨਾਲ ਜੰਜ਼ੀਰਾਂ ਵਿੱਚ ਬੰਨ੍ਹਦਾ ਹੈ ਤਾਂ ਜੋ ਇੱਕ AI ਕੋਡਿੰਗ ਏਜੰਟ ਜੋ ਇੱਕ ਉਪਭੋਗਤਾ ਦੀ ਤਰਫੋਂ ਇੱਕ ਭਰਮ ਸਰੋਤ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਨੂੰ ਹਮਲਾਵਰ-ਸਪਲਾਈ ਕੀਤੇ ਕੋਡ ਨੂੰ ਚਲਾਉਣ ਵਿੱਚ ਹਾਈਜੈਕ ਕੀਤਾ ਜਾ ਸਕੇ, ਇੱਕ ਪੈਸਿਵ ਇੰਸਟਾਲ ਜੋਖਮ ਤੋਂ ਸਲੌਪਸਕੈਟਿੰਗ ਦੇ ਵਿਕਾਸ ਨੂੰ ਏਜੰਟਿਕ ਵਿਕਾਸ ਵਰਕਫਲੋ ਦੇ ਅੰਦਰ ਇੱਕ ਸਰਗਰਮ ਰਿਮੋਟ-ਕੋਡ-ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਵੈਕਟਰ ਵਿੱਚ ਵਧਾਉਂਦਾ ਹੈ।

"ਵਾਈਬ ਕੋਡਿੰਗ" ਨੇ ਸਲੋਪਸਕਵੇਟਿੰਗ ਹਮਲਿਆਂ ਲਈ ਸਤ੍ਹਾ ਦਾ ਵਿਸਤਾਰ ਕਿਉਂ ਕੀਤਾ?

ਜੇਕਰ AI-ਤਿਆਰ ਕੀਤਾ ਕੋਡ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਅਭਿਆਸ ਹੁੰਦਾ ਤਾਂ ਸਲੋਪਸਕਵੇਟਿੰਗ ਹਮਲੇ ਬਹੁਤ ਮਾਇਨੇ ਨਹੀਂ ਰੱਖਦੇ। ਅਜਿਹਾ ਨਹੀਂ ਹੈ। ਕੋਡਿੰਗ ਸਹਾਇਕਾਂ, ਆਟੋਨੋਮਸ ਏਜੰਟਾਂ, ਅਤੇ "ਵਾਈਬ ਕੋਡਿੰਗ" ਵਰਕਫਲੋਜ਼ ਦੇ ਉਭਾਰ, ਜਿੱਥੇ ਡਿਵੈਲਪਰ ਕੋਡ ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦੀ ਘੱਟ ਤੋਂ ਘੱਟ ਸਮੀਖਿਆ ਕਰਦੇ ਹਨ, ਨੇ ਸਾਫਟਵੇਅਰ ਹਮਲੇ ਦੀ ਸਤ੍ਹਾ ਨੂੰ ਦੋ ਠੋਸ ਤਰੀਕਿਆਂ ਨਾਲ ਬਦਲ ਦਿੱਤਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਸਲੋਪਸਕਵੇਟਿੰਗ ਦੇ ਵਿਕਾਸ ਨੂੰ ਤੇਜ਼ ਕਰ ਰਹੇ ਹਨ:

  • ਐਂਟਰੀ ਪੁਆਇੰਟ ਹੁਣ ਸਿਰਫ਼ ਡਿਵੈਲਪਰ ਨਹੀਂ ਹੈ। ਇੱਕ ਟਾਈਪੋਸਕੈਟਿੰਗ ਹਮਲਾ ਪਹਿਲਾਂ ਇੱਕ ਵਿਅਕਤੀ ਦੁਆਰਾ ਟਾਈਪਿੰਗ ਗਲਤੀ ਕਰਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਸੀ। ਹੁਣ ਇਹ ਗਲਤੀ ਮਾਡਲ ਦੇ ਅੰਦਰੋਂ ਹੀ ਪੈਦਾ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਸੈਂਕੜੇ ਵੱਖ-ਵੱਖ ਡਿਵੈਲਪਰਾਂ ਤੱਕ ਫੈਲ ਸਕਦੀ ਹੈ ਜੋ ਇੱਕੋ ਜਿਹੇ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ ਅਤੇ ਉਹੀ ਭਰਮ ਵਾਲੀ ਸਿਫ਼ਾਰਸ਼ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ, ਇੱਕ ਸਿੰਗਲ ਸਲੋਪਸਕੈਟਿੰਗ ਹਮਲੇ ਦੀ ਪਹੁੰਚ ਨੂੰ ਗੁਣਾ ਕਰਦੇ ਹਨ।
  • ਹਮਲੇ ਦੀ ਸਤ੍ਹਾ ਲੜੀ ਦੇ ਹੋਰ ਉੱਪਰ ਵੱਲ ਵਧ ਗਈ ਹੈ। ਹੁਣ ਸਿਰਫ਼ ਇੱਕ ਮਨੁੱਖ ਦੁਆਰਾ ਲਿਖੇ ਗਏ ਕੋਡ ਨੂੰ ਦੇਖਣਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਟੀਮਾਂ ਨੂੰ ਇੱਕ AI ਸਹਾਇਕ ਦੁਆਰਾ ਸੁਝਾਏ ਗਏ ਨਿਰਭਰਤਾਵਾਂ, ਉਹਨਾਂ MCP ਸਰਵਰਾਂ ਨੂੰ ਵੀ ਦੇਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨਾਲ ਇਹ ਜੁੜਦਾ ਹੈ, ਅਤੇ ਏਜੰਟ ਜੋ ਸਿੱਧੇ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਤੋਂ ਬਿਨਾਂ ਖੁਦਮੁਖਤਿਆਰੀ ਨਾਲ ਪੈਕੇਜ ਸਥਾਪਤ ਕਰਦੇ ਹਨ। ਪਰੰਪਰਾਗਤ AppSec, ਰਿਪੋਜ਼ਟਰੀਆਂ ਅਤੇ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ। commits, ਨੂੰ ਕਦੇ ਵੀ ਡਿਵੈਲਪਰ, AI, ਅਤੇ ਪੈਕੇਜ ਰਜਿਸਟਰੀ ਵਿਚਕਾਰ ਇਸ ਨਵੀਂ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਨੂੰ ਦੇਖਣ ਲਈ ਤਿਆਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ, ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਹੁਣ ਸਲੋਪਸਕਵੇਟਿੰਗ ਹਮਲੇ ਲੁਕਦੇ ਹਨ।

ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਜਨਰੇਟਿਵ AI ਸੁਭਾਵਿਕ ਤੌਰ 'ਤੇ ਅਸੁਰੱਖਿਅਤ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਇੱਕ ਨਵੀਂ ਕਿਸਮ ਦੀ ਸਪਲਾਈ ਚੇਨ ਜੋਖਮ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਫੜਨ ਲਈ ਰਵਾਇਤੀ ਸੁਰੱਖਿਆ ਟੂਲਿੰਗ ਨਹੀਂ ਬਣਾਈ ਗਈ ਸੀ, ਅਤੇ ਇੱਕ ਜੋ ਉਹੀ ਤਸਦੀਕ ਸਿਧਾਂਤਾਂ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ ਜੋ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਵੀ ਬਾਹਰੀ ਨਿਰਭਰਤਾ 'ਤੇ ਲਾਗੂ ਕਰਦੇ ਹਾਂ: ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ, ਸਰੋਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਹਰੇਕ ਡਿਵੈਲਪਰ ਦੀ ਯਾਦਦਾਸ਼ਤ ਜਾਂ ਚੌਕਸੀ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਦੀ ਬਜਾਏ ਉਸ ਤਸਦੀਕ ਨੂੰ ਸਵੈਚਾਲਿਤ ਕਰੋ। ਉਹ ਆਟੋਮੇਸ਼ਨ ਕਿਸੇ ਵੀ ਅਸਲ ਸਲੋਪਸਕੈਟਿੰਗ ਰੋਕਥਾਮ ਰਣਨੀਤੀ ਦੀ ਨੀਂਹ ਹੈ।

ਸਲੋਪਸਕਵੇਟਿੰਗ ਰੋਕਥਾਮ: ਟੀਮਾਂ ਅੱਜ ਕੀ ਕਰ ਸਕਦੀਆਂ ਹਨ

ਚੰਗੀ ਖ਼ਬਰ ਇਹ ਹੈ ਕਿ ਸਲੋਪਸਕਵੇਟਿੰਗ ਰੋਕਥਾਮ ਲਈ ਵਿਦੇਸ਼ੀ ਟੂਲਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਸ ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਨਿਰਭਰਤਾ ਸਫਾਈ ਅਭਿਆਸਾਂ ਨੂੰ ਯੋਜਨਾਬੱਧ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਪਰ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਉਸ ਪਲ ਆਰਾਮ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਇੱਕ AI ਜਿਸ 'ਤੇ ਉਹ ਭਰੋਸਾ ਕਰਦੇ ਹਨ ਕੋਡ ਨੂੰ "ਸੁਝਾਅ" ਦਿੰਦਾ ਹੈ। ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸਲੋਪਸਕਵੇਟਿੰਗ ਰੋਕਥਾਮ ਪਹੁੰਚ ਆਮ ਤੌਰ 'ਤੇ ਹੇਠ ਲਿਖਿਆਂ ਨੂੰ ਜੋੜਦੀ ਹੈ:

  • ਕਿਸੇ ਵੀ ਨਵੇਂ ਪੈਕੇਜ ਨੂੰ ਇੰਸਟਾਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਸਨੂੰ ਹੱਥੀਂ ਤਸਦੀਕ ਕਰੋ।, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਇਹ ਕਿਸੇ AI ਸਹਾਇਕ ਦੇ ਸੁਝਾਅ ਤੋਂ ਆਉਂਦਾ ਹੈ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਅਧਿਕਾਰਤ ਰਜਿਸਟਰੀ ਵਿੱਚ ਮੌਜੂਦ ਹੈ, ਇਸਨੂੰ ਕੌਣ ਸੰਭਾਲਦਾ ਹੈ, ਇਹ ਕਦੋਂ ਪ੍ਰਕਾਸ਼ਿਤ ਹੋਇਆ ਸੀ, ਅਤੇ ਕੀ ਇਸਦੇ ਡਾਊਨਲੋਡ ਨੰਬਰ ਅਸਲੀ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਇਹ ਇੱਕਲੀ ਆਦਤ ਕਿਸੇ ਵੀ ਟੀਮ ਲਈ ਉਪਲਬਧ ਸਲੋਪਸਕੈਟਿੰਗ ਰੋਕਥਾਮ ਦਾ ਸਭ ਤੋਂ ਸਸਤਾ ਰੂਪ ਹੈ।
  • ਕਦੇ ਵੀ ਇਹ ਨਾ ਮੰਨੋ ਕਿ AI-ਤਿਆਰ ਕੀਤਾ ਕੋਡ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਹੈ। ਇੱਕ ਕੋਡ ਸਨਿੱਪਟ ਜੋ "ਕੰਮ ਕਰਦਾ ਹੈ" ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਇਸਦੀ ਨਿਰਭਰਤਾ ਜਾਇਜ਼ ਹੈ। ਨਿਰਭਰਤਾ ਸਮੀਖਿਆ ਕੋਡ ਸਮੀਖਿਆ ਦਾ ਹਿੱਸਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਇਸਦਾ ਅਪਵਾਦ ਨਹੀਂ।
  • ਲਾਕਫਾਈਲਾਂ ਅਤੇ ਹੈਸ਼ ਵੈਰੀਫਿਕੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰੋ ਸਹੀ ਸੰਸਕਰਣਾਂ ਨੂੰ ਪਿੰਨ ਕਰਨ ਅਤੇ ਇੱਕ ਸਾਈਲੈਂਟ ਅਪਡੇਟ ਨੂੰ ਅਸਲ ਵਿੱਚ ਆਡਿਟ ਕੀਤੇ ਗਏ ਪੈਕੇਜ ਨਾਲੋਂ ਵੱਖਰੇ ਪੈਕੇਜ ਵਿੱਚ ਸਵੈਪ ਕਰਨ ਤੋਂ ਰੋਕਣ ਲਈ।
  • ਨਿਰਭਰਤਾ ਸਕੈਨਿੰਗ ਤੈਨਾਤ ਕਰੋ ਜੋ ਜਾਣੇ-ਪਛਾਣੇ CVE ਤੋਂ ਪਰੇ ਜੋਖਮ ਪੈਟਰਨਾਂ ਨੂੰ ਫਲੈਗ ਕਰਦੀ ਹੈ।: ਅਸਾਧਾਰਨ ਪੈਕੇਜ, ਸ਼ੱਕੀ ਤੌਰ 'ਤੇ ਮੌਜੂਦਾ ਪੈਕੇਜਾਂ ਨਾਲ ਮਿਲਦੇ-ਜੁਲਦੇ ਨਾਮ, ਬਿਨਾਂ ਕਿਸੇ ਟਰੈਕ ਰਿਕਾਰਡ ਦੇ ਨਵੇਂ ਰੱਖ-ਰਖਾਅ ਕਰਨ ਵਾਲੇ, ਜਾਂ ਅਸਾਧਾਰਨ ਵਿਵਹਾਰ ਵਾਲੀਆਂ ਸਕ੍ਰਿਪਟਾਂ ਸਥਾਪਤ ਕਰਨਾ। ਇੱਕ ਨਵਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਪੈਕੇਜ ਜਿਸਦਾ ਲਗਭਗ ਕੋਈ ਇਤਿਹਾਸ ਨਹੀਂ ਹੈ ਜੋ "ਲਗਭਗ" ਜਾਣੀ-ਪਛਾਣੀ ਚੀਜ਼ ਦੇ ਨਾਮ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ, ਹੁਣ ਤੱਕ ਦਸਤਾਵੇਜ਼ ਕੀਤੇ ਗਏ ਜ਼ਿਆਦਾਤਰ ਸਲੋਪਸਕੈਟਿੰਗ ਹਮਲਿਆਂ ਦੇ ਪਿੱਛੇ ਬਿਲਕੁਲ ਉਹੀ ਪੈਟਰਨ ਹੈ।
  • ਜਨਤਕ ਰਜਿਸਟਰੀਆਂ ਨਾਲ ਵੀ ਉਹੀ ਸਰੋਕਾਰ ਰੱਖੋ।cism ਕਿਸੇ ਹੋਰ ਅਣ-ਪ੍ਰਮਾਣਿਤ ਬਾਹਰੀ ਸਰੋਤ ਵਾਂਗ। ਇਹ ਤੱਥ ਕਿ ਪਾਈਪ ਇੰਸਟਾਲ ਕਰੋ or npm ਇੰਸਟਾਲ ਗਲਤੀ ਨਹੀਂ ਸੁੱਟਦਾ, ਇਹ ਜਾਇਜ਼ਤਾ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ।
  • ਵਿਕਾਸ ਟੀਮਾਂ ਨੂੰ ਸਿਖਲਾਈ ਦਿਓ ਇਸ ਤੱਥ 'ਤੇ ਕਿ ਏਆਈ-ਸਹਾਇਤਾ ਪ੍ਰਾਪਤ ਕੋਡਿੰਗ ਕੀ ਸਥਾਪਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨੂੰ ਨਹੀਂ ਹਟਾਉਂਦਾ; ਇਹ ਸਿਰਫ਼ ਇੱਕ ਕਦਮ ਜੋੜਦਾ ਹੈ ਜਿਸਨੂੰ ਕਿਸੇ ਵੀ ਗੰਭੀਰ ਸਲੋਪਸਕੈਟਿੰਗ ਰੋਕਥਾਮ ਯੋਜਨਾ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਵਰਕਫਲੋ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਉਪਾਅ ਆਪਣੇ ਆਪ ਵਿੱਚ ਨਵਾਂ ਨਹੀਂ ਹੈ। ਜੋ ਬਦਲਿਆ ਹੈ ਉਹ ਹੈ ਪੈਮਾਨਾ: ਜਦੋਂ ਇੱਕ ਨਿਰਭਰਤਾ ਸੁਝਾਅ ਸਟੈਕ ਓਵਰਫਲੋ ਜਾਂ ਕਿਸੇ ਸਹਿਯੋਗੀ ਤੋਂ ਨਹੀਂ ਆਉਂਦਾ, ਪਰ ਇੱਕ ਮਾਡਲ ਤੋਂ ਆਉਂਦਾ ਹੈ ਜੋ ਹਜ਼ਾਰਾਂ ਵੱਖ-ਵੱਖ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਉਹੀ ਭਰਮ ਵਾਲੀ ਗਲਤੀ ਦੁਹਰਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਦਸਤੀ ਤਸਦੀਕ, ਜਦੋਂ ਕਿ ਅਜੇ ਵੀ ਜ਼ਰੂਰੀ ਹੈ, ਆਪਣੇ ਆਪ ਕਾਫ਼ੀ ਨਹੀਂ ਹੋ ਜਾਂਦੀ। ਇਸ ਲਈ ਹੋਰ ਟੀਮਾਂ ਆਪਣੇ ਅੰਦਰ ਸਲੋਪਸਕੈਟਿੰਗ ਰੋਕਥਾਮ ਦੀ ਇਸ ਪਰਤ ਨੂੰ ਸਵੈਚਾਲਿਤ ਕਰ ਰਹੀਆਂ ਹਨ ਸਾਫਟਵੇਅਰ ਰਚਨਾ ਵਿਸ਼ਲੇਸ਼ਣ (SCA) ਟੂਲਿੰਗ, ਇਸਨੂੰ ਵਿਅਕਤੀਗਤ ਡਿਵੈਲਪਰ ਅਨੁਸ਼ਾਸਨ 'ਤੇ ਛੱਡਣ ਦੀ ਬਜਾਏ।

ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਹੈcisਏਲੀ ਕਿਉਂ ASPM ਪਲੇਟਫਾਰਮ ਵਰਗੇ ਜ਼ਾਇਗੇਨੀ ਸ਼ੱਕੀ-ਨਿਰਭਰਤਾ ਖੋਜ ਬਣਾਓ, ਟਾਈਪੋਸਕੈਟਿੰਗ, ਨਿਰਭਰਤਾ ਉਲਝਣ, ਅਤੇ ਜਾਣੇ-ਪਛਾਣੇ ਖਤਰਨਾਕ ਪੈਕੇਜਾਂ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹੋਏ, ਇੱਕੋ ਓਪਨ-ਸੋਰਸ ਅਤੇ ਏਆਈ-ਨਿਰਭਰਤਾ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ। pipeline, ਇਸ ਲਈ ਸਲੋਪਸਕਵੇਟਿੰਗ ਰੋਕਥਾਮ ਹਰ ਡਿਵੈਲਪਰ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦੀ ਕਿ ਹਰ ਵਾਰ ਜਦੋਂ ਕੋਈ AI ਸਹਾਇਕ ਨਵੀਂ ਨਿਰਭਰਤਾ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਤਾਂ ਇਸਨੂੰ ਚੈੱਕ ਕਰਨਾ ਯਾਦ ਰੱਖਦਾ ਹੈ।

ਸਵਾਲ

ਕੀ ਸਲੋਪਸਕਵੇਟਿੰਗ ਹਮਲਾ ਟਾਈਪੋਸਕੈਟਿੰਗ ਹਮਲੇ ਦੇ ਸਮਾਨ ਹੈ?

ਬਿਲਕੁਲ ਨਹੀਂ। ਦੋਵਾਂ ਵਿੱਚ ਇੱਕ ਨਕਲੀ ਪੈਕੇਜ ਨਾਮ ਰਜਿਸਟਰ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ ਤਾਂ ਜੋ ਇਸਨੂੰ ਇੰਸਟਾਲ ਕਰਨ ਵਾਲੇ ਨੂੰ ਧੋਖਾ ਦਿੱਤਾ ਜਾ ਸਕੇ, ਪਰ ਗਲਤੀ ਦਾ ਸਰੋਤ ਵੱਖਰਾ ਹੈ। ਟਾਈਪੋਸਕੈਟਿੰਗ ਮਨੁੱਖੀ ਟਾਈਪਿੰਗ ਗਲਤੀਆਂ ਦਾ ਸ਼ੋਸ਼ਣ ਕਰਦੀ ਹੈ। ਇੱਕ ਸਲੋਪਸਕੈਟਿੰਗ ਹਮਲਾ AI ਮਾਡਲਾਂ ਦੁਆਰਾ ਖੋਜੇ ਗਏ (ਭਰਮ ਵਿੱਚ) ਪੈਕੇਜ ਨਾਮਾਂ ਦਾ ਸ਼ੋਸ਼ਣ ਕਰਦਾ ਹੈ, ਜਿਸਨੂੰ ਇੱਕ ਹਮਲਾਵਰ ਫਿਰ ਇਸਦੇ ਜਾਇਜ਼ ਤੌਰ 'ਤੇ ਮੌਜੂਦ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ।

ਕੀ ਕੋਈ ਪੈਕੇਜ ਮੈਨੇਜਰ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਹਮਲੇ ਨੂੰ ਆਪਣੇ ਆਪ ਰੋਕ ਸਕਦਾ ਹੈ?

ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ, ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਸਲੌਪਸਕੈਟਿੰਗ ਰੋਕਥਾਮ ਪੈਕੇਜ ਮੈਨੇਜਰ ਪੱਧਰ 'ਤੇ ਨਹੀਂ ਰੁਕ ਸਕਦੀ। ਜੇਕਰ ਕੋਈ ਹਮਲਾਵਰ ਡਿਵੈਲਪਰ ਦੁਆਰਾ ਇਸਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਭਰਮ ਵਾਲੇ ਪੈਕੇਜ ਨੂੰ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਇੰਸਟਾਲੇਸ਼ਨ ਬਿਨਾਂ ਕਿਸੇ ਗਲਤੀ ਦੇ ਪੂਰੀ ਹੋ ਜਾਵੇਗੀ ਕਿਉਂਕਿ ਪੈਕੇਜ ਅਸਲ ਵਿੱਚ ਮੌਜੂਦ ਹੈ, ਭਾਵੇਂ ਇਹ ਖਤਰਨਾਕ ਹੈ। ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰੋਕਥਾਮ ਲਈ ਪੈਕੇਜ ਦੇ ਮੂਲ ਅਤੇ ਵਿਵਹਾਰ ਦੀ ਵਾਧੂ ਤਸਦੀਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਕੀ ਇਹ ਸਿਰਫ਼ ਓਪਨ-ਸੋਰਸ ਮਾਡਲਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ?

ਨਹੀਂ। ਸਪ੍ਰੈਕਲੇਨ ਅਤੇ ਹੋਰ ਅਧਿਐਨ ਨੇ ਵਪਾਰਕ ਮਾਡਲਾਂ ਸਮੇਤ, ਟੈਸਟ ਕੀਤੇ ਗਏ ਹਰੇਕ ਮਾਡਲ ਵਿੱਚ ਭਰਮ ਪਾਇਆ, ਹਾਲਾਂਕਿ ਇਹ ਕਾਫ਼ੀ ਘੱਟ ਦਰ 'ਤੇ ਸੀ (ਮੁਲਾਂਕਣ ਕੀਤੇ ਗਏ ਓਪਨ-ਸੋਰਸ ਮਾਡਲਾਂ ਲਈ 21.7% ਦੇ ਮੁਕਾਬਲੇ 5.2%)। ਕੋਈ ਵੀ ਮਾਡਲ ਸਮੱਸਿਆ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੁਕਤ ਨਹੀਂ ਹੈ, ਜੋ ਕਿ ਇਸ ਗੱਲ ਦਾ ਇੱਕ ਹਿੱਸਾ ਹੈ ਕਿ ਸਲੋਪਸਕਵੇਟਿੰਗ ਦਾ ਵਿਕਾਸ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ AI-ਸਹਾਇਤਾ ਪ੍ਰਾਪਤ ਕੋਡਿੰਗ ਦੇ ਵਾਧੇ ਦੇ ਨਾਲ ਤਾਲਮੇਲ ਰੱਖਦਾ ਹੈ।

ਕੀ ਇਹ ਇੱਕ ਸਿਧਾਂਤਕ ਜੋਖਮ ਹੈ, ਜਾਂ ਇਸਦਾ ਪਹਿਲਾਂ ਹੀ ਸ਼ੋਸ਼ਣ ਕੀਤਾ ਜਾ ਚੁੱਕਾ ਹੈ?

The ਜੱਫੀ ਪਾਉਣ ਵਾਲਾ ਚਿਹਰਾ-ਕਲਿੱਪ ਇੱਕ ਖੋਜਕਰਤਾ ਦੁਆਰਾ ਅਪਲੋਡ ਕੀਤਾ ਗਿਆ ਇੱਕ ਖਾਲੀ ਪੈਕੇਜ, ਜਿਸਨੂੰ ਤਿੰਨ ਮਹੀਨਿਆਂ ਵਿੱਚ ਬਿਨਾਂ ਕਿਸੇ ਪ੍ਰਚਾਰ ਦੇ 30,000 ਤੋਂ ਵੱਧ ਵਾਰ ਡਾਊਨਲੋਡ ਕੀਤਾ ਗਿਆ ਸੀ, ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਜੋਖਮ ਸਿਰਫ਼ ਸਿਧਾਂਤਕ ਨਹੀਂ ਹੈ: ਇੱਕ ਭਰਮ ਵਾਲਾ ਨਾਮ ਸਿਰਫ਼ ਵੱਖ-ਵੱਖ ਪ੍ਰੋਂਪਟਾਂ ਵਿੱਚ ਕਾਫ਼ੀ ਇਕਸਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਕੋਈ ਇਸਨੂੰ ਇੱਕ ਅਸਲ ਢਲਾਣ ਵਾਲੇ ਹਮਲੇ ਵਿੱਚ ਬਦਲ ਸਕੇ।

sca-ਟੂਲਜ਼-ਸਾਫਟਵੇਅਰ-ਰਚਨਾ-ਵਿਸ਼ਲੇਸ਼ਣ-ਟੂਲਜ਼
ਆਪਣੇ ਸਾਫਟਵੇਅਰ ਜੋਖਮਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ, ਸੁਧਾਰੋ ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਰੋ
ਆਪਣਾ ਮੁਫ਼ਤ ਖਾਤਾ ਪ੍ਰਾਪਤ ਕਰੋ।
ਕੋਈ ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ

ਆਪਣੇ ਸਾਫਟਵੇਅਰ ਵਿਕਾਸ ਅਤੇ ਡਿਲੀਵਰੀ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰੋ

ਜ਼ਾਇਜੇਨੀ ਪ੍ਰੋਡਕਟ ਸੂਟ ਦੇ ਨਾਲ