ਇਹ ਇੱਕ ਵਿੱਚ ਤੀਜਾ ਐਪੀਸੋਡ ਹੈ ਲੇਖਾਂ ਦੀ ਲੜੀ ਸਭ ਤੋਂ ਪ੍ਰਚਲਿਤ ਕਿਸਮ ਦੇ ਸਾਫਟਵੇਅਰ ਸਪਲਾਈ ਚੇਨ ਹਮਲਿਆਂ ਬਾਰੇ: ਉਹ ਜੋ ਜਨਤਕ ਰਜਿਸਟਰੀ ਦੀ ਦੁਰਵਰਤੋਂ ਕਰਦੇ ਹਨ ਓਪਨ-ਸਰੋਤ ਸਾਫਟਵੇਅਰ ਕੰਪੋਨੈਂਟ। ਪਿਛਲੇ ਐਪੀਸੋਡ ਵਿੱਚ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਤੋਂ ਬਾਅਦ “ਖਤਰਨਾਕ ਪੈਕੇਜਾਂ ਦਾ ਸਰੀਰ ਵਿਗਿਆਨ: ਰੁਝਾਨ ਕੀ ਹਨ?"ਕਿਵੇਂ ਬੁਰੇ ਕਾਰਕ ਨਵੇਂ ਜਾਂ ਮੌਜੂਦਾ ਪ੍ਰਕਾਸ਼ਿਤ ਹਿੱਸਿਆਂ ਵਿੱਚ ਖਤਰਨਾਕ ਵਿਵਹਾਰ ਨੂੰ ਇੰਜੈਕਟ ਕਰਦੇ ਹਨ, ਅਸੀਂ ਆਪਣੀਆਂ ਅੱਗ ਬੁਝਾਊ ਜੈਕਟਾਂ ਪਹਿਨਣ ਅਤੇ ਜਾਂਚ ਕਰਨ ਲਈ ਤਿਆਰ ਹਾਂ ਕਿ ਅਸੀਂ ਇਸ ਤਰੀਕੇ ਨਾਲ ਡਿਲੀਵਰ ਕੀਤੇ ਗਏ ਖਤਰਨਾਕ ਸੌਫਟਵੇਅਰ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਕਿਵੇਂ ਰੋਕ ਸਕਦੇ ਹਾਂ, ਜਾਂ ਵਿਕਲਪਕ ਤੌਰ 'ਤੇ, ਇੱਕ ਸੰਭਾਵੀ ਗੰਭੀਰ ਸਾਈਬਰ ਘਟਨਾ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠ ਸਕਦੇ ਹਾਂ ਕਿਉਂਕਿ ਅਸੀਂ ਗਲਤ ਤਰੀਕਾ ਅਪਣਾਇਆ ਹੈ।"
ਜ਼ਿਆਦਾਤਰ ਸੁਰੱਖਿਆ-ਜਾਗਰੂਕ ਪੇਸ਼ੇਵਰਾਂ ਕੋਲ ਇਸ ਖ਼ਤਰੇ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਣਾ ਹੈ ਇਸ ਬਾਰੇ ਵਿਚਾਰ ਹੁੰਦੇ ਹਨ। ਅਸੀਂ ਸੁਰੱਖਿਆ ਪ੍ਰਬੰਧਕਾਂ ਨੂੰ ਬਿਨਾਂ ਝਿਜਕ ਇਹ ਕਹਿੰਦੇ ਸੁਣਿਆ ਹੈ ਕਿ SCA ਟੂਲ ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਪੈਕੇਜ ਵਰਜਨ ਕਦੋਂ ਮਾਲਵੇਅਰ ਹੁੰਦਾ ਹੈ। ਜਾਂ ਇਹ ਕਿ ਉਹ ਜਾਣੇ-ਪਛਾਣੇ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮੀਖਿਆ ਕੀਤੇ ਸੌਫਟਵੇਅਰ ਹਿੱਸਿਆਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਜਿੱਥੇ ਕੋਈ ਵੀ ਮਾਲਵੇਅਰ ਤੁਰੰਤ ਖੋਜਿਆ ਜਾਵੇਗਾ ਅਤੇ ਹਟਾ ਦਿੱਤਾ ਜਾਵੇਗਾ। ਉਹ ਆਪਣੇ ਆਪ ਕਮਜ਼ੋਰੀ ਫਿਕਸ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਓਪਨ ਮਾਈਨਰ/ਪੈਚ ਵਰਜਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ ਓਪਨ ਸੋਰਸ ਨਿਰਭਰਤਾਵਾਂ 'ਤੇ ਜੋਖਮ ਨੂੰ ਘਟਾਉਣ ਦਾ ਸਹੀ, ਸਿਫ਼ਾਰਸ਼ ਕੀਤਾ ਤਰੀਕਾ ਹੈ, "ਜਲਦੀ ਪੈਚ ਕਰੋ, ਅਕਸਰ ਪੈਚ ਕਰੋ”ਸਿਧਾਂਤ.
ਇਸ ਐਪੀਸੋਡ ਵਿੱਚ, ਅਸੀਂ ਸਮੀਖਿਆ ਕਰਾਂਗੇ ਕਿ ਇਹ ਵਿਚਾਰ ਕਿਉਂ ਗਲਤ ਹਨ, ਅਤੇ ਕਿਵੇਂ ਅਜਿਹੀਆਂ ਗਲਤ ਧਾਰਨਾਵਾਂ ਇਸ ਹਮਲੇ ਦੇ ਢੰਗ ਦੀ ਪ੍ਰਸਿੱਧੀ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾ ਰਹੀਆਂ ਹਨ, ਅਤੇ ਸੰਗਠਨਾਂ ਨੂੰ ਇੱਕ ਭਾਰੀ ਜੋਖਮ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ। ਅਸੀਂ ਇਸ ਨਾਲ ਸਮਾਪਤ ਕਰਾਂਗੇ ਕਿ ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਯਤਨ ਅਤੇ ਸਰੋਤ ਕੀ ਹਨ।
ਆਮ ਭੁਲੇਖੇ
ਸਾਫਟਵੇਅਰ ਸੁਰੱਖਿਆ ਦੇ ਨਾਲ ਸਾਡੀ ਯਾਤਰਾ ਦੌਰਾਨ, ਅਸੀਂ ਹਮਲੇ ਦੀਆਂ ਤਕਨੀਕਾਂ ਨੂੰ ਵਿਕਸਤ ਹੁੰਦੇ ਦੇਖਿਆ ਅਤੇ ਸੁਰੱਖਿਆ ਪ੍ਰਤੀ ਜਾਗਰੂਕ ਲੋਕਾਂ ਦੇ ਵਿਚਾਰਾਂ ਦੀ ਇੱਕ ਵਿਸ਼ਾਲ ਸ਼੍ਰੇਣੀ। ਸੰਗਠਨ ਅਕਸਰ ਗਲਤ ਸਮਝਦੇ ਹਨ ਕਿ ਇਸ ਖ਼ਤਰੇ ਦੇ ਵਿਰੁੱਧ ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਪਹਿਲਾਂ ਅਸੀਂ ਜਾਂਚ ਕਰਾਂਗੇ ਕਿ ਕੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ, ਹੇਠਾਂ ਦਿੱਤੀ ਗਈ, ਸੰਪੂਰਨ ਨਹੀਂ, ਗਲਤ ਧਾਰਨਾਵਾਂ ਦੀ ਸੂਚੀ ਵਿੱਚ ਸੰਖੇਪ ਕੀਤਾ ਗਿਆ ਹੈ।
ਗਲਤ ਧਾਰਨਾ #1: SCA ਟੂਲ ਪਹਿਲਾਂ ਹੀ ਖਤਰਨਾਕ ਹਿੱਸਿਆਂ ਦੀ ਰਿਪੋਰਟ ਕਰਦੇ ਹਨ
ਦਰਅਸਲ! ਪਰ ਇਸ ਤੱਥ ਤੋਂ ਬਾਅਦ… ਜਦੋਂ ਸ਼ਾਇਦ ਬਹੁਤ ਦੇਰ ਹੋ ਚੁੱਕੀ ਹੋਵੇ ਜੇਕਰ ਤੱਤ ਨੂੰ ਸਾਫਟਵੇਅਰ ਬਿਲਡ ਵਿੱਚ ਵਰਤਿਆ ਗਿਆ ਹੋਵੇ, ਅਤੇ ਬੁਰੇ ਅਦਾਕਾਰ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਡਿਵੈਲਪਰ ਵਿੱਚ ਪੈਰ ਜਮਾ ਚੁੱਕੇ ਹੋਣ ਜਾਂ CI/CD ਹੋਸਟ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਭੇਦ ਕੱਢ ਦਿੱਤੇ ਗਏ ਹੋਣ, ਵਾਧੂ ਮਾਲਵੇਅਰ ਡਾਊਨਲੋਡ ਅਤੇ ਇੰਸਟਾਲ ਕੀਤੇ ਗਏ ਹੋਣ, ਅਤੇ ਸ਼ਾਇਦ ਵਿਰੋਧੀ ਪਾਸੇ ਵੱਲ ਚਲਾ ਗਿਆ ਹੋਵੇ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਕਿਤੇ ਹੋਰ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰ ਲਈ ਹੋਵੇ।
ਸਾਫਟਵੇਅਰ ਰਚਨਾ ਵਿਸ਼ਲੇਸ਼ਣ (SCA) ਟੂਲ ਸੰਭਾਵੀ ਜਾਣੀਆਂ-ਪਛਾਣੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਸਨ। ਆਧੁਨਿਕ ਟੂਲ ਸਿਗਨਲ-ਸ਼ੋਰ ਅਨੁਪਾਤ ਨੂੰ ਵਧਾ ਕੇ ਇੱਕ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ, ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਕੀ ਕਮਜ਼ੋਰੀ ਅਸਲ ਵਿੱਚ ਪਹੁੰਚਯੋਗ ਹੈ ਜਾਂ ਸ਼ੋਸ਼ਣਯੋਗ ਹੈ। ਪਰ ਉਹ ਨਵੇਂ ਮਾਲਵੇਅਰ ਦੇ ਵਿਰੁੱਧ ਬੇਕਾਰ ਹਨ। ਇੱਕ ਖਤਰਨਾਕ ਹਿੱਸੇ ਨੂੰ ਜ਼ੀਰੋ-ਡੇ ਕਮਜ਼ੋਰੀ ਸਮਝੋ: ਸਿਰਫ਼ ਜਦੋਂ ਇਸਦੇ ਖਤਰਨਾਕ ਵਿਵਹਾਰ ਦਾ ਪਤਾ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਹੀ ਹਿੱਸੇ ਨੂੰ ਹੋਲਡਿੰਗ ਰਜਿਸਟਰੀ ਨੂੰ ਰਿਪੋਰਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸਦੀ ਸੁਰੱਖਿਆ ਟੀਮ ਦੁਆਰਾ ਸਮੀਖਿਆ ਤੋਂ ਬਾਅਦ ਖਤਰਨਾਕ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਰਜਿਸਟਰੀ ਤੋਂ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। [1].
ਉਸ ਸਮੇਂ, ਦੁਨੀਆਂ (ਸਮੇਤ SCAs) ਜਾਣਦਾ ਹੈ ਕਿ ਕੰਪੋਨੈਂਟ (ਜਾਂ ਮੌਜੂਦਾ ਕੰਪੋਨੈਂਟ ਦੇ ਕੁਝ ਸੰਸਕਰਣ) ਨੂੰ ਸਥਾਪਤ ਕਰਨਾ ਜਾਂ ਵਰਤਣਾ ਚੰਗੀ ਗੱਲ ਨਹੀਂ ਹੈ। ਪਰ ਇਹ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੰਪੋਨੈਂਟ ਰਜਿਸਟਰੀ ਤੋਂ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦਾ. ਇਹ ਜਾਣਨਾ ਚੰਗਾ ਹੈ ਕਿ ਮੇਰੇ ਕੋਲ ਤੀਜੀ-ਧਿਰ ਦੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਕਮਜ਼ੋਰੀਆਂ ਹਨ, ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ ਉਹ ਹਿੱਸੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਰਜਿਸਟਰੀ ਦੁਆਰਾ ਖਤਰਨਾਕ ਵਜੋਂ ਸ਼੍ਰੇਣੀਬੱਧ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਬਦਕਿਸਮਤੀ ਨਾਲ SCA ਜਾਂ ਆਮ ਆਡਿਟ ਟੂਲ ਇਸ ਸੰਦਰਭ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦੇ। ਜਦ ਤੱਕ SCA/audit ਟੂਲ ਅਸਲ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਜਾਣ ਸਕਦਾ ਹੈ ਕਿ ਕੋਈ ਕੰਪੋਨੈਂਟ ਤੁਹਾਡੇ ਸੰਗਠਨ ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਖਤਰਨਾਕ ਹੈ।.
ਯਾਦ ਰੱਖੋ, ਖਤਰਨਾਕ ਓਪਨ-ਸੋਰਸ ਕੰਪੋਨੈਂਟਸ ਦੇ ਵਿਰੁੱਧ ਕਿਸੇ ਵੀ ਹੱਲ ਲਈ ਉਹਨਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣਾ ਲਾਜ਼ਮੀ ਹੈ ਫਲਾਈ 'ਤੇ, ਜਦੋਂ ਕੰਪੋਨੈਂਟ ਰਜਿਸਟਰੀ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਕੰਪੋਨੈਂਟ (ਵਰਜਨ) ਪਹਿਲੀ ਵਾਰ ਤੁਹਾਡੀ ਸੰਸਥਾ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਦੇ ਵਿਚਕਾਰ। ਅਤੇ ਇਸ ਵਿੱਚ ਟਰਾਂਜ਼ਿਟਿਵ ਕੰਪੋਨੈਂਟ ਸ਼ਾਮਲ ਹਨ।
ਗਲਤ ਧਾਰਨਾ #2: ਬਿਲਡ ਸਮੇਂ ਇੰਸਟਾਲੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨਾ ਓਪਨ-ਸੋਰਸ ਕੰਪੋਨੈਂਟਸ ਤੋਂ ਖਤਰਨਾਕ ਵਿਵਹਾਰ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਕਈ ਪੈਕੇਜ ਮੈਨੇਜਰ ਸਕ੍ਰਿਪਟਾਂ ਚਲਾਉਣ ਦੀ ਸਮਰੱਥਾ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ (ਕੰਪੋਨੈਂਟ ਟਾਰਬਾਲ ਵਿੱਚ ਸ਼ਾਮਲ) [2]), ਜਾਇਜ਼ ਕਾਰਨਾਂ ਕਰਕੇ, ਜਿਵੇਂ ਕਿ ਵੱਖ-ਵੱਖ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਲੋੜੀਂਦੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਕੰਪਾਇਲ ਕਰਨਾ, ਕੋਡ ਤਿਆਰ ਕਰਨਾ, ਜਾਂ ਟੈਸਟ ਚਲਾਉਣਾ, ਅਤੇ ਸਾਨੂੰ ਸਾਰਿਆਂ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਜੇਕਰ ਖਤਰਨਾਕ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਟਾਰਬਾਲ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਜੇਕਰ ਹਮਲਾਵਰ ਚੰਗੀ ਦੀ ਬਜਾਏ ਇੱਕ ਖਤਰਨਾਕ ਸਕ੍ਰਿਪਟ ਚਲਾ ਸਕਦਾ ਹੈ ਤਾਂ ਮਾੜੇ ਅਦਾਕਾਰਾਂ ਦੁਆਰਾ ਉਹਨਾਂ ਦੀ ਦੁਰਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।
ਇਹ ਜਾਣਦੇ ਹੋਏ, ਅਸੀਂ ਪੈਕੇਜ ਮੈਨੇਜਰ ਨੂੰ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਲਈ ਕੌਂਫਿਗਰ ਕਰ ਸਕਦੇ ਹਾਂ। ਉਦਾਹਰਣ ਵਜੋਂ, NPM ਨਾਲ - ਅਣਡਿੱਠ-ਸਕ੍ਰਿਪਟਾਂ ਫਲੈਗ (ਜਾਂ ਵਿੱਚ ਇੱਕ ਸੰਰਚਨਾ ਵਿਸ਼ੇਸ਼ਤਾ .npmrc ਫਾਈਲ) ਇੰਸਟਾਲੇਸ਼ਨ ਦੌਰਾਨ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਇਸ ਨਾਲ ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋ ਸਕਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਸਕ੍ਰਿਪਟਾਂ ਚਲਾਉਣਾ ਬਹੁਤ ਸਾਰੇ ਈਕੋਸਿਸਟਮ ਵਿੱਚ ਆਮ ਹੈ: ਕੁਝ ਪੈਕੇਜ ਮੈਨੇਜਰ ਸਕ੍ਰਿਪਟ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਅਯੋਗ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਵੀ ਨਹੀਂ ਦਿੰਦੇ ਹਨ (ਸੰਕੇਤ: ਪ੍ਰੋਂਪਟ “ਕਿਹੜੇ ਪੈਕੇਜ ਮੈਨੇਜਰ ਇੰਸਟਾਲ ਸਕ੍ਰਿਪਟਾਂ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਅਯੋਗ ਕਰਨ ਦੀ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦੇ?"ਤੁਹਾਡੇ ਮਨਪਸੰਦ AI ਵਿੱਚ)। ਪਰ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਆ ਨਹੀਂ ਕਰਦਾ (ਸਾਨੂੰ ਇਹ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਸਕਿੱਪ ਡਿਸਏਬਲ ਕੌਂਫਿਗਰੇਸ਼ਨ ਹਰ ਜਗ੍ਹਾ ਹੋਵੇ)।
ਅਤੇ ਜਦੋਂ ਖਤਰਨਾਕ ਵਿਵਹਾਰ ਇੰਸਟਾਲ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਨਹੀਂ ਸਗੋਂ ਰਨਟਾਈਮ 'ਤੇ ਚਲਾਉਣ ਵਾਲੇ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਵਿਕਲਪ ਹੀ ਸਾਡੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰਦਾ।
ਗਲਤ ਧਾਰਨਾ #3: ਵਰਜਨ ਪਿੰਨਿੰਗ ਖਤਰਨਾਕ ਹਿੱਸਿਆਂ ਨੂੰ ਸਥਾਪਤ ਹੋਣ ਤੋਂ ਰੋਕਦੀ ਹੈ
ਜਲਦੀ ਪੈਚਿੰਗ ਅਤੇ ਅਕਸਰ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਸਮਝੌਤਾ ਹੁੰਦਾ ਹੈ ਖੁੱਲ੍ਹੇ ਸੰਸਕਰਣ (ਸੁਰੱਖਿਆ ਫਿਕਸ ਲਈ ਉਪਲਬਧ ਹੋਣ 'ਤੇ ਪੈਕੇਜ ਮੈਨੇਜਰ ਨੂੰ ਆਪਣੇ ਆਪ ਨਵੇਂ ਅੱਪਡੇਟ ਸਥਾਪਤ ਕਰਨ ਦੇਣਾ) ਅਤੇ ਵਰਜਨ ਪਿੰਨਿੰਗ (ਇੱਕ ਸਥਿਰ ਸੰਸਕਰਣ 'ਤੇ ਇੱਕ ਸਾਫਟਵੇਅਰ ਲਈ ਸਾਰੀਆਂ ਸਿੱਧੀਆਂ ਅਤੇ ਪਰਿਵਰਤਨਸ਼ੀਲ ਨਿਰਭਰਤਾਵਾਂ ਹੋਣ)। ਸੁਰੱਖਿਆ ਸਿਧਾਂਤ ਜ਼ਿੱਦੀ ਹਨ ਅਤੇ ਕਈ ਵਾਰ ਵਿਰੋਧੀ ਹਨ, ਜਿਵੇਂ ਕਿ "ਪੈਚ ਜਲਦੀ, ਪੈਚ ਅਕਸਰ" ਨਾਲ ਹੁੰਦਾ ਹੈ ਅਤੇ "ਅੱਪਗ੍ਰੇਡ ਨੂੰ ਹਲਕੇ ਵਿੱਚ ਨਹੀਂ ਲਿਆ ਜਾਣਾ ਚਾਹੀਦਾ". ਕੁਝ ਪੈਕੇਜ ਮੈਨੇਜਰ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੇ ਤਰੀਕੇ ਨਾਲ ਸਰਵਰ ਰੇਂਜਾਂ ਨਾਲ ਆਟੋਮੈਟਿਕ ਅੱਪਡੇਟ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਵੀ ਖਤਰਨਾਕ ਅੱਪਡੇਟ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਬਹੁਤ ਵਧੀਆ! ਹਾਂ, ਸੁਰੱਖਿਆ ਫਿਕਸ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕੰਪੋਨੈਂਟਸ ਨੂੰ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਜਲਦੀ ਤੋਂ ਜਲਦੀ ਬੰਦ ਕਰਦੇ ਹਨ, ਪਰ ... ਪੈਕੇਜ ਮੈਨੇਜਰ ਨੂੰ ਕਦੇ ਵੀ ਇਹ ਆਪਣੇ ਆਪ ਨਹੀਂ ਕਰਨ ਦਿਓ।
ਗਲਤ ਧਾਰਨਾ #4: ਭਰੋਸੇਯੋਗ ਹਿੱਸਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੁਰੱਖਿਅਤ ਹੈ। ਕੋਈ ਵੀ ਖਤਰਨਾਕ ਸੰਸਕਰਣ ਤੁਰੰਤ ਲੱਭਿਆ ਜਾਵੇਗਾ, ਪ੍ਰਗਟ ਕੀਤਾ ਜਾਵੇਗਾ ਅਤੇ ਹਟਾ ਦਿੱਤਾ ਜਾਵੇਗਾ।
ਇੱਕ ਹਿੱਸੇ 'ਤੇ ਭਰੋਸਾ ਕਿਉਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ? ਸ਼ਾਇਦ ਇਸ ਲਈ ਕਿਉਂਕਿ ਇਹ ਬਹੁਤ ਮਸ਼ਹੂਰ ਹੈ, ਬਹੁਤ ਸਾਰੀਆਂ ਅੱਖਾਂ ਕਮਜ਼ੋਰੀਆਂ ਦੀ ਭਾਲ ਵਿੱਚ ਹਨ, ਰੱਖ-ਰਖਾਅ ਲਈ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਣ ਵਾਲੇ, ਕਈ ਮੁੱਖ ਰੱਖ-ਰਖਾਅ ਕਰਨ ਵਾਲੇ ਜੋ ਸਾਰੇ pull requests. ਹਕੀਕਤ ਬਿਲਕੁਲ ਵੱਖਰੀ ਹੈ। ਕੁਝ ਜ਼ਰੂਰੀ ਹਿੱਸਿਆਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ, ਬਿਨਾਂ ਭੁਗਤਾਨ ਕੀਤੇ ਡਿਵੈਲਪਰ ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ। ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤੇ ਜਾਂਦੇ ਫਰੇਮਵਰਕ ਵਿੱਚ ਕੁਝ ਨਿਯਮਤ ਯੋਗਦਾਨ ਪਾਉਣ ਵਾਲੇ, ਤੇਜ਼ੀ ਨਾਲ ਘਟਦੀ ਗਿਣਤੀ ਦੇ ਨਾਲ commitਪ੍ਰਤੀ ਰੱਖਿਅਕ (ਪ੍ਰਸਿੱਧ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਣ ਵਾਲਿਆਂ ਦੀ ਇੱਕ ਲੰਬੀ ਪੂਛ ਹੁੰਦੀ ਹੈ ਜੋ ਕੁਝ ਡਰਾਈਵ-ਬਾਈ ਕਰਦੇ ਹਨ) commit ਅਤੇ ਕਦੇ ਵਾਪਸ ਨਹੀਂ ਆਉਣਾ)। ਅਤੇ ਇੱਕ ਸਿੰਗਲ ਮੇਨਟੇਨਰ ਵਾਲੇ ਪ੍ਰਸਿੱਧ ਪ੍ਰੋਜੈਕਟ ਬਹੁਤ ਹਨ।
ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਖੁਦ ਕਹਿ ਰਹੇ ਹੋ "ਓਹ, ਅਸੀਂ ਸਪਰਿੰਗ ਬੂਟ / ਐਂਗੂਲਰ / ਰੀਐਕਟ / ਪਾਈਟੋਰਚ / ਅਧਿਕਾਰਤ ਬੇਸ ਡੌਕਰ ਚਿੱਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਾਂ, ਇਸ ਲਈ ਜਿਸ ਜੋਖਮ ਬਾਰੇ ਤੁਸੀਂ ਗੱਲ ਕਰ ਰਹੇ ਹੋ ਉਹ ਕਾਫ਼ੀ ਘੱਟ ਹੈ।" ਸ਼ਾਇਦ ਇਹ ਸੱਚ ਹੈ, ਅਸੀਂ ਸੁਰੱਖਿਆ ਵਿਕਰੇਤਾ ਹਰ ਸਮੇਂ ਡਰਾਉਣ-ਧਮਕਾਉਣ ਵਾਲੇ ਕੰਮ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਇੱਕ ਬਹਿਸਯੋਗ ਜੋਖਮ ਨੂੰ ਘਟਾਉਣ ਲਈ ਵਿਕਾਸ ਟੀਮਾਂ ਵਿੱਚ ਦਖਲ ਦੇਣਾ ਬਕਵਾਸ ਹੈ। ਤੁਸੀਂ ਜੋਖਮ ਸਵੀਕ੍ਰਿਤੀ ਪੈਰਾਗ੍ਰਾਫ (ਅਗਲੇ ਭਾਗ ਵਿੱਚ) ਤੇ ਜਾਣ ਲਈ ਪਰਤਾਏ ਹੋ ਸਕਦੇ ਹੋ ਅਤੇ ਸਭ ਕੁਝ ਹੋ ਗਿਆ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਹਿੱਸੇ ਮਾੜੇ ਅਦਾਕਾਰਾਂ ਲਈ ਨਿਸ਼ਾਨਾ ਹਨ, ਅਤੇ ਉਦਾਹਰਣ ਵਜੋਂ, ਪ੍ਰਸਿੱਧ ਪਾਈਟੋਰਚ ਲਾਇਬ੍ਰੇਰੀ 'ਤੇ ਹਮਲਾ ਹੋਇਆ ਸੀ। ਅਤੀਤ ਵਿੱਚ.
"ਤੁਰੰਤ ਲੱਭਿਆ, ਖੁਲਾਸਾ ਕੀਤਾ, ਅਤੇ ਹਟਾਇਆ ਗਿਆ"। ਜਨਤਕ ਰਜਿਸਟਰੀ ਤੋਂ ਇੱਕ ਨਵੇਂ ਖਤਰਨਾਕ ਹਿੱਸੇ ਨੂੰ ਹਟਾਉਣ ਲਈ ਦਿਨ ਲੱਗਦੇ ਹਨ। ਰਜਿਸਟਰੀਆਂ ਇੱਕ ਕੰਪੋਨੈਂਟ ਸੰਸਕਰਣ ਨੂੰ ਹਟਾਉਣ ਬਾਰੇ ਸਾਵਧਾਨ ਰਹਿੰਦੀਆਂ ਹਨ, ਚੰਗੇ ਲਈ। ਸਾਡਾ ਤਜਰਬਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਵਾਰ ਸਾਡੇ ਵੱਲੋਂ ਰਿਪੋਰਟ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਪ੍ਰਭਾਵਿਤ ਸੰਸਕਰਣ ਨੂੰ ਹਟਾਉਣ ਲਈ ਰਜਿਸਟਰੀ ਲਈ ਔਸਤ ਸਮਾਂ 39 ਘੰਟੇ ਹੁੰਦਾ ਹੈ, ਡੇਢ ਦਿਨ ਤੋਂ ਵੱਧ। ਕੁਝ ਖਤਰਨਾਕ ਹਿੱਸੇ ਹਨ ਜੋ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਰਜਿਸਟਰੀ ਵਿੱਚ ਸਾਡੀ ਸ਼ੁਰੂਆਤੀ ਰਿਪੋਰਟਿੰਗ ਤੋਂ ਇੱਕ ਹਫ਼ਤੇ ਬਾਅਦ ਹੁੰਦੇ ਹਨ। ਅਤੇ ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਕੰਪੋਨੈਂਟ ਨੂੰ ਉਦੋਂ ਹੀ ਹਟਾਇਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਪੀੜਤ ਜਾਂ ਘਟਨਾ ਪ੍ਰਤੀਕਿਰਿਆ ਕੰਪਨੀ ਕੰਪੋਨੈਂਟ ਨਾਲ ਸਬੰਧਤ ਘਟਨਾ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ।
ਖਤਰਨਾਕ ਹਿੱਸਿਆਂ ਦੇ ਵਿਰੁੱਧ ਕੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ
ਕੋਈ ਵੀ ਅਣ-ਵਿਸ਼ੇਸ਼ ਪਹੁੰਚ ਬੁਰੀ ਤਰ੍ਹਾਂ ਅਸਫਲ ਹੋਵੇਗੀ। ਇਹ ਯਕੀਨੀ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ ਖਤਰੇ ਨਾਲ ਜੁੜੇ ਜੋਖਮ ਲਈ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਪ੍ਰਤੀਰੋਧੀ ਉਪਾਅ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰ ਰਹੇ ਹੋ।
ਪਾਰੰਪਰਕ SCA ਟੂਲ ਤੁਹਾਨੂੰ ਜਾਣੇ-ਪਛਾਣੇ ਮਾਲਵੇਅਰ ਬਾਰੇ ਦੱਸਦੇ ਹਨ ਪਰ ਉਹਨਾਂ ਕੋਲ ਇੱਕ ਵੱਡੀ ਐਕਸਪੋਜ਼ਰ ਵਿੰਡੋ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਤੱਕ ਉਹ ਖਤਰਨਾਕ ਹਿੱਸਿਆਂ ਨੂੰ ਜ਼ਬਰਦਸਤੀ ਬਲਾਕ ਕਰਨ ਦੇ ਨਾਲ ਮਾਲਵੇਅਰ ਖੋਜ ਨੂੰ ਸਰਗਰਮੀ ਨਾਲ ਨਹੀਂ ਕਰ ਰਹੇ ਹੁੰਦੇ, ਉਹ ਇਸ ਖਤਰੇ ਦੇ ਵਿਰੁੱਧ ਕੰਮ ਨਹੀਂ ਕਰਦੇ।
ਇੰਸਟਾਲੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਅਯੋਗ ਕਰਨ ਨਾਲ ਮਦਦ ਮਿਲ ਸਕਦੀ ਹੈ ਪਰ ਇਸਨੂੰ ਹਰ ਥਾਂ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਜਿੱਥੇ ਇੱਕ ਕੰਪੋਨੈਂਟ ਨੂੰ ਇੰਸਟਾਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਵਰਜਨ ਪਿੰਨਿੰਗ ਦੇ ਨਾਲ ਵੀ ਇਹੀ ਹੈ, ਕਿਉਂਕਿ ਵਰਜਨਾਂ ਨੂੰ ਹਮੇਸ਼ਾ ਲਈ ਸੁਰੱਖਿਅਤ ਸ਼ੁਰੂਆਤੀ ਸਥਿਤੀ ਤੋਂ ਪਿੰਨ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।
ਇਹ ਮੰਨ ਕੇ ਕਿ ਪ੍ਰਸਿੱਧ ਹਿੱਸਿਆਂ ਨੂੰ ਇੰਨਾ ਧਿਆਨ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਸਪਲਾਈ ਚੇਨ ਹਮਲੇ ਵਿੱਚ ਕਿਸੇ ਵੀ ਨੁਕਸਾਨ ਨੂੰ ਰੋਕਣ ਲਈ ਲਗਭਗ ਤੁਰੰਤ ਖੋਜ ਕੀਤੇ ਬਿਨਾਂ ਅਣਇੱਛਤ ਵਿਵਹਾਰ ਨਾਲ ਨਹੀਂ ਲਗਾਇਆ ਜਾ ਸਕਦਾ, ਇਹ ਭੋਲਾਪਣ ਅਤੇ ਜੋਖਮ ਭਰਿਆ ਹੈ। ਤੁਸੀਂ ਕਿਨਾਰੇ 'ਤੇ ਨਹੀਂ ਰਹਿਣਾ ਚਾਹੁੰਦੇ, ਹੈ ਨਾ?
ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਬਿੰਦੂ 'ਤੇ ਰੁਕ ਜਾਂਦੇ ਹੋ, ਤਾਂ ਜੋਖਮ ਸਵੀਕ੍ਰਿਤੀ ਇਹੀ ਇੱਕੋ ਇੱਕ ਚੀਜ਼ ਹੈ ਜੋ ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ: ਇਹ ਇੱਕ ਡੀ ਹੈcisਤੁਹਾਡੇ ਖ਼ਤਰੇ ਦੇ ਮਾਡਲ/ਜੋਖਮ ਮੁਲਾਂਕਣ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਜਿਸ ਵਿੱਚ ਜੋਖਮ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਦੇ ਤਰਕ ਅਤੇ ਇਸਦੇ ਸੰਭਾਵੀ ਪ੍ਰਭਾਵਾਂ ਸ਼ਾਮਲ ਹਨ। ਪ੍ਰਬੰਧਨ ਅਤੇ ਹੋਰ ਸੰਬੰਧਿਤ ਧਿਰਾਂ ਨੂੰ ਇਸ ਬਾਰੇ ਦੱਸ ਕੇ ਜਾਗਰੂਕਤਾ ਵਧਾਓ। ਕੁਝ ਸੰਕਟਕਾਲੀਨ ਜਦੋਂ ਕੋਈ ਖਤਰਨਾਕ ਕੰਪੋਨੈਂਟ ਤੁਹਾਡੇ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਸਥਾਪਿਤ ਜਾਂ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਯੋਜਨਾ ਬਣਾਈ ਜਾ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਮੁਸ਼ਕਲ ਹੈ ਕਿਉਂਕਿ ਹਮਲਾਵਰਾਂ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਰਸਤੇ ਹਨ। ਇੱਕ ਖਤਰਨਾਕ ਕੰਪੋਨੈਂਟ ਦੀ ਵਰਤੋਂ ਦੇ ਅਧਾਰ ਤੇ ਸਪਲਾਈ ਚੇਨ ਹਮਲੇ ਦੇ ਵੇਰਵੇ ਘਟਨਾ ਦੇ ਜਨਤਕ ਖੁਲਾਸੇ ਨੂੰ ਬਹੁਤ ਬਦਲ ਦੇਣਗੇ, ਜੋ ਕਿ ਸ਼ਾਇਦ ਤੁਹਾਡੇ ਸੰਗਠਨ ਦੇ ਰੈਗੂਲੇਟਰੀ ਢਾਂਚੇ ਦੇ ਅਧੀਨ ਲਾਜ਼ਮੀ ਹੈ। ਤੁਸੀਂ ਇਹ ਵੀ ਸੰਬੋਧਨ ਕਰ ਸਕਦੇ ਹੋ ਮੁਆਵਜ਼ਾ ਦੇਣ ਵਾਲੇ ਨਿਯੰਤਰਣ or ਟ੍ਰਾਂਸਫਰ ਜੋਖਮ ਜਿਵੇਂ ਕਿ ਬੀਮੇ ਦੇ ਨਾਲ।
ਹਾਲਾਂਕਿ, ਕੁਝ ਨਿਯੰਤਰਣ ਹਨ ਜੋ ਖ਼ਤਰੇ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦੇ ਹਨ ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਜੋਖਮ ਸਵੀਕ੍ਰਿਤੀ ਤੋਂ ਸੰਤੁਸ਼ਟ ਨਹੀਂ ਹੋ ਤਾਂ ਇਹਨਾਂ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਕਿਰਪਾ ਕਰਕੇ ਅੱਗੇ ਪੜ੍ਹੋ।
ਖਤਰਨਾਕ ਹਿੱਸਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹਮਲਿਆਂ ਦੇ ਵਿਰੁੱਧ ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ?
ਠੋਸ ਵਰਜਨ ਹੈਂਡਲਿੰਗ
ਨਿਯੰਤਰਿਤ ਅਤੇ ਸੂਚਿਤ ਵਰਜਨ ਬੰਪਾਂ ਨਾਲ ਵਰਜਨ ਪਿੰਨਿੰਗ ਕਰਨਾ ਮਾਲਵੇਅਰ ਪ੍ਰਾਪਤ ਕੀਤੇ ਬਿਨਾਂ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਹਟਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ। ਪਰ ਗਲਤ ਧਾਰਨਾ #3 ਯਾਦ ਰੱਖੋ: ਨਵੇਂ ਸੰਸਕਰਣਾਂ ਤੋਂ ਆਉਣ ਵਾਲੇ ਖਤਰਨਾਕ ਕੋਡ ਨੂੰ ਰੋਕਣ ਲਈ ਸਿਰਫ਼ ਵਰਜਨ ਪਿੰਨਿੰਗ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਭਵਿੱਖ ਵਿੱਚ ਕਿਸੇ ਵੀ ਸਿੱਧੇ ਜਾਂ ਅਸਿੱਧੇ ਨਿਰਭਰਤਾ ਵਿੱਚ ਵਰਜਨਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ। ਉਸ ਸਮੇਂ ਤੁਹਾਨੂੰ ਇੰਨੇ ਮਜ਼ਬੂਤ ਸਬੂਤ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਸਾਰੇ ਸੋਧੇ ਹੋਏ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਮਾਲਵੇਅਰ ਨਹੀਂ ਹੈ।
ਸ਼ੁਰੂਆਤੀ ਚੇਤਾਵਨੀ
ਖਤਰਨਾਕ ਹਿੱਸਿਆਂ ਦੀ ਸਮੱਸਿਆ ਦਾ ਇੱਕ ਤਰੀਕਾ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਚੇਤਾਵਨੀ ਪ੍ਰਣਾਲੀ ਹੈ (ਇੱਥੇ ਨਾਮ ਦਿੱਤਾ ਗਿਆ ਹੈ ਮਾਲਵੇਅਰ ਸੰਬੰਧੀ ਜਲਦੀ ਚੇਤਾਵਨੀ ਜਾਂ MEW), ਜਿੱਥੇ ਪ੍ਰਕਾਸ਼ਿਤ ਨਵੇਂ ਸੰਸਕਰਣਾਂ (ਨਵੇਂ ਜਾਂ ਮੌਜੂਦਾ ਹਿੱਸਿਆਂ ਲਈ) ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਇੱਕ ਖੋਜ ਇੰਜਣ ਦੁਆਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਕਿ ਜਦੋਂ ਕਾਫ਼ੀ ਸਬੂਤ ਮਿਲ ਜਾਂਦੇ ਹਨ ਤਾਂ ਨਵੇਂ ਸੰਸਕਰਣ ਨੂੰ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਖਤਰਨਾਕ ਵਜੋਂ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰ ਸਕਦਾ ਹੈ।
ਇੱਥੇ ਆਟੋਮੇਸ਼ਨ ਜ਼ਰੂਰੀ ਹੈ, ਕਿਉਂਕਿ ਮੌਜੂਦਾ ਪ੍ਰਕਾਸ਼ਨ ਦਰ 'ਤੇ ਸਾਰੇ ਨਵੇਂ ਹਿੱਸਿਆਂ ਦੀ ਹੱਥੀਂ ਸਮੀਖਿਆ ਕਰਨਾ ਅਸੰਭਵ ਹੈ। ਇਸ ਲਈ ਖੋਜ ਇੰਜਣ ਨੂੰ ਕਈ ਤਰ੍ਹਾਂ ਦੀਆਂ ਤਕਨੀਕਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਜਿਸ ਵਿੱਚ ਸ਼ਾਇਦ ਸਥਿਰ, ਗਤੀਸ਼ੀਲ, ਅਤੇ ਸਮਰੱਥਾ ਵਿਸ਼ਲੇਸ਼ਣ, ਉਪਭੋਗਤਾ ਪ੍ਰਤਿਸ਼ਠਾ, ਅਤੇ ਕੰਪੋਨੈਂਟ ਮੈਟਾਡੇਟਾ ਅਤੇ ਟਾਰਬਾਲ ਸਮੱਗਰੀ ਦੇ ਵਿਚਕਾਰ, ਜਾਂ ਟਾਰਬਾਲ ਅਤੇ ਸਰੋਤ ਰਿਪੋਜ਼ਟਰੀ ਦੇ ਵਿਚਕਾਰ ਅੰਤਰ ਤੋਂ ਆਉਣ ਵਾਲੇ ਸਬੂਤ ਸ਼ਾਮਲ ਹਨ ਜਿੱਥੋਂ ਕੰਪੋਨੈਂਟ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।
ਇੱਥੇ ਇੱਕ ਹੈ ਡਾਰਕ ਜ਼ੋਨ ਪ੍ਰਕਾਸ਼ਨ ਸਮੇਂ ਅਤੇ ਇੰਜਣ ਦੁਆਰਾ ਕੰਪੋਨੈਂਟ ਸਮੱਗਰੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਦੇ ਸਮੇਂ ਦੇ ਵਿਚਕਾਰ, ਪਰ ਇਹ ਕੁਝ ਮਿੰਟਾਂ ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਸਕੀਮ ਨੂੰ ਸੋਧਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਣ ਵਜੋਂ ਨਵੇਂ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਇੰਸਟਾਲ ਕਰਨ ਅਤੇ ਸਾਫਟਵੇਅਰ ਬਿਲਡ ਵਿੱਚ ਵਰਤਣ ਦੀ ਆਗਿਆ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤੇ ਜਾਣ ਦੀ ਉਡੀਕ ਕਰਕੇ। pipelines, ਜਾਂ ਲੋੜ ਪੈਣ 'ਤੇ ਮੰਗ 'ਤੇ ਉਹਨਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ। ਦਿੱਤੇ ਗਏ ਸੰਸਕਰਣ 'ਤੇ ਇੱਕ ਭਾਗ ਅਟੱਲ ਹੈ [3], ਇਸ ਲਈ ਇਸਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
ਪੂਰਾ ਆਟੋਮੇਸ਼ਨ ਸੰਭਵ ਨਹੀਂ ਹੈ, ਅਤੇ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਖਤਰਨਾਕ ਹਿੱਸਿਆਂ ਲਈ ਸੁਰੱਖਿਆ ਸਮੀਖਿਆ ਦੀ ਲੋੜ ਹੈ। ਡਿਜੀਟਲ ਰਾਮਬਾਣ ਦੇ ਸਮਰਥਕਾਂ ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ: ਏਆਈ ਅਤੇ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਇੰਨੇ ਵਿਕਸਤ ਨਹੀਂ ਹਨ ਕਿ ਜਦੋਂ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ ਕਿ ਕੀ ਕਿਸੇ ਸ਼ੱਕੀ ਹਿੱਸੇ ਵਿੱਚ ਮਾਲਵੇਅਰ ਹੈ, ਤਾਂ ਆਖਰੀ ਸ਼ਬਦ ਲੈਣ ਲਈ। ਯਕੀਨਨ, ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਕੈਪਚਰ ਕੀਤੇ ਗਏ ਕੱਚੇ ਸਬੂਤਾਂ ਤੋਂ ਇਨਪੁਟ ਹਿੱਸੇ ਨੂੰ ਵਰਗੀਕ੍ਰਿਤ ਕਰਨ ਵਿੱਚ ਖੋਜ ਇੰਜਣ ਵਿੱਚ ਇੱਕ ਮੁੱਖ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦੀ ਹੈ, ਪਰ ਇੱਕ ਵਾਰ ਜਦੋਂ ਭਾਗ "ਕੁਆਰੰਟੀਨ" ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਆਖਰੀ ਸ਼ਬਦ ਇੱਕ ਸੁਰੱਖਿਆ ਟੀਮ ਦੁਆਰਾ ਮੈਨੂਅਲ ਸਮੀਖਿਆ 'ਤੇ ਹੁੰਦਾ ਹੈ ਜਿਸ ਕੋਲ ਖਤਰਨਾਕ ਹਿੱਸਿਆਂ ਵਿੱਚ ਤਜਰਬਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਕਿਸੇ ਵੀ ਸੰਭਾਵੀ ਮਾਲਵੇਅਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਜਾਂ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਵਜੋਂ ਦੁਬਾਰਾ ਵਰਗੀਕ੍ਰਿਤ ਕਰਦਾ ਹੈ। ਅਤੇ ਸਮਾਂ ਮਿਆਦ ਘੰਟਿਆਂ ਦੀ ਸੀਮਾ ਵਿੱਚ ਹੈ।
ਰਜਿਸਟਰੀ ਖਤਰਨਾਕ ਸੰਸਕਰਣ/ਭਾਗ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ; ਫਿਰ ਰਜਿਸਟਰੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਆਪਣੀ ਸਮੀਖਿਆ ਕਰਦੀ ਹੈ ਅਤੇ ਜਨਤਕ ਖੁਲਾਸੇ ਅਤੇ ਰਜਿਸਟਰੀ ਤੋਂ ਹਟਾਉਣ ਲਈ ਅੱਗੇ ਵਧਦੀ ਹੈ। ਕੁਝ ਰਜਿਸਟਰੀਆਂ ਇੱਕ ਸੁਰੱਖਿਆ ਹੋਲਡਿੰਗ ਪੈਕੇਜ ਰੱਖਦੀਆਂ ਹਨ। ਇੱਥੇ ਸਮਾਂ ਸੀਮਾ ਪ੍ਰਕਾਸ਼ਨ ਤੋਂ ਬਾਅਦ ਦੇ ਦਿਨ ਜਾਂ ਹਫ਼ਤੇ ਹਨ, ਜੋ ਕਿ 'ਰਹਿਣ ਦਾ ਸਮਾਂ'ਜਾਂ'ਐਕਸਪੋਜ਼ਰ ਵਿੰਡੋ'ਜ਼ਿਆਦਾਤਰ ਖਤਰਨਾਕ ਹਿੱਸਿਆਂ ਲਈ।'
ਕੀ ਇਹ ਜਾਣਨਾ ਸੰਭਵ ਹੈ ਕਿ ਕੀ ਕੋਈ ਕੰਪੋਨੈਂਟ ਵਰਜਨ ਖਤਰਨਾਕ ਹੈ?
ਇਸ ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਚੇਤਾਵਨੀ ਦੇਣ ਲਈ, ਸਾਨੂੰ ਇਸ ਸਵਾਲ ਦਾ ਇੱਕ ਤਸੱਲੀਬਖਸ਼ ਜਵਾਬ ਦੇਣ ਦੀ ਲੋੜ ਹੈ: ਮੈਂ ਕਿਵੇਂ ਜਾਣ ਸਕਦਾ ਹਾਂ ਕਿ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਜਾਂ ਪੈਕੇਜ ਖਤਰਨਾਕ ਹੈ (ਨਹੀਂ)? ਖਤਰਨਾਕ ਵਿਵਹਾਰ ਦੇ ਕਾਫ਼ੀ ਸਬੂਤ ਕਿਵੇਂ ਇਕੱਠੇ ਕਰੀਏ? ਸੰਭਵ ਹੈ, ਪਰ ਮੁਸ਼ਕਲ ਹੈ, ਕਿਉਂਕਿ ਵਿਰੋਧੀ ਖੋਜ ਤੋਂ ਬਚਣ ਲਈ ਬਹੁਤ ਚਤੁਰਾਈ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਵੱਖੋ-ਵੱਖਰੇ ਤਰੀਕੇ ਹਨ, ਹਰੇਕ ਦੇ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨ ਹਨ।
ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਹਮਲਾਵਰਾਂ ਦੁਆਰਾ ਵਰਤੇ ਗਏ ਤਕਨੀਕਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਵਾਲੇ ਸਾਰੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਮਾਰਗਾਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ, ਬਿਨਾਂ ਕੰਪੋਨੈਂਟ ਚਲਾਏ, ਅਤੇ ਡੀ-ਅਬਫਸਕੇਸ਼ਨ ਜਾਂ ਡਿਸੀਫਰਿੰਗ ਵਰਗੇ ਪ੍ਰੀਪ੍ਰੋਸੈਸਿੰਗ ਕਾਰਜ ਕਰ ਸਕਦਾ ਹੈ। ਜਿਵੇਂ ਕਿ ਹਮਲਾਵਰ ਆਪਣੀ ਸ਼ਰਾਰਤ ਨੂੰ ਛੁਪਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਅਬਫਸਕੇਸ਼ਨ ਕੋਸ਼ਿਸ਼ਾਂ ਅਸਲ ਵਿੱਚ ਮਾਲਵੇਅਰ ਦਾ ਸਬੂਤ ਹਨ (ਪਰ ਧਿਆਨ ਦਿਓ ਕਿ ਜਾਇਜ਼ ਹਿੱਸੇ ਬੌਧਿਕ ਸੰਪਤੀ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਲਈ ਕੋਡ ਨੂੰ ਅਸਪਸ਼ਟ ਕਰਦੇ ਹਨ, "ਓਪਨ ਸੋਰਸ”)। ਸਿਰਫ਼ ਕੁਝ ਕੁ ਬਹੁਤ ਹੀ ਸੂਝਵਾਨ ਹਮਲਿਆਂ ਨੂੰ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਮਜ਼ਬੂਤ ਅਸਪਸ਼ਟਤਾ ਹੈ, ਸੈਂਡਬਾਕਸਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਪਰ ਅਜਿਹਾ ਮਜ਼ਬੂਤ ਅਸਪਸ਼ਟਤਾ ਦੁਰਭਾਵਨਾ ਦੀ ਇੱਕ ਸਪੱਸ਼ਟ ਨਿਸ਼ਾਨੀ ਹੈ। ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਰਵਾਇਤੀ SAST ਔਜ਼ਾਰ ਅਣਜਾਣੇ ਵਿੱਚ ਕਮਜ਼ੋਰੀਆਂ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਸਨ, ਨਾ ਕਿ ਪਿਛਲੇ ਦਰਵਾਜ਼ੇ ਵਰਗੇ ਖਤਰਨਾਕ ਇਰਾਦੇ ਲਈ।
ਗਤੀਸ਼ੀਲ ਵਿਸ਼ਲੇਸ਼ਣ ਕੰਪੋਨੈਂਟ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਰਨਟਾਈਮ ਨੂੰ ਇੰਸਟ੍ਰੂਮੈਂਟ ਕਰਕੇ ਜਵਾਬ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸੈਂਡਬੌਕਸਡ ਵਾਤਾਵਰਣ ਪ੍ਰਦਾਨ ਕਰਕੇ। ਕੁਝ ਸਥਿਤੀਆਂ ਦੇ ਅਧੀਨ ਸ਼ੁਰੂ ਹੋਇਆ ਖਤਰਨਾਕ ਵਿਵਹਾਰ ਅਣਪਛਾਤੇ ਹੋ ਸਕਦਾ ਹੈ: ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਮਾਲਵੇਅਰ ਚੋਰੀ ਦੀਆਂ ਤਕਨੀਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ/ਸੈਂਡਬਾਕਸ ਚੋਰੀ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਕਿਰਿਆਸ਼ੀਲ ਹੋਣਾ ਜਦੋਂ ਜਾਂਚ ਅਧੀਨ ਨਾ ਹੋਵੇ, ਅਤੇ ਕਿਸੇ ਵੀ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਇੰਜਣ ਲਈ ਖਤਰਨਾਕ ਗਤੀਵਿਧੀ ਦਾ ਇੱਕ ਸੰਕੇਤ ਵੀ।
ਸਮਰੱਥਾਵਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਇਹ ਵਿਚਾਰ ਕਰਦਾ ਹੈ ਕਿ ਕੰਪੋਨੈਂਟ ਕੀ ਕਰਦਾ ਹੈ: ਇਹ ਕਿੱਥੇ ਜੁੜਦਾ ਹੈ, ਇਹ ਕਿਹੜੀਆਂ ਫਾਈਲਾਂ ਤੱਕ ਪਹੁੰਚ ਕਰਦਾ ਹੈ, ਕਿਹੜੀਆਂ ਕਮਾਂਡਾਂ ਜਾਂ ਪ੍ਰੋਗਰਾਮ ਚਲਾਏ ਜਾਂਦੇ ਹਨ, ਟਰਮੀਨਲ ਜਾਂ ਡਿਵਾਈਸ I/O ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਾਂ ਕਿਹੜੀਆਂ ਸਿਸਟਮ ਕਾਲਾਂ ਨੂੰ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ। ਵਿਵਹਾਰ ਦੀ ਇਸ ਫਿੰਗਰਪ੍ਰਿੰਟਿੰਗ ਦੀ ਤੁਲਨਾ (ਮੌਜੂਦਾ ਕੰਪੋਨੈਂਟ ਲਈ) ਸਾਰੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਜਦੋਂ ਅਚਾਨਕ ਵਿਵਹਾਰ ਦਾ ਪਤਾ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਸਬੂਤ ਨਵੇਂ ਸੰਸਕਰਣ ਵਿੱਚ ਸੰਭਾਵੀ ਖਤਰਨਾਕ ਗਤੀਵਿਧੀ ਦੇ ਸ਼ੱਕ ਨੂੰ ਵਧਾ ਸਕਦਾ ਹੈ। ਇਹ ਪਹੁੰਚ ਸੰਭਾਵੀ ਮਾਲਵੇਅਰ ਦਾ ਸਾਹਮਣਾ ਕਰਨ ਵੇਲੇ ਸੁਰੱਖਿਆ ਵਿਸ਼ਲੇਸ਼ਕ ਦੁਆਰਾ ਅਪਣਾਏ ਜਾਣ ਵਾਲੇ ਟ੍ਰਾਈਏਜ ਕਦਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ: ਸਤਰ ਜਾਂ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਔਜ਼ਾਰ। ਇਹ ਪਹੁੰਚ ਟਰਿੱਗਰ ਕਰਨ ਵਾਲੀਆਂ ਸਥਿਤੀਆਂ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਖਤਰਨਾਕ ਵਿਵਹਾਰ ਦਾ ਪਤਾ ਲਗਾਉਂਦੀ ਹੈ ਅਤੇ ਉਦੋਂ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਕੋਈ ਸਰੋਤ ਕੋਡ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦਾ।
ਸੰਦਰਭ ਵਿਸ਼ਲੇਸ਼ਣ ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਦਾ ਹੈ ਕਿ ਕੰਪੋਨੈਂਟ ਕਿਵੇਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਕਿਸ ਦੁਆਰਾ। ਮਾੜੇ ਅਦਾਕਾਰਾਂ ਦੀਆਂ ਮੁਹਿੰਮਾਂ ਅਕਸਰ ਇੱਕ ਨਵੇਂ ਉਪਭੋਗਤਾ ਖਾਤੇ(ਖਾਤਿਆਂ) ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ ਜੋ ਕਿਸੇ ਸਖ਼ਤ ਜਾਂਚ ਪ੍ਰਕਿਰਿਆ ਦੇ ਅਧੀਨ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਪਿਛਲੀ ਗਤੀਵਿਧੀ ਨੂੰ ਟਰੈਕ ਕਰਨ ਨਾਲ ਅੰਡਰਲਾਈੰਗ ਉਪਭੋਗਤਾ ਬਾਰੇ ਸੂਝ ਮਿਲ ਸਕਦੀ ਹੈ, ਜ਼ਿਆਦਾਤਰ ਉਹਨਾਂ ਵਿਗਾੜਾਂ ਲਈ ਜੋ ਸੰਭਾਵੀ ਸਮਝੌਤਾ ਵੱਲ ਸੰਕੇਤ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਪ੍ਰਤਿਸ਼ਠਾ ਕਮਾਉਣਾ ਬਹੁਤ ਔਖਾ ਹੈ ਅਤੇ ਗੁਆਉਣਾ ਬਹੁਤ ਆਸਾਨ ਹੈ! ਇੱਕ ਉਪਭੋਗਤਾ ਜਿਸਦੀ ਪਿਛਲੀ ਗਤੀਵਿਧੀ ਨਹੀਂ ਹੈ ਉਹ ਨਿਰਪੱਖ ਹੁੰਦਾ ਹੈ, ਪਰ ਕਰਮ ਦੁਸ਼ਟ ਦਾ ਪਿੱਛਾ ਕਰਦਾ ਹੈ। ਹੈਕਟਿਵਿਸਟ, ਜਾਂ ਆਮ ਉਪਭੋਗਤਾ ਜਿਨ੍ਹਾਂ ਦੇ ਪ੍ਰਕਾਸ਼ਨ ਪ੍ਰਮਾਣ ਪੱਤਰ ਚੋਰੀ ਹੋ ਗਏ ਹਨ, ਨੂੰ ਧਿਆਨ ਨਾਲ ਟਰੈਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਹੋਰ ਪ੍ਰਸੰਗਿਕ ਜਾਣਕਾਰੀ ਸਰੋਤ ਰਿਪੋਜ਼ਟਰੀ ਦੇ ਵਿਚਕਾਰ ਕੋਈ ਵੀ ਅੰਤਰ ਹੈ ਜੋ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਕੰਪੋਨੈਂਟ ਟਾਰਬਾਲ ਬਣਾਉਣ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਟਾਰਬਾਲ ਦੀ ਸਮੱਗਰੀ ਖੁਦ। ਅਤੇ ਚੰਗੇ ਅਭਿਆਸਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨਾ, ਜਿਵੇਂ ਕਿ ਜਨਤਕ ਰਜਿਸਟਰੀ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕੰਪੋਨੈਂਟ ਦੇ ਸੰਸਕਰਣਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਸਰੋਤ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਟੈਗ ਜਾਂ ਰੀਲੀਜ਼ ਬਣਾਉਣਾ। ਜਦੋਂ ਕਿਸੇ ਖਾਸ 'ਤੇ ਸਰੋਤ ਰਿਪੋਜ਼ਟਰੀ commit ਰੀਲੀਜ਼ ਨਾਲ ਟੈਗ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਅਚਾਨਕ ਇੱਕ ਸੰਸਕਰਣ ਇਸਦਾ ਪਾਲਣ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਹੀ ਇੱਕ ਮਜ਼ਬੂਤ ਸਬੂਤ ਹੈ ਕਿ ਕੰਪੋਨੈਂਟ ਦਾਗ਼ੀ ਹੋ ਸਕਦਾ ਹੈ: ਮਾੜੇ ਐਕਟਰ ਨੇ ਕੰਪੋਨੈਂਟ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਲਈ ਵਰਤੇ ਗਏ ਖਾਤੇ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਸਰੋਤ ਕੋਡ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਕੋਈ ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ)। ਇਹਨਾਂ ਨਿਯਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਹੁਤ ਸਾਰੇ ਹਮਲੇ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਖੋਜੇ ਜਾਂਦੇ ਹਨ: ਉਦਾਹਰਣ ਵਜੋਂ, ਲੇਜਰ ਹਮਲਾ ਇਹਨਾਂ ਲੀਹਾਂ 'ਤੇ ਆਸਾਨੀ ਨਾਲ ਖੋਜਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ, ਸੰਦਰਭ ਵਿਸ਼ਲੇਸ਼ਣ ਪ੍ਰਕਾਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਅਜਿਹੀਆਂ ਵਿਗਾੜਾਂ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ।
ਨਿਰਭਰਤਾ ਫਾਇਰਵਾਲਿੰਗ
ਇੱਕ ਵੱਖਰਾ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸਾਰੇ ਨਿਰਭਰਤਾ ਗ੍ਰਾਫਾਂ ਲਈ ਹਿੱਸਿਆਂ ਦੀ ਇੱਕ ਵਿਆਪਕ ਵਾਈਟਲਿਸਟ ਹੋਵੇ, ਇਸ ਲਈ ਕਿਸੇ ਵੀ ਬਿਲਡ ਵਿੱਚ pipeline ਤੁਹਾਡੇ ਸੰਗਠਨ ਵਿੱਚ ਚਲਾਏ ਜਾਣ ਵਾਲੇ ਸਿਰਫ਼ ਪ੍ਰਵਾਨਿਤ ਕੰਪੋਨੈਂਟ ਸੰਸਕਰਣ ਹੀ ਸਥਾਪਿਤ ਅਤੇ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ। “ਫਾਇਰਵਾਲ"ਇੱਕ ਅੰਦਰੂਨੀ ਰਜਿਸਟਰੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਆਗਿਆ ਪ੍ਰਾਪਤ ਕੰਪੋਨੈਂਟ ਸੰਸਕਰਣਾਂ ਲਈ ਟਾਰਬਾਲ ਪਰੋਸੇ ਜਾਂਦੇ ਹਨ (ਕੈਸ਼ ਜਾਂ ਪ੍ਰੌਕਸੀ)। ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਕੋਈ ਵੀ ਵਾਈਟਲਿਸਟ ਉਦੋਂ ਤੱਕ ਕੰਮ ਨਹੀਂ ਕਰੇਗੀ ਜਦੋਂ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਕਿਸੇ ਵੀ ਨਵੇਂ ਸੰਸਕਰਣ ਨੂੰ ਵਾਜਬ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਵਜੋਂ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਨ ਦੀ ਤਕਨਾਲੋਜੀ ਨਹੀਂ ਹੈ ਤਾਂ ਜੋ ਇਸਨੂੰ ਵਾਈਟਲਿਸਟ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾ ਸਕੇ।
ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਸ਼ੁਰੂਆਤੀ ਚੇਤਾਵਨੀ (ਨਵੇਂ ਸੰਸਕਰਣ ਪ੍ਰਕਾਸ਼ਨ ਤੋਂ ਬਾਅਦ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਜਲਦੀ ਪਤਾ ਲਗਾਉਣਾ) ਨੂੰ ਬਿਲਡ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੇ ਹਿੱਸੇ ਨੂੰ ਰੋਕਣ ਲਈ ਉਸ ਜਾਣਕਾਰੀ ਦੀ ਕਿਰਿਆਸ਼ੀਲਤਾ ਨਾਲ ਵਰਤੋਂ ਕਰਨ ਦੇ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਜੋੜਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ। pipelineਜਾਂ ਡਿਵੈਲਪਰਾਂ ਦੀਆਂ ਮਸ਼ੀਨਾਂ [4]. ਅਸੀਂ ਇਸਨੂੰ "ਨਿਰਭਰਤਾ ਫਾਇਰਵਾਲਿੰਗ”: ਆਟੋਮੇਟਿਡ ਬਿਲਡਜ਼ ਨੂੰ ਖਤਰਨਾਕ ਪੈਕੇਜਾਂ ਤੋਂ ਬਚਾਉਣ ਲਈ ਇੱਕ ਕੁਆਰੰਟੀਨ ਵਿਧੀ। ਅੰਦਰੂਨੀ ਪੈਕੇਜ ਅਤੇ ਚਿੱਤਰ ਰਜਿਸਟਰੀਆਂ ਸੰਗਠਨਾਂ ਨੂੰ ਬਾਹਰੀ ਬੁਰਾਈ ਤੋਂ ਬਚਾਉਣ ਲਈ ਵਧੀਆ ਹਨ, ਪਰ ਕੁਆਰੰਟੀਨ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣਾਉਣ ਲਈ ਕਾਫ਼ੀ ਮਜ਼ਬੂਤ ਸਬੂਤ ਜ਼ਰੂਰੀ ਹਨ।
ਰਨਟਾਈਮ ਸੈਂਡਬਾਕਸਿੰਗ
ਪ੍ਰਕਾਸ਼ਨ ਸਮੇਂ ਖੋਜ ਲਈ ਇੱਕ ਵਿਕਲਪਿਕ ਪਹੁੰਚ ਰਨਟਾਈਮ 'ਤੇ ਵਿਵਹਾਰ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ ਹੈ। ਵਿਚਾਰ ਸਾਫਟਵੇਅਰ ਤੋਂ ਉਮੀਦ ਕੀਤੇ ਵਿਵਹਾਰ ਨੂੰ ਹਾਸਲ ਕਰਨਾ ਅਤੇ ਪਾਏ ਜਾਣ ਵਾਲੇ ਕਿਸੇ ਵੀ ਵਿਗਾੜ ਦਾ ਪਤਾ ਲਗਾਉਣਾ (ਜਾਂ ਬਲਾਕ ਕਰਨਾ) ਹੈ। ਇਸ ਕਾਰਵਾਈ ਦੀ ਲਾਈਨ ਵਿੱਚ ਨਿਗਰਾਨੀ ਜਾਂ ਬਲਾਕਿੰਗ ਲਈ ਰਨਟਾਈਮ ਨੂੰ ਸਾਧਨ ਬਣਾਉਣ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ ਵਾਅਦਾ ਕਰਨ ਵਾਲਾ ਵਿਚਾਰ ਹੈ ਜੋ ਖਤਰਨਾਕ ਕੰਪੋਨੈਂਟ ਕੀਟ ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਵਿਧੀਆਂ ਦੇ ਹਥਿਆਰਾਂ ਵਿੱਚ ਜੋੜਿਆ ਜਾਵੇਗਾ।
ਇੱਕ ਵਿਆਪਕ ਰਣਨੀਤੀ ਨਿਰਧਾਰਤ ਕਰਨਾ
ਸਿਫ਼ਾਰਿਸ਼ ਕੀਤੀ ਰਣਨੀਤੀ ਨੂੰ ਸਾਫਟਵੇਅਰ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਤਕਨੀਕਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ, ਆਉਣ ਵਾਲੇ ਖਤਰਨਾਕ ਹਿੱਸਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਵਰਜਨ ਅੱਪਡੇਟਾਂ ਦਾ ਨਿਯੰਤਰਣ ਲੈਣਾ। ਸਾਨੂੰ ਵਰਜਨ ਪਿੰਨਿੰਗ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਮਹੱਤਵਪੂਰਨ ਕਮਜ਼ੋਰੀਆਂ ਲਈ ਸੁਧਾਰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਵਰਜਨ ਅੱਪਡੇਟ ਨਾਲ ਆਟੋਮੈਟਿਕ ਇਨਫੈਕਸ਼ਨ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ; ਵਰਜਨ ਅੱਪਡੇਟ ਦੌਰਾਨ ਸਿੱਧੇ ਅਤੇ ਅਸਿੱਧੇ ਨਿਰਭਰਤਾਵਾਂ ਦਾ ਇੱਕ ਤੇਜ਼ ਅਤੇ ਕੁਸ਼ਲ ਮੁਲਾਂਕਣ ਤਾਂ ਜੋ ਕਾਫ਼ੀ ਸਬੂਤ ਹੋਣ ਕਿ ਉਹ ਮਾਲਵੇਅਰ-ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਹਨ। ਜਾਣੇ-ਪਛਾਣੇ ਖਤਰਨਾਕ ਹਿੱਸਿਆਂ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਵਾਲੇ ਸਾਫਟਵੇਅਰ ਦੇ ਨਿਰਮਾਣ ਨੂੰ ਬਲੌਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ ਸਾਰਿਆਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜਦੋਂ ਵੀ ਸੰਭਵ ਹੋਵੇ, ਵਰਜ਼ਨ ਪਿਨਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਕਿਉਂਕਿ ਇਹ ਬਿਲਡਾਂ ਨੂੰ ਹੋਰ ਪ੍ਰਜਨਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਨਿਯੰਤਰਿਤ, ਹੱਥੀਂ ਪ੍ਰਵਾਨਿਤ ਵਰਜਨ ਬੰਪਾਂ ਦੇ ਨਾਲ ਵਰਜਨ ਪਿਨਿੰਗਹੈ, ਅਤੇ ਸਹਾਇਕ ਤਕਨਾਲੋਜੀ ਦੁਆਰਾ ਸਹਾਇਤਾ ਪ੍ਰਾਪਤ, ਨੂੰ ਇਹ ਮੁਲਾਂਕਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਅੱਪਡੇਟ ਮਾਲਵੇਅਰ ਲਿਆਉਂਦਾ ਹੈ ਜਾਂ ਸਾਫਟਵੇਅਰ ਨੂੰ ਤੋੜਦਾ ਹੈ, ਅਤੇ ਮਾਲਵੇਅਰ ਇਨਫੈਕਸ਼ਨ ਤੋਂ ਬਚਣ ਲਈ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਅੱਪਡੇਟ ਨੂੰ ਮੇਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਟੂਲਿੰਗ ਇੱਥੇ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ, (1) ਤਰਜੀਹ ਦੇ ਕੇ ਕਿ ਕਿਹੜੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਅਸਲ ਵਿੱਚ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ (ਪਹੁੰਚਯੋਗ ਅਤੇ ਸ਼ੋਸ਼ਣਯੋਗ, ਹਮਲਾਵਰਾਂ ਦੁਆਰਾ ਨਿਸ਼ਾਨਾ ਬਣਾਏ ਜਾਣ ਦੇ ਉੱਚ ਜੋਖਮ ਦੇ ਨਾਲ), (2) ਟਾਰਗੇਟ ਸੰਸਕਰਣਾਂ ਦੀ ਚੋਣ ਕਰਕੇ ਜੋ ਮੌਜੂਦਾ ਕੰਪੋਨੈਂਟ ਵਰਤੋਂ ਦੇ ਅਨੁਕੂਲ ਹਨ ਅਤੇ ਸਾਫਟਵੇਅਰ ਨੂੰ ਨਹੀਂ ਤੋੜਦੇ, (3) ਟਾਰਗੇਟ ਸੰਸਕਰਣਾਂ ਦੀ ਚੋਣ ਕਰਕੇ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਖਤਰਨਾਕ ਵਿਵਹਾਰ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ (4) ਸਿੱਧੇ ਅਤੇ ਅਸਿੱਧੇ ਨਿਰਭਰਤਾਵਾਂ ਲਈ ਸੰਸਕਰਣ ਅਪਡੇਟ ਨੂੰ ਇੱਕ ਸਨੈਪ ਬਣਾਉਣਾ, ਮੈਨੀਫੈਸਟ ਫਾਈਲਾਂ ਵਿੱਚ ਬਦਲਾਅ ਸੁਝਾਉਂਦੇ ਹੋਏ ਜਿਨ੍ਹਾਂ ਨੂੰ ਜਲਦੀ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਕਦਮ (3) ਨੂੰ ਖਤਰਨਾਕ ਹਿੱਸਿਆਂ ਬਾਰੇ ਖਾਸ ਜਾਣਕਾਰੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਉਹਨਾਂ ਦੇ ਪ੍ਰਕਾਸ਼ਨ ਸਮੇਂ ਦੇ ਨੇੜੇ।
ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਇਹ ਪ੍ਰਕਿਰਿਆ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਲਾਗੂ ਕੀਤਾ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਸਾਰੀਆਂ ਥਾਵਾਂ 'ਤੇ। ਪ੍ਰਕਿਰਿਆ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸ਼ਾਮਲ ਸਾਰੀਆਂ ਧਿਰਾਂ ਨੂੰ ਸਿਖਲਾਈ ਦਿੱਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ਅਕਸਰ ਵਿਕਾਸ ਅਤੇ ਸਾਫਟਵੇਅਰ ਨਿਰਮਾਣ/ਤੈਨਾਤੀ ਨੂੰ ਬਾਹਰੀ ਰੂਪ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। CI/CD pipelines ਨੂੰ ਉਸ ਅਨੁਸਾਰ ਸੋਧਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਜੋ ਆਟੋਮੇਸ਼ਨ ਕਿਸੇ ਖਤਰਨਾਕ ਅਸਿੱਧੇ ਨਿਰਭਰਤਾ ਨੂੰ ਬਿਲਡ ਵਿੱਚ ਨਾ ਜਾਣ ਦੇਵੇ: guardrails ਜੇਕਰ ਕਿਸੇ ਨਿਰਭਰਤਾ ਵਿੱਚ ਸੰਭਾਵੀ ਮਾਲਵੇਅਰ ਦੇ ਕਾਫ਼ੀ ਸਬੂਤ ਹਨ ਤਾਂ ਬਿਲਡ ਨੂੰ ਬਲਾਕ ਕਰਨਾ ਸਿਫ਼ਾਰਸ਼ ਕੀਤਾ ਤਰੀਕਾ ਹੈ।
ਜੇਕਰ ਤੁਹਾਡੇ ਸੰਗਠਨ ਕੋਲ ਇੱਕ ਅੰਦਰੂਨੀ ਰਜਿਸਟਰੀ ਹੈ ਜੋ ਇਜਾਜ਼ਤ ਦਿੱਤੇ ਕੰਪੋਨੈਂਟ ਸੰਸਕਰਣਾਂ ਨੂੰ ਰੱਖਣ ਲਈ ਸੁਰੱਖਿਆ ਪ੍ਰੌਕਸੀ ਵਜੋਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਬੇਨਤੀ ਕੀਤੇ ਕੰਪੋਨੈਂਟ ਨੂੰ ਭੱਤਾ ਸੂਚੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਖਤਰਨਾਕ ਕੰਪੋਨੈਂਟਸ (ਹੋਰ ਮਾਪਦੰਡਾਂ ਤੋਂ ਇਲਾਵਾ) ਬਾਰੇ ਖੁਫੀਆ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
ਸੁਰੱਖਿਆ ਦੇ ਨਾਲ ਓਪਨ-ਸੋਰਸ ਸੌਫਟਵੇਅਰ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਆਸਾਨ ਨਹੀਂ ਹੈ, ਅਤੇ ਮਾਲਵੇਅਰ ਫੈਕਟਰ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਮਜ਼ੋਰੀ ਨਾਲ ਨਜਿੱਠਣ ਲਈ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਕ ਅੰਤਮ ਨੋਟ: ਸਰੋਤ ਉਤਪਤੀ, ਸਾਫਟਵੇਅਰ ਪ੍ਰਮਾਣੀਕਰਨ ਦੇ ਰੂਪ ਵਿੱਚ, ਜੋ ਕਿ ਕੰਪੋਨੈਂਟ ਦੇ ਨਿਰਮਾਣ ਸਮੇਂ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਆਰਟੀਫੈਕਟ (ਕੰਪੋਨੈਂਟ ਟਾਰਬਾਲ) ਨੂੰ ਸਰੋਤਾਂ ਅਤੇ ਬਿਲਡ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਟਰੇਸ ਕਰਨ ਦੇ ਯਤਨ ਵਿੱਚ ਇੱਕ ਹੋਰ ਮੁੱਖ ਹਿੱਸਾ ਹੈ ਜਿਸਨੇ ਇਸਨੂੰ ਤਿਆਰ ਕੀਤਾ ਹੈ। ਧਿਆਨ ਦਿਓ ਕਿ ਸਰੋਤ ਸਨੈਪਸ਼ਾਟ + ਬਿਲਡ ਵਾਤਾਵਰਣ ਅਤੇ ਸੰਬੰਧਿਤ ਸਾਫਟਵੇਅਰ ਆਰਟੀਫੈਕਟ (ਭਰੋਸੇਯੋਗ ਬਿਲਡ ਸਿਸਟਮ ਦੁਆਰਾ ਦਸਤਖਤ ਕੀਤੇ ਗਏ) ਵਿਚਕਾਰ ਇਹ ਲਿੰਕ ਇਸ ਗੱਲ ਨੂੰ ਨਹੀਂ ਰੋਕਦਾ ਕਿ ਕੰਪੋਨੈਂਟ ਵਿੱਚ ਖਤਰਨਾਕ ਵਿਵਹਾਰ ਨਹੀਂ ਹੈ, ਪਰ ਮਾੜੇ ਲੋਕਾਂ ਲਈ ਮਾਲਵੇਅਰ ਨੂੰ ਇੰਜੈਕਟ ਕਰਨਾ ਔਖਾ ਬਣਾਉਂਦਾ ਹੈ। ਅਤੇ ਓਪਨ ਸੋਰਸ ਕੰਪੋਨੈਂਟਸ ਦੀ ਖਪਤ ਲਈ ਪ੍ਰੋਵੇਨੈਂਸ ਵੈਲੀਡੇਸ਼ਨ ਨੂੰ ਇੱਕ ਆਮ ਲੋੜ ਬਣਾਉਣ ਵਿੱਚ ਬਹੁਤ ਸਮਾਂ ਲੱਗੇਗਾ, ਅਤੇ ਸਿਰਫ ਹਾਲ ਹੀ ਵਿੱਚ NPM ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ. ਉਹਨਾਂ ਭਰੋਸੇਯੋਗ ਬਿਲਡ ਅਤੇ ਡਿਪਲਾਇ ਸਿਸਟਮਾਂ ਨੂੰ ਛੇੜਛਾੜ-ਰੋਧਕ ਬਣਾਉਣਾ, ਜਾਂ ਬਿਲਡ ਵਿੱਚ ਕਿਸੇ ਵੀ ਛੇੜਛਾੜ ਦਾ ਪਤਾ ਲਗਾਉਣ ਦੇ ਯੋਗ ਬਣਾਉਣਾ ਇੱਕ ਵੱਖਰੀ ਕਹਾਣੀ ਹੈ, ਇਸ ਪੋਸਟ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ।
ਹੋਰ ਪੜ੍ਹਨ
ਅਗਲਾ ਐਪੀਸੋਡ ਓਪਨ ਸੋਰਸ ਖਤਰਨਾਕ ਪੈਕੇਜ: ਜ਼ਾਇਜੇਨੀ ਪਹੁੰਚ ਸਾਡੇ ਲਈ Xygeni ਵਿਖੇ ਸਾਡੀ ਰਣਨੀਤੀ ਪੇਸ਼ ਕਰੇਗਾ। ਮਾਲਵੇਅਰ ਸੰਬੰਧੀ ਜਲਦੀ ਚੇਤਾਵਨੀ (MEW) ਸਿਸਟਮ। ਜਨਤਕ ਪੈਕੇਜ ਅਤੇ ਚਿੱਤਰ ਰਜਿਸਟਰੀਆਂ ਵਿੱਚ ਨਵੇਂ ਪੈਕੇਜ ਸੰਸਕਰਣਾਂ ਨੂੰ ਸਕੈਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਥਿਰ, ਗਤੀਸ਼ੀਲ, ਸਮਰੱਥਾਵਾਂ ਅਤੇ ਪ੍ਰਸੰਗਿਕ ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਸੁਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਬੂਤ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਸਬੂਤ, ਉਪਭੋਗਤਾ ਪ੍ਰਤਿਸ਼ਠਾ ਅਤੇ ਸਰੋਤ ਕੋਡ ਰਿਪੋਜ਼ਟਰੀਆਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੇ ਇਤਿਹਾਸ ਦੇ ਨਾਲ, ਇੱਕ ਹਿੱਸੇ ਦੇ ਉੱਚ-ਜੋਖਮ ਅਤੇ ਸ਼ਾਇਦ ਖਤਰਨਾਕ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਇੱਕ ਸਾਰੇ-ਆਟੋਮੈਟਿਕ ਵਰਗੀਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ। ਸਿਸਟਮ ਗਲਤ ਸਕਾਰਾਤਮਕਤਾਵਾਂ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਕਰਨ ਲਈ ਪੈਕੇਜਾਂ ਤੋਂ ਇਕੱਠੇ ਕੀਤੇ ਪਿਛਲੇ ਸਬੂਤਾਂ ਤੋਂ ਸਿੱਖਦਾ ਹੈ।
ਜਦੋਂ ਕਿਸੇ ਖਤਰਨਾਕ ਸੰਸਕਰਣ ਨੂੰ ਸ਼੍ਰੇਣੀਬੱਧ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਗਾਹਕੀ ਪ੍ਰਾਪਤ ਸੰਗਠਨਾਂ ਨੂੰ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਲਈ ਇੱਕ ਚੇਤਾਵਨੀ ਸੂਚਨਾ ਪ੍ਰਾਪਤ ਹੁੰਦੀ ਹੈ ਜੋ ਉਹ ਸਿੱਧੇ ਜਾਂ ਅਸਿੱਧੇ ਤੌਰ 'ਤੇ ਵਰਤ ਰਹੇ ਹਨ। ਫਿਰ ਸਾਡੇ ਵਿਸ਼ਲੇਸ਼ਕਾਂ ਦੁਆਰਾ ਇੱਕ ਦਸਤੀ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਵਰਗੀਕਰਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਜਾਂ ਰੱਦ ਕਰਦਾ ਹੈ। ਪੁਸ਼ਟੀ ਕੀਤੇ ਮਾਲਵੇਅਰ ਲਈ, ਜਨਤਕ ਰਜਿਸਟਰੀ ਨੂੰ ਸੂਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਇਹ ਆਪਣਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰ ਸਕੇ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਖਤਰਨਾਕ ਸੰਸਕਰਣ ਨੂੰ ਹਟਾ ਸਕੇ ਜਾਂ ਵਾਧੂ ਕਾਰਵਾਈ ਕਰ ਸਕੇ, ਜਿਵੇਂ ਕਿ ਸਵਾਲ ਵਿੱਚ ਉਪਭੋਗਤਾ ਖਾਤੇ ਨੂੰ ਬਲੌਕ ਕਰਨਾ ਜਾਂ ਹਟਾਉਣਾ।
ਅਸੀਂ ਦੱਸਾਂਗੇ ਕਿ ਅਸੀਂ ਓਪਨ ਸੋਰਸ ਈਕੋਸਿਸਟਮ ਵਿੱਚ NPM, PyPI, GitHub, ਅਤੇ ਹੋਰ ਮੁੱਖ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਕਿਵੇਂ ਮਦਦ ਕਰ ਰਹੇ ਹਾਂ ਤਾਂ ਜੋ ਇੱਕ ਨਵਾਂ ਖਤਰਨਾਕ ਕੰਪੋਨੈਂਟ ਪ੍ਰਕਾਸ਼ਿਤ ਹੋਣ ਤੱਕ ਸਰਗਰਮ ਰਹਿਣ ਦੇ ਸਮੇਂ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕੇ ਜਦੋਂ ਤੱਕ ਇਸਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਹੋ ਜਾਂਦੀ। ਮਾਲਵੇਅਰ ਅਤੇ ਰਜਿਸਟਰੀ ਤੋਂ ਹਟਾਇਆ ਨਹੀਂ ਜਾਂਦਾ। ਅਤੇ ਕਿਵੇਂ ਸੰਗਠਨਾਂ ਨੂੰ MEW ਸਿਸਟਮ ਤੋਂ ਲਾਭ ਹੋ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ ਓਪਨ ਸੋਰਸ ਕੰਪੋਨੈਂਟਸ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਵਾਲੇ ਸੌਫਟਵੇਅਰ ਸਪਲਾਈ ਚੇਨ ਹਮਲਿਆਂ ਦੇ ਵਿਰੁੱਧ ਬਹੁਤ ਵਧੀਆ ਸੁਰੱਖਿਆ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾ ਸਕੇ।
- [1] ਵੈਸੇ ਵੀ, ਕੰਪੋਨੈਂਟ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇਹ ਜਾਂਚ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਕਿ ਕੀ ਕੰਪੋਨੈਂਟ ਟਾਰਬਾਲ ਕਿਤੇ ਕੈਸ਼ ਜਾਂ ਰਜਿਸਟਰਡ ਹੈ, ਉਦਾਹਰਣ ਵਜੋਂ ਅੰਦਰੂਨੀ ਰਜਿਸਟਰੀ ਵਿੱਚ, ਤਾਂ ਜੋ ਬਿਮਾਰੀ ਖਤਮ ਹੋ ਜਾਵੇ।
- [2] ਪੈਕ ਕੀਤੇ ਹਿੱਸੇ ਵਿੱਚ ਇੱਕ ਮੈਨੀਫੈਸਟ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਜੋ ਇਸਦੀ ਸਮੱਗਰੀ ਅਤੇ ਮੈਟਾਡੇਟਾ, ਸਰੋਤ ਜਾਂ ਕੰਪਾਇਲ ਕੀਤਾ ਕੋਡ, ਇੰਸਟਾਲੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ, ਅਤੇ ਵਾਧੂ ਆਈਟਮਾਂ ਜਿਵੇਂ ਕਿ ਟੈਸਟ ਸੂਟ, ਇੱਕ ਪੈਕੇਜਿੰਗ ਫਾਰਮੈਟ ਦੇ ਅਨੁਸਾਰ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਸੰਕੁਚਿਤ ਰੂਪ ਵਿੱਚ ਘੋਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ "ਕੰਪੋਨੈਂਟ ਟਾਰਬਾਲ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ।
- [3] ਭਾਵੇਂ ਖਤਰਨਾਕ ਐਕਟਰ ਰਜਿਸਟਰੀ ਵਿੱਚ ਹੀ ਉਲੰਘਣਾ ਕਰਕੇ ਪ੍ਰਕਾਸ਼ਿਤ ਹਿੱਸੇ ਨੂੰ ਸੋਧ ਸਕਦਾ ਹੈ, ਇੱਕ ਸਾਦਾ-ਪੁਰਾਣਾ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਡਾਇਜੈਸਟ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਟਾਰਬਾਲ ਵਿੱਚ ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਦਾ ਪਤਾ ਲਗਾ ਸਕਦਾ ਹੈ।
- [4] ਯਾਦ ਰੱਖੋ ਕਿ ਕੁਝ ਖਤਰਨਾਕ ਕੰਪੋਨੈਂਟ ਇੰਸਟਾਲ ਸਮੇਂ ਚੱਲਦੇ ਹਨ, ਇਸ ਲਈ ਇਹ ਡਿਵੈਲਪਰ ਨੋਡਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਅਣਜਾਣੇ ਵਿੱਚ "npm install X" ਨੂੰ X ਦੇ ਨਾਲ ਇੱਕ ਖਤਰਨਾਕ ਕੰਪੋਨੈਂਟ ਨਾਲ ਚਲਾਉਂਦੇ ਹਨ।
