ਕੀ AI ਸੁਰੱਖਿਆ ਜਾਂਚ SAST, DAST ਅਤੇ ਪੈਠ ਜਾਂਚਾਂ ਦੀ ਥਾਂ ਲੈ ਸਕਦੀ ਹੈ?

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

ਏਜੰਟ ਦੀ ਸਮੀਖਿਆ ਨਵੇਂ ਟੈਸਟ ਵਰਗ ਦੀ ਬਜਾਏ ਵਿਆਖਿਆਕਾਰ ਹੈ

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

ਇਹ ਫਰਕ ਉਸ ਵੇਲੇ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਵੈਂਡਰ ਕਹਿੰਦਾ ਹੈ ਕਿ ਉਸ ਦਾ ਏਜੰਟ «ਸਕੈਨਰਾਂ ਦੀ ਥਾਂ ਲੈ ਲੈਂਦਾ ਹੈ»। ਪੁੱਛੋ ਕਿ ਸਿਸਟਮ ਅਸਲ ਵਿੱਚ ਕੀ ਦੇਖ ਸਕਦਾ ਹੈ। ਕੀ ਇਸ ਨੂੰ ਪੂਰਾ ਰਿਪੋਜ਼ਟਰੀ, ਤਿਆਰ ਕੀਤਾ ਕੋਡ, ਬਿਲਡ ਫਲੈਗ, ਇੰਫ੍ਰਾਸਟ੍ਰਕਚਰ ਨੀਤੀ ਅਤੇ ਡਿਪੈਂਡੈਂਸੀ ਲੌਕਫਾਈਲ ਮਿਲਦੇ ਹਨ? ਕੀ ਇਹ ਕਈ ਯੂਜ਼ਰਾਂ ਵਜੋਂ ਲੌਗਇਨ ਕਰਕੇ ਹਰ ਰਿਕਵੈਸਟ ਤੋਂ ਬਾਅਦ ਡੇਟਾਬੇਸ ਸਥਿਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹੈ? ਕੀ ਇਸ ਨੂੰ ਪਤਾ ਹੈ ਕਿ ਨੀਤੀ ਅਨੁਸਾਰ ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਮਨਾਹੀ ਹਨ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇਹ ਕਿ ਇੰਟਰਫੇਸ ਵਿੱਚ ਉਹ ਮੌਜੂਦ ਨਹੀਂ? ਸੁੰਦਰ ਵਿਆਖਿਆ ਗੁੰਮ ਇਨਪੁੱਟ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦੀ।

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

ਸਪਸ਼ਟ ਹੱਦ ਸਮੀਖਿਆ ਅਤੇ ਪੁਸ਼ਟੀ ਦੇ ਵਿਚਕਾਰ ਹੈ। ਸਮੀਖਿਆ ਪੁੱਛਦੀ ਹੈ, «ਜੋ ਸਮੱਗਰੀ ਮੈਨੂੰ ਦਿਖ ਰਹੀ ਹੈ, ਉਸ ਦੇ ਆਧਾਰ ਉੱਤੇ ਕੀ ਇਹ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਅਸੁਰੱਖਿਅਤ ਲੱਗਦੀ ਹੈ?» ਪੁਸ਼ਟੀ ਪੁੱਛਦੀ ਹੈ, «ਦੱਸੀਆਂ ਸ਼ਰਤਾਂ ਹੇਠ ਕੀ ਇਹ ਅਦਾਕਾਰ ਮਨਾਹੀ ਵਾਲਾ ਨਤੀਜਾ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ?» AI ਦੋਵਾਂ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਪਰ ਸੁਰੱਖਿਆ ਗੇਟ ਨੂੰ ਇਹ ਦਰਜ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਕਿਹੜਾ ਦਾਅਵਾ ਕਰ ਰਿਹਾ ਹੈ। ਟੀਮਾਂ ਨੂੰ ਨੁਕਸਾਨ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸੁਚੱਜੀ ਸਮੀਖਿਆ ਟਿੱਪਣੀ ਨੂੰ ਪੁਸ਼ਟੀ ਕੀਤੇ ਐਕਸਪਲੋਇਟ ਵਜੋਂ ਦਰਜ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜਾਂ ਇੱਕ ਅਸਫਲ ਐਕਸਪਲੋਇਟ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਸੁਰੱਖਿਆ ਦਾ ਸਬੂਤ ਮੰਨ ਲਿਆ ਜਾਂਦਾ ਹੈ।

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

SAST ਕੋਲ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੀ ਸਰੋਤ ਕਵਰੇਜ ਅਜੇ ਵੀ ਹੈ

ਵੱਡੇ ਕੋਡਬੇਸ ਵਿੱਚ ਹਰ ਤਬਦੀਲੀ ਉੱਤੇ ਸਥਿਰ ਜਾਂਚਾਂ ਲਾਗੂ ਕਰਨ ਲਈ SAST ਅਜੇ ਵੀ ਸਭ ਤੋਂ ਸਸਤਾ ਢੰਗ ਹੈ। ਇਹ ਸਰੋਤਾਂ ਅਤੇ ਸਿੰਕਾਂ ਦੀ ਸੂਚੀ ਬਣਾ ਸਕਦਾ ਹੈ, ਮਨਾਹੀ ਵਾਲੀਆਂ API ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ, ਡੇਟਾ ਫਲੋ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਜਿਸ ਰਿਵਿਜ਼ਨ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਗਿਆ ਉਸ ਦੀ ਸਪਸ਼ਟ ਰਿਪੋਰਟ ਦੇ ਸਕਦਾ ਹੈ। ਨਿਰਧਾਰਤ ਨਿਯਮ ਕੱਲ੍ਹ ਵੀ ਉਹੀ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ, ਜੋ ਉਸ ਵੇਲੇ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਦੋਂ ਰਿਲੀਜ਼ ਗੇਟ ਨੂੰ ਪਾਸ ਜਾਂ ਫੇਲ ਹੋਣ ਦਾ ਆਡਿਟ ਯੋਗ ਕਾਰਨ ਚਾਹੀਦਾ ਹੋਵੇ।

ਏਜੰਟ ਉਹ ਸੰਦਰਭ ਜੋੜਦਾ ਹੈ ਜੋ ਨਿਯਮ ਇੰਜਣ ਕੋਲ ਅਕਸਰ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਪ੍ਰੋਜੈਕਟ-ਵਿਸ਼ੇਸ਼ ਰੈਪਰਾਂ ਦਾ ਪਿੱਛਾ ਕਰ ਸਕਦਾ ਹੈ, ਟਿੱਪਣੀਆਂ ਨੂੰ ਸਾਵਧਾਨੀ ਨਾਲ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਇੱਕ ਹੈਂਡਲਰ ਦੀ ਨੇੜਲੇ ਹੈਂਡਲਰਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਨਵੇਂ ਪੈਟਰਨ ਲਈ ਕਵੈਰੀ ਸੁਝਾ ਸਕਦਾ ਹੈ। ਇਹ ਸ਼ੱਕੀ ਗੈਰਹਾਜ਼ਰੀਆਂ ਲੱਭ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਨੌਂ ਐਂਡਪੌਇੰਟ authorizeProject() ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ ਪਰ ਦਸਵਾਂ ਰਿਕਾਰਡ ਸਿੱਧਾ ਲੋਡ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤਿਆਰ ਕੀਤਾ ਕੋਡ ਜਾਂ ਅਣਜਾਣ ਫ੍ਰੇਮਵਰਕ ਮਿਆਰੀ ਨਿਯਮ ਪੈਕ ਨੂੰ ਅਸਫਲ ਕਰ ਦੇਵੇ, ਤਾਂ ਇਹ ਖਾਸ ਤੌਰ ਉੱਤੇ ਲਾਭਦਾਇਕ ਹੈ।

ਪਰ ਏਜੰਟ ਦੀ ਸਰੋਤ ਕਵਰੇਜ ਸਾਬਤ ਕਰਨਾ ਆਮ ਤੌਰ ਉੱਤੇ ਔਖਾ ਹੁੰਦਾ ਹੈ। ਕਾਂਟੈਕਸਟ ਵਿੰਡੋ, ਰਿਟਰੀਵਲ ਰੈਂਕਿੰਗ, ਅਣਡਿੱਠ ਕੀਤੀਆਂ ਫਾਈਲਾਂ, ਤਿਆਰ ਕੀਤੇ ਆਰਟੀਫੈਕਟ ਅਤੇ ਟੂਲ ਟਾਈਮਆਉਟ ਕੋਡ ਨੂੰ ਅਣਪੜ੍ਹਿਆ ਛੱਡ ਸਕਦੇ ਹਨ। «ਇਸ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਇੰਜੈਕਸ਼ਨ ਦੀ ਸਮੀਖਿਆ ਕਰੋ» ਕਹਿਣ ਨਾਲ ਇਹ ਸਾਬਤ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਹਰ ਸਿੰਕ ਤੱਕ ਪਹੁੰਚ ਕੀਤੀ ਗਈ। SAST ਰਿਪੋਰਟ ਘੱਟੋ-ਘੱਟ ਇਹ ਦੱਸ ਸਕਦੀ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਫਾਈਲਾਂ, ਨਿਯਮ ਅਤੇ ਰਿਵਿਜ਼ਨ ਜਾਂਚੇ ਗਏ। ਲਾਜ਼ਮੀ ਗੇਟ ਦੀ ਥਾਂ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ ਏਜੰਟ ਨੂੰ ਵੀ ਇਸ ਦੇ ਬਰਾਬਰ ਦੀ ਕਵਰੇਜ ਲੈਜਰ ਚਾਹੀਦੀ ਹੈ।

NIST SP 800-218 ਇੱਥੇ ਸਮਝਦਾਰ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹੈ: ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ ਜਲਦੀ ਵਰਤੋ ਅਤੇ ਸੁਰੱਖਿਆ ਫੀਚਰਾਂ ਅਤੇ ਘਟਾਉਣ ਵਾਲੇ ਨਿਯੰਤਰਣਾਂ ਦੀ ਮਨੁੱਖੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਅਸਲ ਮੁੱਲ ਮਿਲਾਪ ਵਿੱਚ ਹੈ। ਸਥਿਰ ਨਿਯਮ ਹਰ ਕਮਿਟ ਉੱਤੇ ਜਾਣੇ-ਪਛਾਣੇ ਨੁਕਸ ਪੈਟਰਨ ਫੜਦੇ ਹਨ; ਏਜੰਟ ਅਪਵਾਦਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ, ਕੇਂਦਰਿਤ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟ ਲਿਖਦਾ ਅਤੇ ਇੱਕੋ ਪੈਟਰਨ ਮੁੜ ਆਉਣ ਉੱਤੇ ਨਿਯਮ ਸੁਧਾਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਏਜੰਟ ਨੇ ਕੁਝ ਚਤੁਰ ਬੱਗ ਲੱਭ ਲਏ ਇਸ ਕਰਕੇ SAST ਹਟਾਉਣਾ ਮਾਪੀ ਜਾ ਸਕਣ ਵਾਲੀ ਵਿਸ਼ਾਲਤਾ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਕਿਸਿਆਂ ਨਾਲ ਬਦਲਣਾ ਹੈ।

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

ਬਲੌਕ ਕਰਨ ਵਾਲੇ SAST ਨਿਯਮ ਵਿੱਚ ਹਰ ਗੱਲ ਸ਼ਾਮਲ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਮਨਾਹੀ ਕੀਤੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਪ੍ਰਿਮਿਟਿਵ ਦਾ ਸਪਸ਼ਟ ਪੈਟਰਨ ਤੁਰੰਤ ਰੋਕ ਸਕਦਾ ਹੈ। ਪਰ ਵਿਆਪਕ ਹਿਊਰਿਸਟਿਕ, ਜੋ ਪੁੱਛਦਾ ਹੈ ਕਿ ਅਧਿਕਾਰ ਜਾਂਚ «ਕਾਫ਼ੀ ਨੇੜੇ» ਲੱਗਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਆਮ ਤੌਰ ਉੱਤੇ ਸਮੀਖਿਆ ਟਾਸਕ ਬਣਾਏ, ਜਦ ਤੱਕ ਟੀਮ ਇਸ ਦੀ ਸ਼ੁੱਧਤਾ ਨਾ ਮਾਪ ਲਵੇ। ਏਜੰਟ ਸਹੀ ਉਦਾਹਰਨਾਂ, ਉਲਟ ਉਦਾਹਰਨਾਂ ਅਤੇ ਉਸ ਕੋਡਬੇਸ ਦੇ ਆਮ ਰੈਪਰ ਫੰਕਸ਼ਨ ਇਕੱਠੇ ਕਰਕੇ ਹਿਊਰਿਸਟਿਕ ਨੂੰ ਨਿਯਮ ਵਿੱਚ ਬਦਲਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ। ਇਸ ਨਾਲ ਗੇਟ ਸਖ਼ਤ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਡਿਵੈਲਪਰ ਉਸ ਨੂੰ ਅਣਡਿੱਠ ਕਰਨਾ ਨਹੀਂ ਸਿੱਖਦੇ।

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

DAST ਉਹ ਵਿਹਾਰ ਸਾਬਤ ਕਰਦਾ ਹੈ ਜੋ ਰਿਪੋਜ਼ਟਰੀ ਨਹੀਂ ਦਿਖਾ ਸਕਦੀ

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

ਇੱਥੇ ਏਜੰਟ ਡਾਇਨਾਮਿਕ ਟੈਸਟਿੰਗ ਨੂੰ ਕਾਫ਼ੀ ਘੱਟ ਭੋਂਦਾ ਬਣਾ ਸਕਦਾ ਹੈ। ਇਸ ਨੂੰ API ਵੇਰਵਾ, ਟੈਸਟ ਪਛਾਣਾਂ, ਮਨਜ਼ੂਰ ਸਕੋਪ ਅਤੇ ਡਿਸਪੋਜ਼ੇਬਲ ਵਾਤਾਵਰਣ ਦਿਓ, ਤਾਂ ਇਹ ਆਮ ਪੇਲੋਡ ਛਿੜਕਣ ਦੀ ਬਜਾਏ ਰਿਕਵੈਸਟ ਲੜੀਆਂ ਬਣਾ ਸਕਦਾ ਹੈ। ਇਹ ਇੱਕ ਰਿਸਪਾਂਸ ਵਿੱਚੋਂ ਰਿਸੋਰਸ ਪਛਾਣਕਾਰ ਅਗਲੀ ਰਿਕਵੈਸਟ ਵਿੱਚ ਲੈ ਜਾ ਸਕਦਾ ਹੈ, ਸੈਸ਼ਨ ਰਿਫ੍ਰੈਸ਼ ਕਰ ਸਕਦਾ ਹੈ, ਦੋ ਭੂਮਿਕਾਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਜਾਂਚ ਸਕਦਾ ਹੈ ਕਿ ਰਾਈਟ ਨੇ ਬਾਅਦ ਦੀਆਂ ਰੀਡਾਂ ਨੂੰ ਬਦਲਿਆ ਹੈ ਜਾਂ ਨਹੀਂ। ਰਵਾਇਤੀ DAST ਨੂੰ ਅਜਿਹੇ ਸਟੇਟਫੁਲ ਫਲੋਅ ਵਿੱਚ ਅਕਸਰ ਮੁਸ਼ਕਲ ਹੁੰਦੀ ਹੈ।

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

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

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

ਆਥੈਂਟੀਕੇਸ਼ਨ ਸੈਟਅੱਪ ਲਈ ਵੱਖਰਾ ਸਬੂਤ ਰੱਖੋ। ਦਰਜ ਕਰੋ ਕਿ ਟੈਸਟ ਨੇ ਹਰ ਸੈਸ਼ਨ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕੀਤਾ, ਟੈਸਟ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਿਹੜੇ ਦੂਜੇ ਫੈਕਟਰ ਜਾਂ ਡਿਵਾਈਸ ਜਾਂਚਾਂ ਬਾਈਪਾਸ ਕੀਤੀਆਂ ਗਈਆਂ ਅਤੇ ਕੀ ਟੋਕਨਾਂ ਵਿੱਚ ਪ੍ਰੋਡਕਸ਼ਨ ਟੋਕਨਾਂ ਵਰਗੇ ਕਲੇਮ ਅਤੇ ਮਿਆਦ ਹਨ। ਹੱਥੋਂ ਬਣਿਆ ਐਡਮਿਨ ਟੋਕਨ ਕਵਰੇਜ ਵਧਾ ਸਕਦਾ ਹੈ, ਪਰ ਉਹ ਠੀਕ ਉਹਨਾਂ ਸੈਸ਼ਨ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਤਬਦੀਲੀਆਂ ਨੂੰ ਛੱਡ ਸਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਜਾਂਚ ਲੋੜੀਂਦੀ ਹੈ। ਅਜਿਹੇ ਸ਼ਾਰਟਕੱਟ ਰਿਪੋਰਟ ਵਿੱਚ ਸਪਸ਼ਟ ਰੱਖੋ।

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

ਅਧਿਕਾਰ ਟੈਸਟਾਂ ਨੂੰ ਪਛਾਣਾਂ ਅਤੇ ਮਨਾਹੀ ਵਾਲੇ ਨਤੀਜਿਆਂ ਦੀ ਲੋੜ ਹੈ

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

OWASP ASVS ਕਹਿੰਦਾ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਸੇਵਾ ਪੱਧਰ ਉੱਤੇ ਐਕਸੈਸ ਕੰਟਰੋਲ ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਫੰਕਸ਼ਨਾਂ तथा ਡੇਟਾ ਉੱਤੇ ਘੱਟੋ-ਘੱਟ ਅਧਿਕਾਰ ਲਾਗੂ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਮੈਂ ਸੇਵਾ ਪੱਧਰ ਦੀ ਲੋੜ ਨਾਲ ਸਹਿਮਤ ਹਾਂ, ਪਰ ਟੀਮਾਂ ਅਕਸਰ ਇਸ ਦੀ ਬਹੁਤ ਸੀਮਿਤ ਜਾਂਚ ਕਰਦੀਆਂ ਹਨ। ਉਹ ਦਿਖਾਈ ਦੇਣ ਵਾਲੇ HTTP ਹੈਂਡਲਰ ਦੀ ਜਾਂਚ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ, ਐਕਸਪੋਰਟ, ਸਰਚ ਇੰਡੈਕਸ, ਵੈਬਸਾਕੇਟ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਸਿੱਧੇ ਆਬਜੈਕਟ ਸਟੋਰੇਜ URL ਭੁੱਲ ਜਾਂਦੀਆਂ ਹਨ। ਆਬਜੈਕਟ ਤੱਕ ਹਰ ਰਸਤੇ ਵਿੱਚ ਇੱਕੋ ਨੀਤੀ ਕਾਇਮ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ।

ਇੱਕ ਛੋਟੀ ਐਗਜ਼ਿਕਿਊਟੇਬਲ ਮੈਟ੍ਰਿਕਸ «IDOR ਟੈਸਟ ਕਰੋ» ਵਰਗੀ ਅਸਪਸ਼ਟ ਹਦਾਇਤ ਨਾਲੋਂ ਵੱਧ ਦਿਖਾਉਂਦੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤਾ shell ਹਿੱਸਾ ਡਿਸਪੋਜ਼ੇਬਲ ਵਾਤਾਵਰਣ, ਦੋ bearer ਟੋਕਨ ਅਤੇ ਯੂਜ਼ਰ A ਦੀ ਮਲਕੀਅਤ ਵਾਲੇ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਮੰਨਦਾ ਹੈ। ਇਹ ਸਥਿਤੀ ਅਤੇ B ਦੇ ਰਿਸਪਾਂਸ ਵਿੱਚ A ਦੇ ਗੁਪਤ ਨਿਸ਼ਾਨ ਦੀ ਗੈਰਹਾਜ਼ਰੀ ਦੋਵੇਂ ਜਾਂਚਦਾ ਹੈ:

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $TOKEN_B" \
  "$base_url/api/documents/$doc_id" \
  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

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

ਹੁਣ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਪੱਖ ਬਦਲੋ: ਰੀਡ ਬਨਾਮ ਅਪਡੇਟ, ਸਿੱਧੀ ID ਬਨਾਮ ਸਰਚ, ਸਰਗਰਮ ਬਨਾਮ ਰੱਦ ਕੀਤੀ ਮੈਂਬਰਸ਼ਿਪ, ਆਮ ਰੂਟ ਬਨਾਮ ਐਕਸਪੋਰਟ ਅਤੇ ਯੂਜ਼ਰ ਟੋਕਨ ਬਨਾਮ ਸੇਵਾ ਟੋਕਨ। ਏਜੰਟ ਇਹ ਕੇਸ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਬਣਾ ਅਤੇ ਚਲਾ ਸਕਦਾ ਹੈ। ਮਨੁੱਖ ਨੂੰ ਜਾਂਚਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਮੈਟ੍ਰਿਕਸ ਨੀਤੀ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ ਅਤੇ 404, 403, ਖਾਲੀ ਨਤੀਜਾ ਜਾਂ ਲੁਕਾਇਆ ਆਬਜੈਕਟ ਉਮੀਦ ਕੀਤਾ ਨਤੀਜਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਨਹੀਂ ਤਾਂ ਏਜੰਟ ਉਸ ਵਿਹਾਰ ਨੂੰ ਸਫਲਤਾ ਮੰਨ ਸਕਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕਾਰੋਬਾਰ ਉਲੰਘਣਾ ਸਮਝਦਾ ਹੈ।

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

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

ਟੈਨੈਂਟ ਆਈਸੋਲੇਸ਼ਨ ਸਿਰਫ਼ ਸਪਸ਼ਟ ਰਿਕਵੈਸਟ ਰਸਤੇ ਤੋਂ ਬਾਹਰ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ

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

ਦੋ ਟੈਨੈਂਟਾਂ ਵਿੱਚ ਜਾਣ-ਬੁੱਝ ਕੇ ਮਿਲਦੇ-ਜੁਲਦੇ ਰਿਕਾਰਡ ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਨਿਸ਼ਾਨ ਬਣਾਓ। ਵੱਖਰੇ ਯੂਜ਼ਰ, ਵੱਖਰੇ ਸੈਸ਼ਨ ਅਤੇ ਜਿੱਥੇ ਆਰਕੀਟੈਕਚਰ ਇਜਾਜ਼ਤ ਦੇਵੇ, ਵੱਖਰੇ ਸੇਵਾ ਕ੍ਰੈਡੈਂਸ਼ਲ ਵਰਤੋ। create, read, update, delete, list, search, export, import, attachment access, notification delivery ਅਤੇ background processing ਦੀ ਜਾਂਚ ਕਰੋ। ਹਰ ਕਾਰਵਾਈ ਤੋਂ ਬਾਅਦ ਯੂਜ਼ਰ ਨੂੰ ਦਿਖਣ ਵਾਲੇ ਰਿਸਪਾਂਸ ਅਤੇ ਟਿਕਾਊ ਸਥਿਤੀ ਦੋਵੇਂ ਦੇਖੋ। ਰੱਦ ਕੀਤੀ ਰਿਕਵੈਸਟ ਜੋ ਫਿਰ ਵੀ ਕ੍ਰਾਸ-ਟੈਨੈਂਟ ਜੌਬ ਕਤਾਰ ਵਿੱਚ ਪਾ ਦੇਵੇ, ਫੇਲ੍ਹ ਹੈ।

ਏਜੰਟ ਇੱਥੇ ਮਦਦਗਾਰ ਹਨ, ਕਿਉਂਕਿ ਇਹ ਪਛਾਣਕਾਰ ਨੂੰ ਕਈ ਪੱਧਰਾਂ ਵਿਚੋਂ ਟ੍ਰੇਸ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਉਹ permutation ਬਣਾ ਸਕਦੇ ਹਨ ਜੋ ਮਨੁੱਖਾਂ ਨੂੰ ਥਕਾਵਟ ਵਾਲੇ ਲੱਗਦੇ ਹਨ। ਇਹ ਦੇਖ ਸਕਦੇ ਹਨ ਕਿ ਕੈਸ਼ ਕੀ document_id ਵਰਤਦੀ ਹੈ ਜਦਕਿ ਡੇਟਾਬੇਸ ਕਵੈਰੀ tenant_id ਅਤੇ document_id ਦੋਵੇਂ ਵਰਤਦੀ ਹੈ। ਇਹ export worker ਦੀ ਇੰਟਰਐਕਟਿਵ ਹੈਂਡਲਰ ਨਾਲ ਤੁਲਨਾ ਕਰਕੇ ਪੁੱਛ ਸਕਦੇ ਹਨ ਕਿ row-level context ਸਿਰਫ਼ ਇੱਕ ਥਾਂ ਕਿਉਂ ਸੈੱਟ ਕੀਤਾ ਗਿਆ। ਇਹ ਉੱਚ ਮੁੱਲ ਵਾਲੀਆਂ ਸਮੀਖਿਆ ਕਾਰਵਾਈਆਂ ਹਨ।

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

ਏਜੰਟ ਨੂੰ ਉਸੇ ਕੋਡ ਨੂੰ ਪੜ੍ਹ ਕੇ ਆਪਣਾ oracle ਬਣਾਉਣ ਨਾ ਦਿਓ ਜਿਸ ਦੀ ਉਹ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ। ਉਮੀਦ ਕੀਤੀ ਪਹੁੰਚ ਉਤਪਾਦ ਲੋੜਾਂ ਨਾਲ ਸੰਭਾਲੀ ਸੁਤੰਤਰ ਨੀਤੀ ਟੇਬਲ ਤੋਂ ਲਓ। ਜੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਅਤੇ ਟੈਸਟ ਦੋਵੇਂ ਇੱਕੋ ਨਿਯਮ ਨੂੰ ਗਲਤ ਸਮਝਦੇ ਹਨ, ਤਾਂ ਉਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਹਿਮਤ ਹੋਣਗੇ ਅਤੇ ਫਿਰ ਵੀ ਡੇਟਾ ਲੀਕ ਕਰ ਸਕਦੇ ਹਨ।

ਅਸਿੰਕ੍ਰੋਨਸ ਰਸਤਿਆਂ ਲਈ ਦੇਰੀ ਵਾਲੀਆਂ assertions ਚਾਹੀਦੀਆਂ ਹਨ। ਟੈਨੈਂਟ A ਵਜੋਂ export, notification, thumbnail ਜਾਂ indexing job ਚਲਾਓ, worker ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮਲਕੀਅਤ ਜਾਂ ਮੈਂਬਰਸ਼ਿਪ ਬਦਲੋ ਅਤੇ ਦੇਖੋ ਕਿ ਨਤੀਜਾ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ। ਫੈਸਲਾ ਕਰੋ ਕਿ worker ਨੂੰ ਰਿਕਵੈਸਟ ਸਮੇਂ ਦੀ authority ਵਰਤਣੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ execution ਸਮੇਂ ਮੌਜੂਦਾ authority ਮੁੜ ਜਾਂਚਣੀ ਚਾਹੀਦੀ ਹੈ। ਕਿਸੇ ਖਾਸ ਕਾਰਵਾਈ ਲਈ ਦੋਵੇਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਚੋਣ ਸਹੀ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਬਿਨਾਂ ਯੋਜਨਾ ਦਾ ਮਿਲਾਪ ਲੀਕ ਅਤੇ ਟੁੱਟੇ ਆਡਿਟ ਟ੍ਰੇਲ ਬਣਾਉਂਦਾ ਹੈ।

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

ਕਾਰੋਬਾਰੀ ਤਰਕ ਲਈ ਦੁਰਵਰਤੋਂ ਦੀ ਕਹਾਣੀ ਚਾਹੀਦੀ ਹੈ

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

OWASP Web Security Testing Guide ਜਾਂਚਕਾਰਾਂ ਨੂੰ ਛੱਡੇ ਹੋਏ ਵਰਕਫਲੋ ਕਦਮ, ਦੁਹਰਾਈਆਂ ਕਾਰਵਾਈਆਂ, ਜਾਲਸਾਜ਼ ਰਿਕਵੈਸਟਾਂ, ਸਮੇਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਅਤੇ ਵੈਧ ਫੀਚਰਾਂ ਦੀ ਦੁਰਵਰਤੋਂ ਅਜ਼ਮਾਉਣ ਲਈ ਕਹਿੰਦੀ ਹੈ। ਇਸ ਦੀ ਪੁਰਾਣੀ business-logic ਜਾਣ-ਪਛਾਣ ਸਿੱਧਾ ਕਹਿੰਦੀ ਹੈ ਕਿ ਸਕੈਨਰ ਆਟੋਮੇਸ਼ਨ ਐਪਲੀਕੇਸ਼ਨ-ਵਿਸ਼ੇਸ਼ ਗਿਆਨ ਜਾਂ ਰਚਨਾਤਮਕਤਾ ਨਹੀਂ ਦੇ ਸਕਦੀ। ਆਧੁਨਿਕ ਏਜੰਟ ਆਟੋਮੇਸ਼ਨ ਸੁਧਾਰਦੇ ਹਨ, ਪਰ ਗਿਆਨ ਦੀ ਇਹ ਕਮੀ ਦੂਰ ਨਹੀਂ ਕਰਦੇ। ਮਾਡਲ ਸੁਝਾ ਸਕਦਾ ਹੈ ਕਿ ਕੂਪਨ ਮੁੜ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ; ਇਹ ਨਹੀਂ ਜਾਣ ਸਕਦਾ ਕਿ ਇਹ ਪ੍ਰਚਾਰ ਹੈ ਜਾਂ ਧੋਖਾਧੜੀ, ਜਦ ਤੱਕ ਕੋਈ ਨਿਯਮ ਨਾ ਦੱਸੇ।

ਏਜੰਟ ਨੂੰ ਮਨਜ਼ੂਰ ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ ਅਤੇ ਇਨਵੇਰੀਐਂਟਾਂ ਵਾਲਾ ਸਟੇਟ ਮਾਡਲ ਦਿਓ। ਮਨਜ਼ੂਰੀ ਫਲੋ ਲਈ ਇੱਕ ਇਨਵੇਰੀਐਂਟ ਹੋ ਸਕਦਾ ਹੈ, «ਰਿਕਵੈਸਟਰ ਆਪਣੀ ਹੀ ਭੁਗਤਾਨ ਰਿਕਵੈਸਟ ਨੂੰ ਮਨਜ਼ੂਰ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਮਲਕੀਅਤ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਵੀ ਨਹੀਂ»। ਫਿਰ ਇਸ ਨੂੰ ਭੂਮਿਕਾ ਤਬਦੀਲੀਆਂ, ਡੁਪਲੀਕੇਟ ਰਿਕਵੈਸਟ, ਰੱਦਗੀ, ਰਿਟਰਾਈ, concurrency ਅਤੇ ਪੁਰਾਣੇ ਸੈਸ਼ਨਾਂ ਵਾਲੀਆਂ ਲੜੀਆਂ ਬਣਾਉਣ ਲਈ ਕਹੋ। ਏਜੰਟ ਇੱਕ ਵਿਅਕਤੀ ਨਾਲੋਂ ਕਿਤੇ ਵੱਧ ਲੜੀਆਂ ਖੋਜ ਸਕਦਾ ਹੈ।

ਮੁਸ਼ਕਲ ਕੇਸਾਂ ਵਿੱਚ HTTP ਰਿਸਪਾਂਸ ਤੋਂ ਬਾਹਰ ਦੇ ਨਤੀਜੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਦੋ ਸਮਕਾਲੀ redemption ਰਿਕਵੈਸਟ ਦੋਵੇਂ ਸਫਲ ਵਾਪਸ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਜਦਕਿ ਬਾਅਦ ਦੀ reconciliation ਇੱਕ ਨੂੰ ਹਟਾ ਦੇਵੇ। ਰੱਦਗੀ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ job ਰੋਕ ਸਕਦੀ ਹੈ ਪਰ signed download ਨੂੰ ਰੱਦ ਨਾ ਕਰੇ। ਸੱਦਾ ਦੇਣ ਵਾਲੇ ਦੀ ਪਹੁੰਚ ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸੱਦਾ ਸਵੀਕਾਰ ਕਰਨ ਨਾਲ orphaned membership ਬਣ ਸਕਦੀ ਹੈ। ਟੈਸਟਾਂ ਨੂੰ ਸਿਰਫ਼ status code ਨਹੀਂ, ledger, queues, object permissions ਅਤੇ ਬਾਅਦ ਦੀ ਸਥਿਤੀ ਵੀ ਦੇਖਣੀ ਚਾਹੀਦੀ ਹੈ।

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

ਡਿਪੈਂਡੈਂਸੀ ਦਾ ਖਤਰਾ ਸਿਰਫ਼ ਕਮਜ਼ੋਰ ਵਰਜ਼ਨ ਤੋਂ ਵੱਧ ਹੈ

ਡਿਪੈਂਡੈਂਸੀ ਟੈਸਟਿੰਗ ਵਿੱਚ ਚਾਰ ਵੱਖਰੇ ਸਵਾਲ ਹਨ: ਕਿਹੜੇ ਪੈਕੇਜ ਮੌਜੂਦ ਹਨ, ਕੀ ਉਨ੍ਹਾਂ ਦੇ ਜਾਣੇ-ਪਛਾਣੇ ਵਰਜ਼ਨ ਰਿਪੋਰਟ ਕੀਤੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਰੱਖਦੇ ਹਨ, ਕੀ ਬਿਲਡ ਨੇ ਉਮੀਦ ਕੀਤੇ ਆਰਟੀਫੈਕਟ ਪ੍ਰਾਪਤ ਕੀਤੇ ਅਤੇ ਕੀ ਐਪਲੀਕੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕਮਜ਼ੋਰ ਵਿਹਾਰ ਦਿਖਾਉਂਦੀ ਹੈ। Software composition analysis (SCA) ਅਤੇ provenance ਨਿਯੰਤਰਣ ਇਨ੍ਹਾਂ ਪਹਿਲੇ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਇਕੱਲੀ ਗੱਲਬਾਤੀ ਸਮੀਖਿਆ ਨਾਲੋਂ ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਦਿੰਦੇ ਹਨ।

ਇਨਵੈਂਟਰੀ ਮੌਜੂਦ ਹੋਣ ਤੋਂ ਬਾਅਦ ਏਜੰਟ ਲਾਭਦਾਇਕ ਹੈ। ਇਹ ਜਾਂਚ ਸਕਦਾ ਹੈ ਕਿ ਡਿਪੈਂਡੈਂਸੀ ਕਿਵੇਂ ਕਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪ੍ਰਭਾਵਿਤ ਫੰਕਸ਼ਨ ਤੱਕ ਪਹੁੰਚ ਹੈ ਜਾਂ ਨਹੀਂ, ਮੁਆਵਜ਼ਾ ਨਿਯੰਤਰਣ ਲੱਭ ਸਕਦਾ ਹੈ ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟਾਂ ਵਾਲਾ ਅਪਗ੍ਰੇਡ ਪੈਚ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਉਹ ਖਤਰਨਾਕ ਪੈਕੇਜ ਵਿਹਾਰ ਵੀ ਦੱਸ ਸਕਦਾ ਹੈ ਜਿਸ ਦਾ ਕੋਈ vulnerability identifier ਨਹੀਂ, ਜਿਵੇਂ install script ਨੂੰ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਮਿਲਣਾ ਜਾਂ ਨਵੀਂ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਵਾਤਾਵਰਣ ਵਿੱਚ secrets ਮਿਲਣਾ।

ਮਾਡਲ ਨੂੰ ਮੌਜੂਦਾ ਕਮਜ਼ੋਰੀ ਡੇਟਾ ਯਾਦ ਤੋਂ ਦੱਸਣ ਲਈ ਨਾ ਕਹੋ। ਇਸ ਨੂੰ ਸਮਾਂ-ਮੁਹਰ ਵਾਲਾ ਐਡਵਾਈਜ਼ਰੀ ਸਰੋਤ, resolved lockfile ਅਤੇ built artifact inventory ਦਿਓ। ਮਾਡਲ ਦੀ ਯਾਦ vulnerability database ਨਹੀਂ ਅਤੇ package manifest ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ shipped ਹੋਇਆ। SLSA provenance ਇੱਕ ਸੰਬੰਧਿਤ ਫਰਕ ਦੱਸਦੀ ਹੈ: provenance ਦੱਸਦੀ ਹੈ ਕਿ ਆਰਟੀਫੈਕਟ ਕਿੱਥੇ, ਕਦੋਂ ਅਤੇ ਕਿਵੇਂ ਬਣਿਆ। ਇਹ ਆਰਟੀਫੈਕਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਘੋਸ਼ਿਤ ਨਹੀਂ ਕਰਦੀ।

ਰੀਚੇਬਿਲਿਟੀ ਟ੍ਰਾਇਜ ਦੀ ਤਰਜੀਹ ਘਟਾ ਸਕਦੀ ਹੈ, ਪਰ ownership ਖਤਮ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ। ਫੀਚਰ ਫਲੈਗ ਬਦਲਦੇ ਹਨ, dead code ਵਾਪਸ ਆ ਸਕਦਾ ਹੈ ਅਤੇ indirect dependencies ਅਣਉਮੀਦ ਤਰੀਕੇ ਨਾਲ ਕਾਲ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਦਰਜ ਕਰੋ ਕਿ ਫਾਈਂਡਿੰਗ ਮੁਲਤਵੀ ਕਿਉਂ ਕੀਤੀ ਗਈ, ਕਿਹੜਾ ਵਰਜ਼ਨ ਅਤੇ ਕਾਲ ਪਾਥ ਜਾਂਚਿਆ ਗਿਆ ਅਤੇ ਕਿਹੜੀ ਘਟਨਾ ਇਸ ਨੂੰ ਮੁੜ ਖੋਲ੍ਹੇਗੀ। ਏਜੰਟ ਇਹ ਤਰਕ ਸੰਭਾਲ ਸਕਦਾ ਹੈ, ਜਦਕਿ ਨਿਰਧਾਰਤ ਇਨਵੈਂਟਰੀ ਘਟਨਾ ਉੱਤੇ ਨਜ਼ਰ ਰੱਖਦੀ ਹੈ।

ਪੈਕੇਜ ਨਾਮ ਵੀ ਪਛਾਣ ਦੀਆਂ ਮੁਸ਼ਕਲਾਂ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਉਮੀਦ ਕੀਤੇ ਨਾਮ ਵਾਲੀ ਡਿਪੈਂਡੈਂਸੀ ਗਲਤ ਰਜਿਸਟਰੀ ਤੋਂ ਆ ਸਕਦੀ ਹੈ, lockfile mutable location ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦੀ ਹੈ ਜਾਂ ਬਿਲਡ ਕਦਮ manifest ਤੋਂ ਗੈਰਹਾਜ਼ਰ ਕੋਡ ਡਾਊਨਲੋਡ ਕਰ ਸਕਦਾ ਹੈ। resolved sources, hashes, signatures ਜਿੱਥੇ ecosystem ਇਹ ਸਹਾਇਤਾ ਕਰਦਾ ਹੋਵੇ ਅਤੇ ਬਿਲਡ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਦੀ ਜਾਂਚ ਕਰੋ। ਏਜੰਟ ਅਸੰਗਤੀਆਂ ਸਮਝਾ ਸਕਦਾ ਹੈ, ਪਰ ਬਿਲਡ ਸਿਸਟਮ ਨੂੰ ਉਹ ਸਰੋਤ ਲਾਗੂ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਹ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ।

ਅਪਗ੍ਰੇਡ ਆਪਣੇ ਆਪ ਸੁਰੱਖਿਅਤ ਤਬਦੀਲੀਆਂ ਨਹੀਂ ਹੁੰਦੇ। ਸੁਰੱਖਿਆ ਰਿਲੀਜ਼ parsing, authorization defaults ਜਾਂ serialization ਬਦਲ ਸਕਦੀ ਹੈ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਤੋੜ ਸਕਦੀ ਹੈ। ਐਡਵਾਈਜ਼ਰੀ ਲਈ ਛੋਟਾ reproduction ਬਣਾਓ, isolated branch ਵਿੱਚ ਅਪਗ੍ਰੇਡ ਲਾਗੂ ਕਰੋ ਅਤੇ ਸੁਰੱਖਿਆ ਸਬੂਤ ਅਤੇ ਫੰਕਸ਼ਨਲ ਟੈਸਟ ਦੋਵੇਂ ਚਲਾਓ। ਇਹ ਸਬੂਤ ਫੈਸਲੇ ਦਾ ਆਧਾਰ ਬਣਦਾ ਹੈ; ਮਾਡਲ ਦਾ ਇਹ ਕਹਿਣਾ ਕਿ ਨਵਾਂ ਵਰਜ਼ਨ «ਸ਼ਾਇਦ compatible ਹੋਵੇਗਾ» ਕਾਫ਼ੀ ਨਹੀਂ।

ਗਲਤ ਪੌਜ਼ਿਟਿਵ ਸਬੂਤ ਡਿਜ਼ਾਈਨ ਦੀ ਸਮੱਸਿਆ ਹਨ

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

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

ਫਿਰ disposition ਲਈ ਸਧਾਰਨ ਸ਼ਬਦ ਵਰਤੋ: confirmed, likely, needs context, not reproducible, accepted risk ਜਾਂ fixed। «False positive» ਦਾ ਮਤਲਬ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸੁਰੱਖਿਆ ਦਾਅਵਾ ਗਲਤ ਹੈ, ਨਾ ਕਿ ਟੀਮ ਨੂੰ severity ਪਸੰਦ ਨਹੀਂ ਜਾਂ ਉਸ ਨੇ ਕੰਮ ਮੁਲਤਵੀ ਕਰ ਦਿੱਤਾ ਹੈ। ਇਨ੍ਹਾਂ ਫੈਸਲਿਆਂ ਨੂੰ ਮਿਲਾਉਣ ਨਾਲ feedback ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਜੇ ਹਰ ਅਣਚਾਹੇ ਟਿਕਟ ਨੂੰ ਇੱਕੋ ਲੇਬਲ ਮਿਲੇ, ਤਾਂ ਏਜੰਟ ਨਹੀਂ ਸਿੱਖ ਸਕਦਾ ਕਿ ਕਿਹੜਾ ਨਿਯਮ ਅਸਫਲ ਹੋਇਆ।

AI duplicate traces ਨੂੰ ਕਲੱਸਟਰ ਕਰਕੇ, sanitizers ਦੀ ਜਾਂਚ ਕਰਕੇ ਅਤੇ ਫਿਕਸ ਤੋਂ ਬਾਅਦ ਮੁੜ ਟੈਸਟ ਕਰਕੇ ਸ਼ੋਰ ਘਟਾ ਸਕਦਾ ਹੈ। ਇਹ ਇੱਕ ਕਮਜ਼ੋਰ ਸ਼ੱਕ ਦੇ ਦਸ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰੂਪ ਬਣਾ ਕੇ ਸ਼ੋਰ ਵਧਾ ਵੀ ਸਕਦਾ ਹੈ। URL ਦੇ ਆਧਾਰ ਉੱਤੇ ਨਹੀਂ, root cause ਅਤੇ boundary ਦੇ ਆਧਾਰ ਉੱਤੇ deduplicate ਕਰੋ। ਅੱਠ ਐਂਡਪੌਇੰਟਾਂ ਵੱਲੋਂ ਵਰਤੀ ਇੱਕ ownership check ਦੀ ਗੈਰਹਾਜ਼ਰੀ ਇੱਕ engineering defect ਹੈ ਜਿਸ ਦੇ ਅੱਠ exposure points ਹਨ।

ਸ਼੍ਰੇਣੀ ਅਤੇ ਟੈਸਟ ਸਰੋਤ ਅਨੁਸਾਰ precision ਮਾਪੋ। ਜੇ ਏਜੰਟ ਵੱਲੋਂ ਬਣਾਈਆਂ cross-site scripting ਰਿਪੋਰਟਾਂ ਆਮ ਤੌਰ ਉੱਤੇ ਸਹੀ ਹਨ ਪਰ race-condition ਦਾਅਵੇ ਘੱਟ ਹੀ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਰੂਟ ਕਰੋ। ਵੱਖ-ਵੱਖ defect types ਲਈ ਇੱਕੋ score ਵਿੱਚ performance ਨਾ ਘਟਾਓ। ਗੇਟ evidence ਅਤੇ policy ਉੱਤੇ ਫੇਲ੍ਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਮਾਡਲ ਦੇ confidence adjective ਉੱਤੇ ਨਹੀਂ।

Ownership ਇਸ ਚੱਕਰ ਨੂੰ ਪੂਰਾ ਕਰਦੀ ਹੈ। ਹਰ accepted finding ਲਈ remediation ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਵਾਲਾ ਵਿਅਕਤੀ ਜਾਂ ਟੀਮ, ਉਮੀਦ ਕੀਤਾ retest method ਅਤੇ ਦੂਜੇ tester ਵੱਲੋਂ ਚਲਾਇਆ ਜਾ ਸਕਣ ਵਾਲਾ ਸੰਭਾਲਿਆ proof ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਰਿਪੋਰਟ ਸਿਰਫ਼ ਏਜੰਟ ਗੱਲਬਾਤ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ, ਤਾਂ ਗੱਲਬਾਤ, ਮਾਡਲ ਜਾਂ ਵੈਂਡਰ ਬਦਲਣ ਉੱਤੇ ਇਹ ਗਾਇਬ ਹੋ ਜਾਵੇਗੀ। ਸੁਰੱਖਿਆ ਕੰਮ ਟਿਕਾਊ ਤਦ ਬਣਦਾ ਹੈ ਜਦੋਂ ਸਬੂਤ ਉਸ ਟੂਲ ਤੋਂ ਬਚਿਆ ਰਹੇ ਜਿਸ ਨੇ ਉਹ ਬਣਾਇਆ।

ਟ੍ਰਾਇਜ ਦੌਰਾਨ privacy ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਸਰੋਤ ਕੋਡ, ਰਿਕਵੈਸਟ ਬਾਡੀ, ਲੌਗ ਅਤੇ ਡੇਟਾਬੇਸ ਨਮੂਨਿਆਂ ਵਿੱਚ ਕ੍ਰੈਡੈਂਸ਼ਲ ਜਾਂ ਗਾਹਕ ਡੇਟਾ ਹੋ ਸਕਦਾ ਹੈ। ਏਜੰਟ ਨੂੰ ਮਿਲਣ ਵਾਲੀ ਸਮੱਗਰੀ ਘਟਾਓ, ਸੰਭਾਲੀਆਂ transcripts ਵਿੱਚੋਂ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਹਟਾਓ, ਟੈਸਟ ਡੇਟਾ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾ ਤੋਂ ਵੱਖ ਰੱਖੋ ਅਤੇ ਮਾਡਲ ਪ੍ਰੋਵਾਈਡਰ ਅਤੇ ਉਸ ਦੇ ਟੂਲਾਂ ਉੱਤੇ ਸੰਸਥਾ ਦੇ ਮਨਜ਼ੂਰ data-handling ਨਿਯਮ ਲਾਗੂ ਕਰੋ। ਬਿਹਤਰ detection ਕਿਸੇ ਬੇਕਾਬੂ prompt ਵਿੱਚ ਪੂਰੀ production incident ਕਾਪੀ ਕਰਨ ਨੂੰ ਜਾਇਜ਼ ਨਹੀਂ ਬਣਾਉਂਦੀ।

ਮਨੁੱਖੀ ਪੈਠ ਜਾਂਚ ਟੈਸਟ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀਆਂ ਧਾਰਣਾਵਾਂ ਜਾਂਚਦੀ ਹੈ

ਕੁਸ਼ਲ ਪੈਠ ਜਾਂਚਕਾਰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ brief ਨਾਲ ਵਿਰੋਧ ਹੋਣ ਉੱਤੇ ਯੋਜਨਾ ਬਦਲਦਾ ਹੈ। ਏਜੰਟਾਂ ਨੇ ਇਸ ਹਿੱਸੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲਈ। ਮਨੁੱਖ ਮਾਲਕਾਂ ਨਾਲ ਗੱਲ ਕਰਦਾ, ਅਸਪਸ਼ਟ ਨਿਯਮ ਸਪਸ਼ਟ ਕਰਦਾ, ਓਪਰੇਸ਼ਨਲ ਸ਼ਾਰਟਕੱਟ ਵੇਖਦਾ, ਹੋਰ ਪਛਾਣ ਮੰਗਦਾ ਅਤੇ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਅਜੀਬ ਵਿਹਾਰ ਲੰਬੇ ਪ੍ਰਯੋਗਾਂ ਦੀ ਲੜੀ ਦੇ ਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ।

ਮਨੁੱਖ ਅਧੂਰੇ ਸਬੂਤ ਵਿੱਚ ਫੈਸਲੇ ਲਈ ਵੀ ਜ਼ਿੰਮੇਵਾਰ ਹੁੰਦੇ ਹਨ। ਉਹ ਤਕਨੀਕੀ ਤੌਰ ਉੱਤੇ ਸੰਭਵ ਕਾਰਵਾਈ ਅਤੇ ਭਰੋਸੇਯੋਗ ਹਮਲਾ ਰਸਤੇ ਵਿੱਚ ਫਰਕ ਕਰ ਸਕਦੇ ਹਨ, ਮਿਲੀ-ਜੁਲੀ ਅਸਫਲਤਾ ਨੂੰ executives ਅਤੇ engineers ਨੂੰ ਸਮਝਾ ਸਕਦੇ ਹਨ ਅਤੇ ਜਦੋਂ exploitation ਡੇਟਾ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੀ ਹੋਵੇ ਤਾਂ ਸੁਰੱਖਿਅਤ proof ਉੱਤੇ ਸਹਿਮਤ ਹੋ ਸਕਦੇ ਹਨ। ਖੁਦਮੁਖਤਿਆਰ ਏਜੰਟ ਨੂੰ ਉਸ ਹੱਦ ਉੱਤੇ ਰੁਕਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਓਪਰੇਟਰ ਨੇ ਨਿਰਧਾਰਤ ਕੀਤੀ ਹੈ। ਜੇ ਇਹ ਹੱਦ ਚੁੱਪਚਾਪ ਵਧਾ ਦੇਵੇ, ਤਾਂ ਇਹ ਆਪ ਇੱਕ ਹੋਰ ਸੁਰੱਖਿਆ ਖਤਰਾ ਬਣ ਜਾਂਦਾ ਹੈ।

ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਰਿਲੀਜ਼ ਲਈ ਇੱਕ ਹਫ਼ਤੇ ਦੀ ਬਾਹਰੀ engagement ਲੋੜੀਂਦੀ ਹੈ। ਜਿੱਥੇ ਤਬਦੀਲੀ ਅਤੇ ਪ੍ਰਭਾਵ ਮਿਲਦੇ ਹਨ, ਉੱਥੇ ਮਨੁੱਖੀ ਜਾਂਚ ਵਰਤੋ: ਨਵਾਂ authorization model, tenant architecture, payment ਜਾਂ credit flow, administrative plane, ਸੰਵੇਦਨਸ਼ੀਲ integration, ਵੱਡੀ migration ਜਾਂ public launch। ਖਤਰੇ ਅਨੁਸਾਰ ਵੱਡੇ ਸਮੇਂ-ਸਮੇਂ ਵਾਲੇ ਕੰਮ ਤਹਿ ਕਰੋ ਅਤੇ ਗੰਭੀਰ ਫਿਕਸਾਂ ਦੀ ਮੁੜ ਜਾਂਚ ਕਰੋ। ਰੁਟੀਨ ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਫਿਰ ਵੀ automated coverage ਚਾਹੀਦੀ ਹੈ।

ਜਾਂਚਕਾਰ ਨੂੰ ਏਜੰਟ ਦਾ ਆਉਟਪੁੱਟ, SAST traces, DAST coverage, architecture notes, test accounts ਅਤੇ unresolved assumptions ਦਿਓ। ਏਜੰਟ reconnaissance ਅਤੇ ਦੁਹਰਾਈਆਂ variations ਸੰਭਾਲ ਸਕਦਾ ਹੈ, ਜਦਕਿ ਜਾਂਚਕਾਰ ਅਣਉਮੀਦ ਵਿਹਾਰ ਦਾ ਪਿੱਛਾ ਕਰਦਾ ਹੈ। ਇਸ ਨਾਲ ਮਨੁੱਖੀ ਸਮਾਂ ਵਧੇਰੇ ਉਪਯੋਗੀ ਬਣਦਾ ਹੈ, ਮਨੁੱਖ ਨੂੰ ਬੇਲੋੜਾ ਦਿਖਾਏ ਬਿਨਾਂ।

«Autonomous pentest» ਦੇ ਦਾਅਵਿਆਂ ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਿਰਫ਼ findings ਦੀ ਗਿਣਤੀ ਨਾਲ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ। ਦਸ ਜਾਣੇ-ਪਛਾਣੇ injection findings, role assignment, stale authorization ਅਤੇ export storage ਰਾਹੀਂ ਇੱਕ ਸਾਬਤ path ਦੇ ਬਰਾਬਰ ਨਹੀਂ। ਕੰਮ ਨੂੰ ਜਾਂਚੀਆਂ ਹੱਦਾਂ, ਸਬੂਤ ਦੀ ਗੁਣਵੱਤਾ ਅਤੇ ਚੁਣੌਤੀ ਦਿੱਤੀਆਂ ਮਹੱਤਵਪੂਰਨ ਧਾਰਣਾਵਾਂ ਦੇ ਆਧਾਰ ਉੱਤੇ ਮਾਪੋ।

Engagement ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੋ ਕਿ cleanup ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਕਿਸ ਦੀ ਹੈ। Test accounts, uploaded files, queued messages, temporary roles ਅਤੇ ਬਦਲੇ ਹੋਏ feature flags scan ਤੋਂ ਬਾਅਦ ਵੀ ਰਹਿ ਸਕਦੇ ਹਨ। ਮਨੁੱਖੀ lead ਨੂੰ destructive proofs ਮਨਜ਼ੂਰ ਕਰਨੇ, operations ਨਾਲ ਸੰਪਰਕ ਰੱਖਣਾ ਅਤੇ restoration ਦੀ ਪੁਸ਼ਟੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਏਜੰਟ cleanup script ਚਲਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਫੈਸਲਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ production ਦੀ ਕੋਈ ਅਣਜਾਣ ਸਥਿਤੀ ਹਟਾਉਣ ਲਈ ਸੁਰੱਖਿਅਤ ਹੈ ਜਾਂ ਨਹੀਂ।

ਚੰਗਾ ਜਾਂਚਕਾਰ ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਜਾਂਚਿਆ ਨਹੀਂ ਜਾ ਸਕਿਆ। ਗੁੰਮ mobile builds, ਅਣਉਪਲਬਧ roles, rate limits, third-party callbacks ਅਤੇ ਅਸਥਿਰ ਵਾਤਾਵਰਣ assurance ਘਟਾਉਂਦੇ ਹਨ। ਏਜੰਟ ਰੁਕਾਵਟਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕੰਮ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਸਿਰਫ਼ ਪੂਰੇ ਕੀਤੇ ਰਸਤੇ ਦਿਖਾ ਸਕਦੇ ਹਨ। ਅੰਤਿਮ ਰਿਪੋਰਟ ਵਿੱਚ exclusions ਸਪਸ਼ਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਤਾਂ ਜੋ ਸਾਫ਼ ਨਤੀਜੇ ਨੂੰ ਪੂਰੀ ਕਵਰੇਜ ਨਾ ਸਮਝਿਆ ਜਾਵੇ।

ਕਈ ਕਿਸਮਾਂ ਦੇ ਸਬੂਤਾਂ ਨਾਲ ਇੱਕ ਗੇਟ ਬਣਾਓ

ਸਹੀ ਪ੍ਰੋਗਰਾਮ ਹਰ ਢੰਗ ਨੂੰ ਇੱਕ ਕੰਮ ਦਿੰਦਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਆਉਟਪੁੱਟ ਨੂੰ ਇੱਕੋ ਸੁਰੱਖਿਆ ਲੋੜ ਉੱਤੇ ਮਿਲਾਉਂਦਾ ਹੈ। ਨਿਰਧਾਰਤ ਸਰੋਤ ਪੈਟਰਨ ਅਤੇ ਵਿਆਪਕ change coverage ਲਈ SAST ਵਰਤੋ। ਡਿਪੈਂਡੈਂਸੀ ਅਤੇ ਬਿਲਡ ਤੱਥਾਂ ਲਈ SCA ਅਤੇ provenance ਵਰਤੋ। ਡਿਪਲੌਇ ਕੀਤੇ ਵਿਹਾਰ ਅਤੇ baseline runtime checks ਲਈ DAST ਵਰਤੋ। ਸਬੂਤ ਜੋੜਨ, authenticated flows ਦੀ ਖੋਜ, ਟੈਸਟ ਬਣਾਉਣ ਅਤੇ triage ਸੁਧਾਰਨ ਲਈ agents ਵਰਤੋ। ਨੀਤੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ, ਕਾਰੋਬਾਰੀ ਧਾਰਣਾਵਾਂ ਨੂੰ ਚੁਣੌਤੀ ਦੇਣ ਅਤੇ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੀਆਂ ਤਬਦੀਲੀਆਂ ਦੀ ਜਾਂਚ ਲਈ ਮਨੁੱਖ ਵਰਤੋ।

ਫਿਰ ਰਿਲੀਜ਼ ਨੀਤੀ ਖਾਸ ਹੋ ਸਕਦੀ ਹੈ। ਬਿਲਡ ਰੋਕੋ ਜਦੋਂ unapproved path ਉੱਤੇ deterministic high-severity rule match ਕਰੇ, ਲੋੜੀਂਦਾ authorization invariant fail ਹੋਵੇ, cross-tenant marker ਦਿਖਾਈ ਦੇਵੇ ਜਾਂ confirmed exploit ਖੁੱਲ੍ਹਾ ਰਹੇ। ਅਨਿਸ਼ਚਿਤ agent findings ਨੂੰ exposure ਅਨੁਸਾਰ deadline ਨਾਲ review ਲਈ ਭੇਜੋ। Production ship ਕਰਨੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਸ ਦਾ ਫੈਸਲਾ ਮਾਡਲ ਦੀ ਆਪਣੀ confidence ਰਿਪੋਰਟ ਨੂੰ ਨਾ ਕਰਨ ਦਿਓ।

ਸਬੂਤ portable ਰੱਖੋ। Findings, generated tests, request transcripts, tool versions, revisions, identities, coverage ਅਤੇ dispositions ਅਜਿਹੇ formats ਵਿੱਚ export ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਟੀਮ ਏਜੰਟ ਤੋਂ ਬਿਨਾਂ ਦੇਖ ਸਕੇ। ਇਹ audits, incident review, vendor ਤਬਦੀਲੀਆਂ ਅਤੇ ਉਸ ਆਮ ਦਿਨ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਦੋਂ model update ਵਿਹਾਰ ਬਦਲ ਦੇਵੇ।

ਚੈਟ ਰਾਹੀਂ ਬਣਾਈਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਵੀ ਇਹੀ ਵੱਖਰਾ ਰੱਖਣ ਦਾ ਨਿਯਮ ਹੈ। Koder.ai web, server ਅਤੇ mobile applications ਤਿਆਰ ਕਰਕੇ ਉਨ੍ਹਾਂ ਦਾ source export ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਤਿਆਰ ਸੌਫਟਵੇਅਰ ਨੂੰ ਫਿਰ ਵੀ ਸਪਸ਼ਟ security requirements ਅਤੇ deployed result ਉੱਤੇ independent tests ਚਾਹੀਦੇ ਹਨ। ਤੇਜ਼ creation ਸਪਸ਼ਟ gate ਨੂੰ ਹੋਰ ਲਾਭਦਾਇਕ ਬਣਾਉਂਦੀ ਹੈ, ਕਿਉਂਕਿ architecture ਅਤੇ code ਜਲਦੀ ਬਦਲ ਸਕਦੇ ਹਨ।

ਏਜੰਟ ਨੂੰ ਲਗਾਤਾਰ ਚਲਾਓ, ਪਰ ਇਸ ਦੀਆਂ ਵਧੀਆ ਖੋਜਾਂ ਨੂੰ deterministic regression tests ਵਿੱਚ ਬਦਲੋ। ਹਰ confirmed authorization bypass policy case ਬਣੇ। ਹਰ tenant leak ਉਸ boundary ਉੱਤੇ invariant ਜੋੜੇ ਜਿੱਥੇ ਅਸਫਲਤਾ ਹੋਈ। ਹਰ noisy rule ਨੂੰ recorded disposition ਮਿਲੇ। ਸਮੇਂ ਦੇ ਨਾਲ ਏਜੰਟ ਨੂੰ test system ਨੂੰ ਪਹਿਲਾਂ ਨਾਲੋਂ ਵੱਧ precise ਛੱਡਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਹ ਨਾ ਪੁੱਛੋ ਕਿ ਇੱਕੋ ਟੂਲ ਕੌਣ ਜਿੱਤਦਾ ਹੈ। ਪੁੱਛੋ ਕਿ ਹਰ ਮਹੱਤਵਪੂਰਨ ਦਾਅਵੇ ਲਈ ਸੁਤੰਤਰ ਸਬੂਤ ਹੈ ਜਾਂ ਨਹੀਂ: code path ਦੀ ਸਮੀਖਿਆ ਹੋਈ, deployed behavior ਚਲਾਇਆ ਗਿਆ, business rule ਮਾਲਕ ਤੋਂ ਆਇਆ ਅਤੇ ਜਿੱਥੇ ਅਸਫਲਤਾ ਨੁਕਸਾਨ ਕਰੇਗੀ ਉੱਥੇ ਕਿਸੇ ਮਨੁੱਖ ਨੇ ਧਾਰਣਾਵਾਂ ਨੂੰ ਚੁਣੌਤੀ ਦਿੱਤੀ। ਜੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਲਾਈਨ ਖਾਲੀ ਹੈ, ਤਾਂ AI ਵੱਲੋਂ ਤਿਆਰ ਕੀਤਾ «all clear» ਉਸ ਨੂੰ ਨਹੀਂ ਭਰ ਸਕਦਾ।