20 ਨਵੰ 2025·8 ਮਿੰਟ
ਵਲਨਰੇਬਿਲਿਟੀ ਡਿਕਲੋਜ਼ਰ ਪ੍ਰੋਗਰਾਮ: ਛੋਟੀਆਂ ਟੀਮਾਂ ਲਈ ਸ਼ੁਰੂਆਤੀ ਗਾਈਡ
ਸਮਝੋ ਕਿ vulnerability disclosure program ਕੀ ਹੁੰਦਾ ਹੈ, ਸਿਰਫ਼ ਵਪਾਰਕ ਦਲੀਲ ਨਹੀਂ—ਛੋਟੀਆਂ ਟੀਮਾਂ ਲਈ ਸਕੋਪ, ਟ੍ਰਾਇਅਜ ਅਤੇ ਸਮਾਂ-ਰੇਖਾ ਕਿਵੇਂ ਨਿਰਧਾਰਤ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ।
ਸਮਝੋ ਕਿ vulnerability disclosure program ਕੀ ਹੁੰਦਾ ਹੈ, ਸਿਰਫ਼ ਵਪਾਰਕ ਦਲੀਲ ਨਹੀਂ—ਛੋਟੀਆਂ ਟੀਮਾਂ ਲਈ ਸਕੋਪ, ਟ੍ਰਾਇਅਜ ਅਤੇ ਸਮਾਂ-ਰੇਖਾ ਕਿਵੇਂ ਨਿਰਧਾਰਤ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਸੁਰੱਖਿਆ ਫੀਡਬੈਕ ਹੁੰਦੀ ਹੈ। ਪਰ ਉਹਨਾਂ ਕੋਲ ਇਸਦੇ ਲੀਏ ਇੱਕ ਸੁਰੱਖਿਅਤ ਥਾਂ ਨਹੀਂ ਹੁੰਦੀ।
ਇੱਕ vulnerability disclosure program (VDP) ਖੋਜਕਾਰਾਂ ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਮੁੱਦੇ ਰਿਪੋਰਟ ਕਰਨ ਦਾ ਇੱਕ ਸਾਫ਼, ਕਾਨੂੰਨੀ ਅਤੇ ਇਜ਼ਜ਼ਤਦਾਰ ਤਰੀਕਾ ਦਿੰਦਾ ਹੈ, ਪਹਿਲਾਂ ਦੀਆਂ ਖਬਰਾਂ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ। ਬਿਨਾਂ ਨੀਤੀ ਦੇ, ਰਿਪੋਰਟਾਂ ਸਭ ਤੋਂ ਗਲਤ ਵੇਲੇ, ਗਲਤ ਚੈਨਲ ਰਾਹੀਂ, ਅਤੇ ਅਸਪਸ਼ਟ ਉਮੀਦਾਂ ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ। ਇੱਕ ਚੰਗਾ-ਨیتی ਖੋਜਕਾਰ ਨੂੰ ਨਿੱਜੀ ਈਮੇਲ ਦੇ ਸਕਦਾ ਹੈ, ਧਿਆਨ ਖਿੱਚਣ ਲਈ ਪਬਲਿਕ ਪੋਸਟ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਜਵਾਬ ਮਿਲਣ ਤੱਕ ਨਿਰਤੰਤਰ ਪਰਖ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ। ਪਰ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਨਾਲ, ਹਰ ਕੋਈ ਜਾਣਦਾ ਹੈ ਕਿ ਰਿਪੋਰਟ ਕਿੱਥੇ ਭੇਜਣੀਆਂ ਹਨ, ਕਿਹੜੀ ਟੈਸਟਿੰਗ ਮਨਜ਼ੂਰ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਅਗਲਾ قدم ਕੀ ਲਵੇਗੀ।
ਮੁੱਦੇ ਪਹਿਲਾਂ ਲੱਭਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਬੱਗ ਦੇ ਦੁਰੁਪਯੋਗ ਹੋਣ 'ਤੇ ਖਰਚ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਛੋਟੀ ਅਥੈਂਟ ਘਲਤੀ ਜੋ ਇੱਕ ਸ਼ਾਂਤ ਹਫ਼ਤੇ ਵਿੱਚ ਪਕੜੀ ਜਾਂਦੀ ਹੈ ਉਹ ਇੱਕ ਦਿਨ ਦੀ ਫਿਕਸ ਹੋ ਸਕਦੀ ਹੈ। ਉਹੀ ਗਲਤੀ ਜਦੋਂ ਬਦਨੀਆਂ ਨੇ ਵਰਤੀ ਤਾਂ ਐਮਰਜੈਂਸੀ ਪੈਚ, ਇੰਸੀਡੈਂਟ ਰਿਸਪਾਂਸ, ਗਾਹਕ ਸਹਾਇਤਾ ਅਤੇ ਤੀਰਕ ਭਰੋਸੇ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚ ਸਕਦਾ ਹੈ।
VDP ਅਤੇ ਬੱਗ ਬਾਊਂਟੀਆਂ ਨੂੰ ਲੈ ਕੇ ਪ੍ਰਯੋਗਿਕ ਸੋਚ:
Katie Moussouris ਨੇ ਇੱਕ ਸਧਾਰਣ ਕਾਰੋਬਾਰੀ ਫਰੇਮਿੰਗ ਨੂੰ ਲੋਕਪ੍ਰਿਯ ਕੀਤਾ ਜਿਸ ਨਾਲ ਕੰਪਨੀਆਂ ਲਈ ਬੱਗ ਬਾਊਂਟੀਆਂ ਮੰਨਣ ਆਸਾਨ ਹੋ ਗਈਆਂ: ਸੁਰੱਖਿਆ ਖੋਜਕਾਰ “ਦੁਸ਼ਮਣ” ਨਹੀਂ ਹਨ। ਉਹ ਗੁਣਵੱਤਾ ਲਈ ਇੱਕ ਪ੍ਰਬੰਧਿਤ, ਸਕਾਰਾਤਮਕ-ਜ਼ੀਰੋ-ਸੰਖਿਆ ਇਨਪੁੱਟ ਹੋ ਸਕਦੇ ਹਨ। ਇਹੀ ਤਰਕ VDPs 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਮੁੱਦੇ ਬੁਲਾ ਰਹੇ ਨਹੀਂ ਹੋ, ਤੁਸੀਂ ਉਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਲਈ ਇੱਕ ਨਿਯੰਤਰਤ ਇੰਟੇਕ ਬਣਾ ਰਹੇ ਹੋ ਜੋ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਮੌਜੂਦ ਹਨ।
ਛੋਟੀ ਟੀਮ ਲਈ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਦੀ ਹੈ (ਮਿਸਾਲ ਵਜੋਂ, ਇੱਕ ਵੈਬ ਐਪ ਜਿਸਦਾ React ਫਰੰਟ-ਐਂਡ ਅਤੇ API ਹੈ), ਫਾਇਦਾ ਆਮ ਤੌਰ 'ਤੇ ਤੁਰੰਤ ਹੁੰਦਾ ਹੈ: ਘੱਟ ਅਚਾਨਕ ਤੇਜ਼-ਬੜ੍ਹੀਆਂ, ਸਪਸ਼ਟ ਫਿਕਸ ਪ੍ਰਾਇਓਰਿਟੀ, ਅਤੇ ਸੁਰੱਖਿਆ ਰਿਪੋਰਟਾਂ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਲੈਣ ਦੀ شہرت।
VDP ਇੱਕ ਸਰਵਜਨਿਕ ਅਤੇ ਪੂਰਵਧਾਰਿਤ ਤਰੀਕਾ ਹੈ ਜਿੱਥੇ ਲੋਕ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਆ ਮੁੱਦੇ ਰਿਪੋਰਟ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰ ਸਕਦੀ ਹੈ। ਇਹ ਇਨਾਮ ਦੇਣ ਵਾਲੇ ਕਾਰਜ ਨਹੀਂ ਹਨ। ਮਕਸਦ ਮੁੱਦਿਆਂ ਨੂੰ ਯੂਜ਼ਰਾਂ ਨੂੰ ਨੁਕਸਾਨ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰਨਾ ਹੈ।
ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਗਰੁੱਪ ਸ਼ਿਰਕਤ ਕਰਦੇ ਹਨ: ਸੁਰੱਖਿਆ ਖੋਜਕਾਰ ਜੋ ਸਰਗਰਮੀਆਂ ਨਾਲ ਮੁੱਦੇ ਲੱਭਦੇ ਹਨ, ਗਾਹਕ ਜੋ ਸ਼ੱਕੀ ਬਰਤਾਵ ਦੇਖਦੇ ਹਨ, ਅਤੇ ਕਰਮਚਾਰੀ ਜਾਂ ਠੇਕੇਦਾਰ ਜੋ ਆਮ ਕੰਮ ਦੌਰਾਨ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਨੋਟ ਕਰਦੇ ਹਨ। ਉਹਨਾਂ ਸਭ ਦੀ ਇੱਕ ਸਧਾਰਣ ਰਿਪੋਰਟਿੰਗ ਰਾਹ ਚਾਹੀਦੀ ਹੈ।
ਰਿਪੋਰਟਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਮਰਪਿਤ ਈਮੇਲ ਪਤਾ, ਇੱਕ ਵੈਬ ਫਾਰਮ, ਜਾਂ ਟਿਕਟਿੰਗ ਇੰਟੇਕ ਰਾਹੀਂ ਆਉਂਦੀਆਂ ਹਨ। ਛੋਟੀ ਟੀਮ ਲਈ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਨਬਾਕਸ ਦੀ ਮਲਕੀਅਤ ਕਿਸੇ ਕੋਲ ਹੋਵੇ, ਨਿਗਰਾਨੀ ਹੋਵੇ, ਅਤੇ ਇਹ ਸਧਾਰਨ ਸਹਾਇਤਾ ਤੋਂ ਵੱਖਰਾ ਹੋਵੇ।
ਇੱਕ ਮਜ਼ਬੂਤ ਰਿਪੋਰਟ ਤੁਹਾਨੂੰ ਜਲਦੀ ਦੁਹਰਾਉਣ ਯੋਗ ਵੇਰਵਾ ਦਿੰਦੀ ਹੈ: ਕੀ ਲੱਭਿਆ ਗਿਆ, ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਦੁਹਰਾਉਣ ਲਈ ਕਦਮ, ਕਿਹੜਾ ਸਿਸਟਮ ਜਾਂ ਐਂਡਪੌਇੰਟ ਪ੍ਰਭਾਵਿਤ ਹੈ, ਅਤੇ ਪ੍ਰਭਾਵ ਦਾ ਸਬੂਤ। ਸੁਝਾਅਤ ਸਮਾਧਾਨ ਚੰਗੇ ਹਨ ਪਰ ਲਾਜ਼ਮੀ ਨਹੀਂ।
ਰਿਪੋਰਟ ਮਿਲਣ 'ਤੇ ਤੁਸੀਂ ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਕੁਝ ਵਾਅਦੇ ਕਰਦੇ ਹੋ, ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ responsible disclosure policy ਵਿੱਚ। ਛੋਟੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਸਿਰਫ ਉਹੀ ਵਾਅਦੇ ਕਰੋ ਜੋ ਤੁਸੀਂ ਰੱਖ ਸਕਦੇ ਹੋ। ਘੱਟੋ-ਘੱਟ: ਤੁਸੀਂ ਰਿਪੋਰਟ ਨੂੰ ਅਕਨਾਲੇਜ ਕਰੋਗੇ, ਬੁਨਿਆਦੀ ਟ੍ਰਾਇਅਜ ਕਰੋਂਗੇ, ਅਤੇ ਰਿਪੋਰਟਰ ਨੂੰ ਅਪਡੇਟ ਰੱਖੋਗੇ।
ਪਿੱਛੇ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਸਿੱਧੀ ਹੁੰਦੀ ਹੈ: ਪ੍ਰਾਪਤੀ ਦੀ ਪੁਸ਼ਟੀ, ਮੁੱਦੇ ਦੀ ਪੁਸ਼ਟੀ, ਗੰਭੀਰਤਾ ਦਾ ਅੰਦਾਜ਼ਾ, ਮਾਲਕ ਨਿਰਧਾਰਿਤ ਕਰਨਾ, ਫਿਕਸ ਕਰਨਾ, ਅਤੇ ਹੱਲ ਹੋਣ ਤੱਕ ਸਥਿਤੀ ਬਾਰੇ ਸੰਚਾਰ ਕਰਨਾ। ਜੇ ਤੁਸੀਂ ਤੁਰੰਤ ਫਿਕਸ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਨਿਯਮਤ ਅਪਡੇਟ ਭਰੋਸਾ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ ਦੁਹਰਾਉਣ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
VDP ਮੂਲ ਭੂਮਿਕਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਸੁਰੱਖਿਅਤ ਰਿਪੋਰਟਿੰਗ ਰਾਹ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹੋ, ਦੱਸਦੇ ਹੋ ਕਿ ਕਿਹੜੀ ਟੈਸਟਿੰਗ ਮਨਜ਼ੂਰ ਹੈ, ਅਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਨ ਦਾ ਵਾਅਦਾ ਕਰਦੇ ਹੋ। ਪੈਸਾ ਲੈਣਾ ਲਾਜ਼ਮੀ ਨਹੀਂ। ਮੁਲਾਕਾਤ ਦੋਹਾਂ ਪਾਸਿਆਂ ਉੱਤੇ ਸਪਸ਼ਟਤਾ ਅਤੇ ਚੰਗੇ ਇਰਾਦੇ ਦਾ ਹੁੰਦੀ ਹੈ।
ਬੱਗ ਬਾਊਂਟੀ ਇਨਾਮ ਜੋੜਦੀ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਸਿੱਧਾ ਚਲਾਉਂਦੇ ਹੋ (ਈਮੇਲ ਅਤੇ ਪੇਆਊਟ ਤਰੀਕਾ) ਜਾਂ ਕਿਸੇ ਪਲੇਟਫਾਰਮ ਰਾਹੀਂ ਜੋ ਖੋਜਕਾਰਾਂ ਤੱਕ ਪਹੁੰਚ, ਰਿਪੋਰਟ ਹੈਂਡਲਿੰਗ ਅਤੇ ਭੁਗਤਾਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਵਾਤਾਵਰਣ ਜ਼ਿਆਦਾ ਧਿਆਨ ਅਤੇ ਵੋਲਿਊਮ ਲਿਆਉਂਦਾ ਹੈ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਦਬਾਅ ਵਧਦਾ ਹੈ।
ਬਾਊਂਟੀ ਤਦ ਹੀ ਸਮਝਦਾਰ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਹਾਡੀ ਟੀਮ ਇਹ ਨਿਭਾ ਸਕੇ। ਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ ਰੋਜ਼ ਬਦਲਦਾ ਹੈ, ਲੌਗਿੰਗ ਕਮਜ਼ੋਰ ਹੈ, ਜਾਂ ਕਿਸੇ ਕੋਲ ਵੀ ਸੁਰੱਖਿਆ ਟ੍ਰਾਇਅਜ ਦੀ ਮਲਕੀਅਤ ਨਹੀਂ, ਤਾਂ ਬਾਊਂਟੀ ਇੱਕ ऐसी ਕਤਾਰ ਬਣਾਈਗਾ ਜੋ ਤੁਸੀਂ ਸਾਫ਼ ਨਹੀਂ ਕਰ ਸਕੋਗੇ। ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਥਿਰ ਸਰਫੇਸ, ਖੋਜ ਲਾਇਕ ਪ੍ਰਾਪਤੀ ਪਾਉਣ ਲਈ ਕਾਫੀ ਐਕਸਪੋਜ਼ਰ, ਹੋਰਤੀ ਤੌਰ 'ਤੇ ਦਿਨਾਂ ਜਾਂ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਟ੍ਰਾਇਅਜ ਅਤੇ ਫਿਕਸ ਕਰਨ ਦੀ ਸਮਰੱਥਾ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਬਜਟ ਅਤੇ ਭੁਗਤਾਨ ਤਰੀਕਾ ਹੋਵੇ ਤਾਂ ਬਾਊਂਟੀ ਬਾਰੇ ਸੋਚੋ।
ਇਨਾਮ ਲਈ, ਇਸਨੂੰ ਸਧਾਰਨ ਰੱਖੋ: ਗੰਭੀਰਤਾ ਦੇ ਅਧਾਰ 'ਤੇ ਫਿਕਸ ਰੇਂਜ (low ਤੋਂ critical), ਅਤੇ ਅਸਧਾਰਣ ਤੌਰ 'ਤੇ ਸਪੱਸ਼ਟ, ਦੁਹਰਾਉਣ ਯੋਗ ਰਿਪੋਰਟਾਂ ਲਈ ਛੋਟੇ ਬੋਨਸ।
ਭੁਗਤਾਨ ਸਿਰਫ ਕਾਰੋਬਾਰੀ ਕੇਸ ਦਾ ਇੱਕ ਹਿੱਸਾ ਹਨ। ਵੱਡਾ ਫਾਇਦਾ ਪਹਿਲਾਂ ਚੇਤਾਵਨੀ ਅਤੇ ਘੱਟ ਖਤਰੇ ਵਿੱਚ ਹੈ: ਘੱਟ ਹੈਰਾਨੀ ਵਾਲੇ ਘਟਨਾਵਾਂ, ਇੰਜੀਨੀਅਰਿੰਗ 'ਚ ਬਿਹਤਰ ਸੁਰੱਖਿਆ ਆਦਤਾਂ, ਅਤੇ ਗਾਹਕ ਸਮੀਖਿਆ ਦੌਰਾਨ ਦਿਖਾਉਣ ਲਈ ਦਸਤਾਵੇਜ਼ਬੱਧ ਪ੍ਰਕਿਰਿਆ।
ਇੱਕ ਚੰਗਾ VDP ਇੱਕ ਵਾਅਦੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਉਹਨਾਂ ਰਿਪੋਰਟਾਂ ਨੂੰ ਦੇਖੋਂਗੇ ਜੋ ਤੁਸੀਂ ਵਾਸਤਵ ਵਿੱਚ ਪੁਸ਼ਟੀ ਅਤੇ ਫਿਕਸ ਕਰ ਸਕਦੇ ਹੋ। ਜੇ ਸਕੋਪ ਬਹੁਤ ਵਿਆਪਕ ਹੈ, ਤਾੰ ਰਿਪੋਰਟਾਂ ਇਕੱਠੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਖੋਜਕਾਰ ਨਿਰਾਸ਼ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਜੋ ਭਰੋਸਾ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਸੀ ਉਹ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ।
ਆਪਣੇ ਆਪ ਨੂੰ ਅੰਤ ਤੋਂ ਅੰਤ ਤੱਕ ਦੇਖਣ ਵਾਲੀਆਂ ਸੰਪਤੀਆਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜ਼ਿਆਦਾਤਰ ਛੋਟੀ ਟੀਮਾਂ ਲਈ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਪ੍ਰੋਡਕਸ਼ਨ ਵੈਬ ਐਪ ਅਤੇ ਕੋਈ ਵੀ ਪਬਲਿਕ API ਜੋ ਗਾਹਕ ਵਰਤਦੇ ਹਨ। ਅੰਦਰੂਨੀ ਟੂਲ, ਪੁਰਾਣੇ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਤੀਜੀ ਪੱਖੀ ਸੇਵਾਵਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖੋ ਜਦ ਤੱਕ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਠੀਕ ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਕੀ ਸਕੋਪ ਵਿੱਚ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ। ਕੁਝ ਨਮੂਨੇ ਸ਼ਾਮਲ ਕਰਨ ਨਾਲ ਬਹੁਤ ਘਟ-ਵਿੱਚਾਰ ਹੁੰਦਾ ਹੈ:
ਫਿਰ ਦੱਸੋ ਕਿ ਕਿਹੜੀ ਟੈਸਟਿੰਗ ਮਨਜ਼ੂਰ ਹੈ ਤਾਂ ਕਿ ਕੋਈ ਅਣਜਾਣੇ ਤੌਰ 'ਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਨੁਕਸਾਨ ਨਾ ਪਹੁੰਚਾਏ। ਸੀਮਾਵਾਂ ਸਧਾਰਣ ਰੱਖੋ: ਕੋਈ ਮੈਸ ਸਕੈਨਿੰਗ ਨਹੀਂ, ਰੇਟ ਲਿਮਿਟਸ ਦਾ ਆਦਰ, ਡੋਸ ਟੈਸਟਿੰਗ ਨਹੀਂ, ਅਤੇ ਹੋਰ ਲੋਕਾਂ ਦੇ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਨਾ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਸੀਮਾਨਤ ਟੈਸਟ ਅਕਾਊਂਟਾਂ ਦੀ ਆਗਿਆ ਦੇਣੀ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਸਪਸ਼ਟ ਕਰੋ।
ਅਖੀਰ ਵਿੱਚ, ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਨਾਨ-ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮਾਂ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲੋਗੇ। ਸਟੇਜਿੰਗ ਦੁਹਰਾਈ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ੋਰ ਵਾਲਾ ਅਤੇ ਘੱਟ ਨਿਗਰਾਨੀ ਵਾਲਾ ਹੁੰਦਾ ਹੈ। ਕਈ ਟੀਮਾਂ ਪਹਿਲਾਂ ਸਟੇਜਿੰਗ ਨੂੰ ਬਾਹਰ ਰੱਖਦੀਆਂ ਹਨ ਅਤੇ ਸਿਰਫ ਪ੍ਰੋਡਕਸ਼ਨ ਖੋਜਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੀਆਂ ਹਨ, ਫਿਰ ਲੌਗਿੰਗ ਸਥਿਰ ਹੋਣ ਤੇ ਅਤੇ ਟੈਸਟ ਕਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਹੋਣ 'ਤੇ ਸਟੇਜਿੰਗ ਜੋੜਦੇ ਹਨ।
ਉਦਾਹਰਨ: ਇੱਕ ਛੋਟੀ SaaS ਟੀਮ ਜੋ Koder.ai ਐਪ ਚਲਾਉਂਦੀ ਹੈ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀ ਹੈ "ਪ੍ਰੋਡਕਸ਼ਨ ਐਪ + ਸਾਡੇ ਮੁੱਖ ਡੋਮੇਨ 'ਤੇ ਪਬਲਿਕ API" ਨਾਲ ਅਤੇ ਗਾਹਕਾਂ ਦੀ self-hosted ਡੀਪਲੋਇਮੈਂਟ ਨੂੰ ਇਕਸਪਲਿਸਿਟ ਤੌਰ 'ਤੇ ਬਾਹਰ ਰੱਖ ਸਕਦੀ ਹੈ ਜਦ ਤੱਕ ਟੀਮ ਕੋਲ ਦੁਹਰਾਉਣ ਅਤੇ ਫਿਕਸ ਕਰਨ ਦਾ ਸਪਸ਼ਟ ਤਰੀਕਾ ਨਹੀਂ ਹੁੰਦਾ।
ਚੰਗੇ ਨਿਯਮ ਦੋ ਕੰਮ ਇਕੱਠੇ ਕਰਦੇ ਹਨ: ਉਹ ਅਸਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਖੋਜਕਾਰਾਂ ਨੂੰ ਭਰੋਸਾ ਦਿੰਦਿਆਂ ਹਨ ਕਿ ਉਹ ਚੰਗੇ ਇਰਾਦੇ ਨਾਲ ਰਿਪੋਰਟ ਕਰਨ 'ਤੇ ਸਜ਼ਾ ਨਹੀਂ ਪਾਉਣਗੇ। ਭਾਸ਼ਾ ਸਧਾਰਣ ਅਤੇ ਨਿਰਧਾਰਤ ਰੱਖੋ। ਜੇ ਇੱਕ ਟੈਸਟਰ ਨਹੀਂ ਸਮਝਦਾ ਕਿ ਕੀ ਮਨਜ਼ੂਰ ਹੈ, ਤਾਂ ਉਹ ਜਾਂ ਤਾਂ ਰੁਕ ਜਾਵੇਗਾ ਜਾਂ ਖਤਰਨਾਕ ਕਦਮ ਚੁੱਕੇਗਾ।
ਸੁਰੱਖਿਅਤ ਟੈਸਟਿੰਗ ਸੀਮਾਵਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਲਕਸ਼ ਰਿਸਰਚ ਰੋਕਣਾ ਨਹੀਂ; ਮਕਸਦ ਨੁਕਸਾਨ ਰੋਕਣਾ ਹੈ ਜਦੋਂ ਮੁੱਦਾ ਅਣਜਾਣ ਹੋ। ਆਮ ਨਿਯਮ ਸ਼ਾਮਲ ਹਨ: ਕੋਈ ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਨਹੀਂ, ਕੋਈ ਡੀਨਾਇਲ-ਆਫ-ਸੇਵਾ ਜਾਂ ਸਟ੍ਰੈੱਸ ਟੈਸਟਿੰਗ ਨਹੀਂ, ਕੋਈ ਭੌਤਿਕ ਹਮਲੇ ਨਹੀਂ, ਸਕੋਪ ਤੋਂ ਬਾਹਰ ਸਕੈਨਿੰਗ ਨਹੀਂ, ਅਤੇ ਜੇ ਅਸਲ ਯੂਜ਼ਰ ਡੇਟਾ ਛੁਹ ਜਾਂਦਾ ਹੈ ਤਾਂ ਤੁਰੰਤ ਰੁਕੋ।
ਫਿਰ ਰਿਪੋਰਟ ਕਰਨ ਦਾ ਤਰੀਕਾ ਸਮਝਾਓ ਅਤੇ “ਉਪਯੋਗੀ” ਕੀ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਣ ਟੈਮਪਲੇਟ ਟ੍ਰਾਇਅਜ ਤੇਜ਼ ਕਰਦਾ ਹੈ: ਕਿੱਥੇ ਹੋਇਆ (URL/ਐਪ ਸਕ੍ਰੀਨ, ਵਾਤਾਵਰਣ, ਅਕਾਉਂਟ ਕਿਸਮ), ਦੁਹਰਾਉਣ ਲਈ ਨੰਬਰਵਾਰ ਕਦਮ, ਪ੍ਰਭਾਵ, ਸਬੂਤ ( ਸਕਰੀਨਸ਼ਾਟ, ਛੋਟੀ ਵੀਡੀਓ, request/response ), ਅਤੇ ਸੰਪਰਕ ਵੇਰਵੇ।
ਪ੍ਰਾਈਵੇਸੀ ਬਾਰੇ ਸਪਸ਼ਟ ਰਹੋ। ਖੋਜਕਾਰਾਂ ਨੂੰ ਕਹੋ ਕਿ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਘਟਾਓ, ਡਾਟਾਸੈਟ ਡਾਊਨਲੋਡ ਕਰਨ ਤੋਂ ਬਚੋ, ਅਤੇ ਸਕਰੀਨਸ਼ਾਟਾਂ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ (ਈਮੇਲ, ਟੋਕਨ, ਨਿੱਜੀ ਵੇਰਵੇ) ਨੂੰ ਰੈਡੈਕਟ ਕਰੋ। ਜੇ ਉਹਨਾਂ ਨੂੰ ਪਹੁੰਚ ਸਾਬਤ ਕਰਨ ਲਈ ਕੁਝ ਦਿਖਾਉਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਤਾਂ ਸਭ ਤੋਂ ਛੋਟਾ ਸਮਾਂਪਲ ਮੰਗੋ।
ਅਖੀਰ ਵਿੱਚ, ਡੁਪਲਿਕੇਟ ਅਤੇ ਅਧੂਰੇ ਰਿਪੋਰਟਾਂ ਲਈ ਉਮੀਦਾਂ ਨਿਰਧਾਰਤ ਕਰੋ। ਤੁਸੀਂ ਕਹਿ ਸਕਦੇ ਹੋ ਕਿ ਪਹਿਲੀ ਸਪਸ਼ਟ ਰਿਪੋਰਟ ਨੂੰ ਯੋਗਤਾ ਦੇਣਗੇ ਜਾਂ ਕ੍ਰੈਡਿਟ ਦੇਵੋਗੇ, ਅਤੇ ਅਧੂਰੇ ਰਿਪੋਰਟਾਂ ਨੂੰ ਬੰਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੇ ਤੁਸੀਂ ਦੁਹਰਾਉਣ ਯੋਗ ਨਹੀਂ ਹੋ। ਇੱਕ ਛੋਟੀ ਲਾਈਨ ਜਿਵੇਂ "ਜੇ ਤੁਸੀਂ ਪੱਕੇ ਨਹੀਂ ਹੋ, ਤਾਂ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਹੈ ਭੇਜੋ ਅਤੇ ਅਸੀਂ ਰਾਹ-ਨਿਰਦੇਸ਼ ਕਰਾਂਗੇ" ਦਰਵਾਜ਼ਾ ਖੁੱਲ੍ਹਾ ਰੱਖਦੀ ਹੈ ਬਿਨਾਂ ਨਤੀਜੇ ਦੇ ਵਾਅਦੇ ਕੀਤੇ।
VDP ਸਭ ਤੋਂ ਤੇਜ਼ ਫੇਲ ਹੁੰਦਾ ਹੈ ਜਦ ਰਿਪੋਰਟਾਂ ਇਕ ਸਾਂਝੇ ਇਨਬਾਕਸ ਵਿੱਚ ਪੈਂਦੀਆਂ ਹਨ ਜਿਸਦਾ ਕੋਈ ਮਾਲਕ ਨਹੀਂ। ਟ੍ਰਾਇਅਜ ਇੱਕ ਆਦਤ ਹੈ ਜੋ "ਸਾਨੂੰ ਰਿਪੋਰਟ ਮਿਲੀ" ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਫੈਸਲਾ ਬਣਾਉਂਦੀ: ਕੀ ਇਹ ਹਕੀਕਤ ਹੈ, ਇਹ ਕਿੰਨਾ ਭਾਰੀ ਹੈ, ਕੌਣ ਇਸ ਨੂੰ ਠੀਕ ਕਰੇਗਾ, ਅਤੇ ਅਸੀਂ ਰਿਪੋਰਟਰ ਨੂੰ ਕੀ ਦੱਸਾਂਗੇ।
ਪੂਰੇ ਟੀਮ ਲਈ ਲਾਗੂ ਕੀਤੀ ਜਾ ਸਕਣ ਵਾਲਾ ਇੱਕ ਛੋਟਾ severity rubric ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਪਹਿਲੀ ਪ੍ਰਤੀਕਿਰਿਆ ਇੱਕ ਵਿਅਕਤੀ (ਸੁਰੱਖਿਆ ਲੀਡ, on-call ਇੰਜੀਨੀਅਰ, ਜਾਂ ਫਾਉਂਡਰ) ਨੂੰ ਸੌਂਪੋ, ਨਾਲ ਹੀ ਹਫ਼ਤੇ ਦੇ ਅੰਤ ਅਤੇ ਛੁੱਟੀਆਂ ਲਈ ਬੈਕਅਪ ਰੱਖੋ। ਇਹ ਇਕੱਲਾ ਫੈਸਲਾ "ਕੋਈ ਹੋਰ ਸੰਭਾਲੇਗਾ" ਦੇ ਡੀਫ਼ਾਲਟ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਝੂਠੇ ਸਕੈਨ ਆਉਟਪੁੱਟ ਅਤੇ "ਸੁਰੱਖਿਆ ਥੀਏਟਰ" ਘਟਾਉਣ ਲਈ ਇੱਕ ਵਸਤੁ ਸੰਪੱਦ ਚਾਹੋ: ਇੱਕ ਦੁਹਰਾਉਣਯੋਗ ਸਬੂਤ। ਇਹ ਕਦਮ, ਇੱਕ ਛੋਟੀ ਵੀਡੀਓ, ਜਾਂ ਨਿਊਨਤਮ request/response ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਦੁਹਰਾਇਆ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਇਹ ਕਹੋ, ਜੋ ਤੁਸੀਂ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਉਹ ਵਰਨਣ ਕਰੋ, ਅਤੇ ਇੱਕ ਲਕੜੀ ਲਈ ਸਵਾਲ ਪੁੱਛੋ। ਸਕੈਨਰ ਆਉਟਪੁੱਟ ਨੂੰ ਨੀਰਣੈਯਕ ਨਹੀਂ, ਇੱਕ ਇਸ਼ਾਰਾ ਸਮਝੋ।
ਜੇ ਰਿਪੋਰਟ ਤੀਜੀ-ਪੱਖੀ ਸੇਵਾਵਾਂ ਨੂੰ ਛੇੜਦੀ ਹੈ (ਕਲਾਉਡ ਸਟੋਰੇਜ, ਆਈਡੈਂਟੀਟੀ ਪ੍ਰੋਵਾਈਡਰ, ਐਨਾਲਿਟਿਕਸ), ਤਾਂ ਜੋ ਤੁਸੀਂ ਕੰਟਰੋਲ ਕਰਦੇ ਹੋ ਅਤੇ ਜੋ ਨਹੀਂ, ਉਸਨੂੰ ਵੱਖ ਕਰੋ। ਪਹਿਲਾਂ ਆਪਣੀ ਕੰਫਿਗਰੇਸ਼ਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਵੇਂਡਰ ਨੂੰ ਸੰਪਰਕ ਕਰੋ। ਰਿਪੋਰਟਰ ਨੂੰ ਇਹ ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕੀ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹੋ।
ਹਰ ਰਿਪੋਰਟ ਨੂੰ ਇੱਕ ਸਧਾਰਣ ਅੰਦਰੂਨੀ ਟੇਮਪਲੇਟ ਵਿੱਚ ਦਰਜ ਕਰੋ: ਸੰਖੇਪ, ਪ੍ਰਭਾਵਿਤ ਸਤਹ, ਗੰਭੀਰਤਾ ਅਤੇ ਕੈੋਂ, ਦੁਹਰਾਉਣ ਨੋਟਸ, ਮਾਲਕ, ਅਤੇ ਮੌਜੂਦਾ ਸਥਿਤੀ। ਲਗਾਤਾਰ ਨੋਟਸ ਅਗਲੀ ਰਿਪੋਰਟ ਨੂੰ ਪਹਿਲੀ ਨਾਲੋਂ ਤੇਜ਼ ਬਣਾ ਦਿੰਦੀਆਂ ਹਨ।
ਸਮਾਂ-ਰੇਖਾ ਇੱਕ ਐਸੇ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਫਰਕ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜੋ ਭਰੋਸਾ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਜੋ ਅਣਦੇਖੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਆਪਣੇ ਮੌਜੂਦਾ ਟੀਮ ਨਾਲ ਜੋ ਤੁਸੀਂ ਹਕੀਕਤ ਵਿੱਚ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹੋ ਉਹ ਟਾਰਗੇਟ ਚੁਣੋ, ਉਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ, ਅਤੇ ਉਹਨਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ।
ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਬਹੁਤੀਆਂ ਵਾਅਦੀਆਂ ਜੋ ਅਕਸਰ ਸੰਭਵ ਹੁੰਦੀਆਂ ਹਨ:
ਜੇ ਤੁਸੀਂ ਇਹ ਨੰਬਰ ਨਹੀਂ ਮਿਲਾ ਸਕਦੇ, ਤਾਂ ਹੁਣ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਧ ਕਰੋ ਬਜਾਏ ਕਿ ਬਾਅਦ ਵਿੱਚ ਨਾਂ-ਪਾਲਨਾ ਕਰੋਂ। ਵਧੀਆ ਹੈ ਕਿ "30 ਦਿਨ" ਬੋਲੋ ਅਤੇ 20 ਵਿੱਚ ਡਿਲਿਵਰ ਕਰੋ ਬਜਾਏ "7 ਦਿਨ" ਦਾ ਵਾਅਦਾ ਕਰਨ ਦੇ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਖਾਮੋਸ਼ ਹੋ ਜਾਣ ਦੀ।
ਰਿਪੋਰਟ ਖੋਜਕਾਰਾਂ ਲਈ ਤਤਕਾਲ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ। ਭਾਵੇਂ ਤੁਹਾਡੇ ਕੋਲ ਹੁਣੇ ਫਿਕਸ ਨਾ ਹੋਵੇ, ਨਿਯਮਤ ਅਪਡੇਟ ਨਿਰਾਸ਼ਾ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਜਨਤਕ ਸਥਿਤੀ ਲਈ ਪ੍ਰੇਰਿਤ ਹੋਣ ਤੋਂ ਰੋਕਦੇ ਹਨ। ਇੱਕ ਪੇਸ਼ਗੋਈ ਕੈਡੈਂਸ ਵਰਤੋ ਅਤੇ ਸ਼ਾਮਿਲ ਕਰੋ: ਮੌਜੂਦਾ ਸਥਿਤੀ (ਟ੍ਰਾਇਅਜ, ਫਿਕਸ, ਜਾਂ ਟੈਸਟਿੰਗ), ਅੱਗਲਾ ਕਦਮ, ਅਤੇ ਅਗਲੀ ਅਪਡੇਟ ਦੀ ਤਾਰੀਖ।
ਮੁੱਦੇ ਦੀ ਪੁਸ਼ਟੀ ਹੋਣ 'ਤੇ ਇੱਕ ਡਿਕਲੋਜ਼ਰ ਤਾਰੀਖ 'ਤੇ ਸਹਿਮਤੀ ਕਰੋ। ਜੇ ਤੁਹਾਨੂੰ ਵੱਧ ਸਮਾਂ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਜਲਦੀ ਮੰਗੋ ਅਤੇ ਕਾਰਨ ਸਮਝਾਓ (ਜਟਿਲ ਫਿਕਸ, ਰੋਲਆਉਟ ਪਾਬੰਦੀਆਂ)। ਜੇ ਮੁੱਦਾ ਸਰਗਰਮ ਤੌਰ 'ਤੇ ਸ਼ੋਇਲ ਹੈ, ਤਾਂ ਯੂਜ਼ਰਾਂ ਦੀ ਰੱਖਿਆ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਅਤੇ ਜਲਦੀ ਸੰਚਾਰ ਕਰਨ ਲਈ ਤਿਆਰ ਰਵੋ, ਭਾਵੇਂ ਪੂਰਨ ਫਿਕਸ ਅਜੇ ਰੋਲਿੰਗ ਹੋ ਰਿਹਾ ਹੋਵੇ।
ਜਦੋਂ ਰਿਪੋਰਟ ਦੀ ਪੁਸ਼ਟੀ ਅਤੇ ਰੈਂਕਿੰਗ ਹੋ ਜਾਵੇ, ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਯੂਜ਼ਰਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਰੱਖਿਆ ਦਿਓ। ਇੱਕ ਸੁਰੱਖਿਅਤ ਪੈਚ ਜਾਂ ਮਿਟੀਗੇਸ਼ਨ ਸ਼ਿਪ ਕਰੋ ਭਾਵੇਂ ਤੁਸੀਂ ਪੂਰੀ ਰੇਸ਼ਮੀ ਜੜ ਨਾਲ-ਲਿਖਤੀ ਰਿਪੋਰਟ ਨਾ ਕਰ ਪਾਓ। ਅੱਜ ਦੀ ਛੋਟੀ ਫਿਕਸ ਅਕਸਰ ਅਗਲੇ ਮਹੀਨੇ ਦੇ ਵੱਡੇ ਰੀਫੈਕਟਰ ਤੋਂ ਵਧੀਆ ਹੁੰਦੀ ਹੈ।
ਛੋਟੀਆਂ-ਸ਼ੌਰਟ ਟਰਮ ਮਿਟੀਗੇਸ਼ਨ ਉਸ ਸਮੇਂ ਸਮਾਂ ਖਰੀਦਦੇ ਹਨ ਜਦੋਂ ਇੱਕ ਪੂਰਾ ਫਿਕਸ ਖਤਰਨਾਕ ਜਾਂ धीਮਾ ਹੋਵੇ। ਆਮ ਵਿਕਲਪ ਵਿੱਚ ਇੱਕ ਫੀਚਰ ਨੂੰ ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਬੰਦ ਕਰਨਾ, ਰੇਟ ਲਿਮਿਟਸ ਕਸਣਾ, ਗਲਤ ਰਿਕਵੈਸਟ ਪੈਟਰਨ ਨੂੰ ব্লੌਕ ਕਰਨਾ, ਪ੍ਰਕਾਸ਼ਤ ਗੁਪਤਚਾਬੀਆਂ ਨੂੰ ਘੁਮਾ ਦੈਣਾ, ਜਾਂ ਲੌਗਿੰਗ ਅਤੇ ਅਲਰਟਜ਼ ਜੋੜਨਾ ਸ਼ਾਮਲ ਹਨ। ਮਿਟੀਗੇਸ਼ਨ ਨੂੰ ਅੰਤਿਆ ਟੀਕ ਨਹੀਂ ਮੰਨਣਾ ਚਾਹੀਦਾ, ਪਰ ਇਹ ਨੁਕਸਾਨ ਘਟਾਉਂਦੀਆਂ ਹਨ ਜਦ ਤੱਕ ਤੁਸੀਂ ਅਸਲੀ ਮੁਰੰਮਤ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋ।
ਰਿਪੋਰਟ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਫਿਕਸ ਨੂੰ ਇੱਕ ਛੋਟੀ ਰਿਲੀਜ਼ ਵਾਂਗ ਵੈਰਿਫਾਈ ਕਰੋ: ਮੁੱਦੇ ਨੂੰ ਦੁਹਰਾਓ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਫਿਕਸ ਤੋਂ ਬਾਅਦ ਮੁੱਦਾ ਹੁਣ ਕੰਮ ਨਹੀਂ ਕਰਦਾ, ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਜੋੜੋ, ਆਸ-ਪਾਸ ਦੀਆਂ ਪਰਮੀਸ਼ਨਾਂ 'ਤੇ ਸਾਈਡ-ਇਫੈਕਟ ਚੈੱਕ ਕਰੋ, ਅਤੇ ਜੇ ਹੋ ਸਕੇ ਤਾਂ ਦੂਸਰੀ ਨਜ਼ਰ ਲਵਾਓ।
ਸੰਚਾਰ ਪੈਚ ਦੇ ਬਰਾਬਰ ਮੈਤਲ ਬਰਾਬਰ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਰਿਪੋਰਟਰ ਨੂੰ ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕੀ ਪੁਸ਼ਟੀ ਕੀਤੀ, ਕੀ ਬਦਲਿਆ, ਅਤੇ ਇਹ ਕਦੋਂ ਡੀਪਲੌਇ ਹੋਵੇਗਾ (ਸਧਾਰਣ ਭਾਸ਼ਾ ਵਿੱਚ)। ਜੇ ਤੁਹਾਨੂੰ ਹੋਰ ਸਮਾਂ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਕਾਰਨ ਦੱਸੋ ਅਤੇ ਅਗਲੀ ਅਪਡੇਟ ਦੀ ਤਾਰੀਖ ਦਿਓ। ਯੂਜ਼ਰਾਂ ਲਈ, ਸੰਦੇਸ਼ ਛੋਟਾ ਅਤੇ ਇਮਾਨਦਾਰ ਰੱਖੋ: ਕੀ ਪ੍ਰਭਾਵਿਤ ਹੋਇਆ, ਤੁਸੀਂ ਕੀ ਕੀਤਾ, ਅਤੇ ਕੀ ਉਨ੍ਹਾਂ ਨੂੰ ਕੋਈ ਕਾਰਵਾਈ ਕਰਨ ਦੀ ਲੋੜ ਹੈ (ਪਾਸਵਰ্ড ਰੀਸੈੱਟ, ਕੀ ਰੋਟੇਸ਼ਨ, ਐਪ ਅੱਪਡੇਟ)।
ਜਦੋਂ ਮੁੱਦਾ ਕਈ ਯੂਜ਼ਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ, ਮੁੜਖੋਜ ਲਈ ਸੰਭਾਵਨਾ ਜ਼ਿਆਦਾ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਯੂਜ਼ਰ ਐਕਸ਼ਨ ਜਰੂਰੀ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਛੋਟੀ ਸਲਾਹ-ਮਸ਼ਵਰਾ ਜਾਰੀ ਕਰੋ। ਇੱਕ ਸੰਖੇਪ ਸਮਰੀ, ਗੰਭੀਰਤਾ, ਪ੍ਰਭਾਵਿਤ ਕੰਪੋਨੈਂਟ, ਫਿਕਸ ਦੀ ਤਾਰੀਖ, ਅਤੇ ਰਿਪੋਰਟਰ ਨੂੰ ਕ੍ਰੈਡਿਟ (ਜੇ ਉਹ ਚਾਹੁੰਦੇ ਹਨ) ਸ਼ਾਮਲ ਕਰੋ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ, ਜਿੱਥੇ ਐਪ ਡਿਪਲੌਯਡ ਅਤੇ ਹੋਸਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਐਡਵਾਈਜ਼ਰੀ ਉਹਨਾਂ ਟੀਮਾਂ ਨੂੰ ਵੀ ਮਦਦ ਕਰਦੇ ਹਨ ਜੋ exports ਜਾਂ custom ਡੋਮੇਨ ਵਰਤ ਰਹੀਆਂ ਹਨ ਤਾਂ ਕਿ ਉਹ ਜਾਣ ਸਕਣ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਦੁਬਾਰਾ ਡਿਪਲੌਯ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਨਹੀਂ।
ਜ਼ਿਆਦਾਤਰ ਛੋਟੀ ਟੀਮਾਂ ਦੀ ਨਾਕਾਮੀ ਦੀ وجہ ਚੰਗਾ ਇਰਾਦਾ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਇਸ ਲਈ ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਪ੍ਰੋਗਰਾਮ ਉਹਨਾਂ ਦੀ ਸਮਰੱਥਾ ਤੋਂ ਵੱਡਾ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਇੰਨਾ ਅਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ ਕਿ ਹਰ ਰਿਪੋਰਟ ਇਕ ਡਿਬੇਟ ਬਣ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਆਪਣਾ VDP ਉਸ ਹਫ਼ਤੇ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ ਜੋ ਤੁਸੀਂ ਬਿਤਾ ਰਹੇ ਹੋ, ਨਾ ਕਿ ਉਸ ਹਫ਼ਤੇ ਲਈ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ।
ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਸਭ ਤੋਂ ਸਰਲ ਠੀਕ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ:
ਉਦਾਹਰਨ: ਇੱਕ ਖੋਜਕਾਰ ਨੇ ਇਕ ਇਕਸਪੋਜ਼ਡ ਸਟੇਜਿੰਗ ਐਂਡਪੌਇੰਟ ਰਿਪੋਰਟ ਕੀਤਾ। ਜੇ ਤੁਹਾਡੇ ਨਿਯਮ ਸਟੇਜਿੰਗ ਦਾ ਜ਼ਿਕਰ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਤੁਹਾਡੀ ਟੀਮ ਦਿਨਾਂ ਤੱਕ ਇਸ 'ਤੇ بحث ਕਰ ਸਕਦੀ ਹੈ। ਜੇ ਸਟੇਜਿੰਗ ਸ਼ਾਮਲ ਹੈ ਜਾਂ ਖੁੱਲ੍ਹਾ-ਖੁੱਲ੍ਹਾ ਬਾਹਰ ਰੱਖਿਆ ਗਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ ਸਕਦੇ ਹੋ, ਸਹੀ ਰਸਤੇ 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਗੱਲਬਾਤ ਸ਼ਾਂਤ ਰੱਖ ਸਕਦੇ ਹੋ।
ਇੱਕ ਘੱਟੋ-ਘੱਟ ਯੋਗ vulnerability disclosure program ਇਸ ਗੱਲ ਬਾਰੇ ਘੱਟ ਨਹੀਂ ਕਿ ਕਾਗਜ਼ੀ ਕਾਰਵਾਈ ਪੂਰਨ ਹੋਵੇ, ਸਗੋਂ ਯਕੀਨੀ ਵਤੀਵਾਹਾਰ ਬਾਰੇ ਹੈ। ਲੋਕਾਂ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਕੀ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹਨ, ਕਿਵੇਂ ਰਿਪੋਰਟ ਕਰਨਾ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਕਦੋਂ ਪ੍ਰਤੀਕਿਰਿਆ ਮਿਲੇਗੀ।
ਚੈੱਕਲਿਸਟ ਛੋਟੀ ਰੱਖੋ:
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਵਜੋਂ, Koder.ai ਵਰਗਾ ਪਲੇਟਫਾਰਮ ਜੋ ਵੈਬ, ਬੈਕਐਂਡ, ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਡਿਪਲੌਯ ਕਰਦਾ ਹੈ), ਤਾਂ ਇਹ ਰਿਪੋਰਟਾਂ ਨੂੰ ਟੀਮਾਂ ਅਤੇ ਰਿਲੀਜ਼ ਸਾਇਕਲਾਂ ਦੇ ਦਰਮਿਆਂ ਖੋ ਜਾਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਇੱਕ ਤਿੰਨ-ਇਨਸਾਨ SaaS ਟੀਮ ਨੂੰ ਇੱਕ ਈਮੇਲ ਮਿਲਦੀ ਹੈ ਸਿਰਲੇਖ ਨਾਲ: “Possible account takeover via password reset.” ਖੋਜਕਾਰ ਕਹਿੰਦਾ ਹੈ ਕਿ ਉਹ ਕਿਸੇ ਪੀੜਤ ਦੇ ਈਮੇਲ ਪਤਾ ਨੂੰ ਜਾਣ ਕੇ ਪਾਸਵਰਡ ਰੀਸੈਟ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਰੀਸੈਟ ਲਿੰਕ ਪੁਰਾਣਾ ਹੋਣ 'ਤੇ ਵੀ ਵੈਧ ਰਹਿੰਦਾ ਹੈ।
ਟੀਮ ਜਲਦੀ ਰਿਪੋਰਟਰ ਨੂੰ ਪ੍ਰਾਪਤੀ ਦੀ ਪੁਸ਼ਟੀ ਦਿੰਦੀ ਹੈ ਅਤੇ ਦੋ ਗੱਲਾਂ ਮੰਗਦੀ ਹੈ: ਦੁਹਰਾਉਣ ਲਈ ਸਹੀ ਕਦਮ, ਅਤੇ ਕਿ ਕੀ ਖੋਜਕਾਰ ਨੇ ਸਿਰਫ ਆਪਣੇ ਅਕਾਉਂਟਾਂ 'ਤੇ ਟੈਸਟ ਕੀਤਾ। ਉਹ ਹੋਰ ਯਾਦ ਦਿਲਾਉਂਦੇ ਹਨ ਕਿ ਗ੍ਰਾਹਕਾਂ ਦਾ ਅਸਲ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਨਾ ਕੀਤੀ ਜਾਵੇ।
ਉਤਪਾਦਕ ਯੂਜ਼ਰਾਂ ਨੂੰ ਛੁਹੇ ਬਿਨਾਂ ਪ੍ਰਭਾਵ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ, ਟੀਮ ਇਕ ਸਟੇਜਿੰਗ ਵਾਤਾਵਰਣ ਵਿੱਚ ਡਮੀ ਅਕਾਉਂਟ ਬਣਾਕੇ ਫਲੋ ਨੂੰ ਦੁਹਰਾਉਂਦੀ ਹੈ। ਉਹ ਇਕ ਖਾਤੇ ਲਈ ਦੋ ਰੀਸੈਟ ਈਮੇਲ ਤਿਆਰ ਕਰਦੇ ਹਨ, ਫਿਰ ਵੇਖਦੇ ਹਨ ਕਿ ਕੀ ਪੁਰਾਣਾ ਟੋਕਨ ਹਾਲੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਬਿਨਾਂ ਕਿਸੇ ਵਾਧੂ ਜਾਂਚ ਦੇ ਨਵਾਂ ਪਾਸਵਰਡ ਸੈੱਟ ਕਰ सकते ਹਨ। ਉਹ ਸਰਵਰ ਲੌਗ ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਕੈਪਚਰ ਕਰਦੇ ਹਨ ਪਰ ਕਿਸੇ ਵੀ ਇਮੇਲ ਸਮੱਗਰੀ ਦੀ ਨਕਲ ਨਹੀ ਕਰਦੇ ਜੋ ਗਲਤ ਹੋ ਸਕਦੀ ਸੀ।
ਉਹ ਇਸਨੂੰ High severity ਲੇਬਲ ਕਰਦੇ ਹਨ: ਇਹ ਇੱਕ ਹਕੀਕਤੀ ਰਾਹ ਨਾਲ ਖਾਤਾ ਟੇਕਓਵਰ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ। ਆਪਣੀ ਨੀਤੀ ਤਹਿਤ, ਉਹ 72 ਘੰਟਿਆਂ ਵਿੱਚ ਮਿਟੀਗੇਸ਼ਨ ਅਤੇ 7 ਦਿਨਾਂ ਵਿੱਚ ਪੂਰਾ ਫਿਕਸ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ।
ਉਹ ਰਿਪੋਰਟਰ ਨੂੰ ਹਰ ਪੜਾਅ 'ਤੇ ਅਪਡੇਟ ਰੱਖਦੇ ਹਨ:
ਬੰਦ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਉਹ ਦੁਹਰਾਵਟਾਂ ਨੂੰ ਰੋਕਣ ਲਈ ਇੱਕ ਆਟੋਮੇਟੈਡ ਟੈਸਟ ਜੋੜਦੇ ਹਨ ਜੋ single-use reset tokens ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਅਣੁਸਾਰ reset ਵਾਲੀ ਰਕਤ ਲਈ ਮਾਨਨਕ ਤਾਕਤ ਦੇਖਦੇ ਹਨ, ਅਤੇ ਆਪਣੀ ਅੰਦਰੂਨੀ ਚੈੱਕਲਿਸਟ ਅੱਪਡੇਟ ਕਰਦੇ ਹਨ: “ਕੋਈ ਵੀ ਲੌਗਿਨ ਜਾਂ ਰੀਸੈਟ ਟੋਕਨ single-use, ਛੋਟੀ ਮਿਆਦ ਵਾਲਾ, ਅਤੇ ਨਵੀਂ ਜਾਰੀਗੀ 'ਤੇ ਅਵੈਲਿਡੇਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।”
ਹਫਤੇ-ਬ-ਹਫਤੇ ਚਲਾਇਆ ਜਾਣ ਵਾਲਾ VDP ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਸਧਾਰਣ ਇਨਬਾਕਸ, ਸਪਸ਼ਟ ਸਕੋਪ, ਅਤੇ ਲਗਾਤਾਰ ਟ੍ਰਾਇਅਜ ਰੁਟੀਨ ਕਿਸੇ ਵਿਲਾਸੀ ਨੀਤੀ ਤੋਂ ਬੇਹਤਰ ਹੈ ਜੋ ਬਿਨਾਂ ਵਰਤੇ ਪੜੀ ਰਹਿ ਜਾਂਦੀ ਹੈ। ਜਦੋਂ ਵਰਕਫਲੋ ਸਥਿਰ ਹੋ ਜਾਵੇ ਅਤੇ ਤੁਹਾਡੀ ਪ੍ਰਤੀਕਿਰਿਆ ਕੈਡੈਂਸ ਭਰੋਸੇਯੋਗ ਹੋਵੇ, ਤਾਂ ਉਹ ਖੇਤਰ ਜਿੱਥੇ ਤੁਸੀਂ ਗਹਿਰੀ ਜਾਂਚ ਚਾਹੁੰਦੇ ਹੋ ਉੱਥੇ ਬੱਗ ਬਾਊਂਟੀ ਸ਼ੁਰੂ ਕਰੋ।
ਕੁਝ ਗਿਣਤੀ ਟ੍ਰੈਕ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਤਰੱਕੀ ਵੇਖ ਸਕੋ ਬਿਨਾਂ ਇਸਨੂੰ ਫੁੱਲ-ਟਾਈਮ ਕੰਮ ਬਣਾਇਆ:
ਹਰ ਮਹੱਤਵਪੂਰਨ ਰਿਪੋਰਟ ਤੋਂ ਬਾਅਦ ਇੱਕ ਹਲਕੀ ਰੀਟ੍ਰੋ ਕਰੋ: ਕੀ ਚੀਜ਼ ਨੇ ਤੁਹਾਨੂੰ ਧੀਰਾ ਕੀਤਾ, ਖੋਜਕਾਰ ਨੂੰ ਕੀ ਔਖਾ ਲੱਗਿਆ, ਕਿਹੜਾ ਫੈਸਲਾ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲਿਆ, ਅਤੇ ਅਗਲੀ ਵਾਰੀ ਤੁਸੀਂ ਕੀ ਬਦਲੋਗੇ।
ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਦੀ ਹੈ, ਤਾਂ “ਸੁਰੱਖਿਅਤ ਰਿਲੀਜ਼” ਨੂੰ ਯੋਜਨਾ ਦਾ ਹਿੱਸਾ ਬਣਾਓ। ਛੋਟੇ, ਵਾਪਸ ਲਿਆਂਦੇ ਜਾ ਸਕਣ ਵਾਲੇ ਬਦਲਾਅ ਲਈ ਨਿਸ਼ਾਨ ਬਣਾਓ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ snapshots ਅਤੇ rollback ਉਪਲਬਧ ਹਨ ਤਾਂ ਉਹ ਵਰਤੋ ਤਾਂ ਕਿ ਇੱਕ ਸੁਰੱਖਿਆ ਫਿਕਸ ਇੱਕ ਲੰਬੇ ਆਉਟਜ ਵਿਚ ਨਾ ਬਦਲ ਜਾਵੇ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਮਾਸਿਕ ਰਿਦਮ:
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) 'ਤੇ ਬਣਾਓ, ਤਾਂ ਡਿਪਲੌਇਮੈਂਟ ਅਤੇ ਹੋਸਟਿੰਗ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਹਨ, ਅਤੇ ਜਦੋਂ ਤੁਹਾਨੂੰ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸੋর্স ਕੋਡ export ਉਪਲਬਧ ਹੁੰਦਾ ਹੈ। ਇਹ ਸੁਰੱਖਿਆ ਫਿਕਸ ਤੇਜ਼ੀ ਨਾਲ ਪুশ ਕਰਨ ਅਤੇ ਜੇ ਕਿਸੇ ਬਦਲاؤ ਤੋਂ ਸਾਈਡ-ਇਫੈਕਟ ਆ ਜਾਵੇ ਤਾਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ recuperação ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ।
ਏਕ VDP ਲੋਕਾਂ ਨੂੰ ਤੁਹਾਡੇ ਕੋਲ ਸੁਰੱਖਿਆ ਸਮੱਸਿਆਵਾਂ ਰਿਪੋਰਟ ਕਰਨ ਦਾ ਸਾਫ਼, ਕਾਨੂੰਨੀ ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਰਸਤਾ ਦਿੰਦਾ ਹੈ। ਇਹ ਘੱਟ ਕਰਦਾ ਹੈ ਕਿ ਰਿਪੋਰਟਾਂ ਲੋਕ ਪ੍ਰਸਿੱਧੀਆਂ, ਬੇਚੈਨ ਡਾਇਰੈਕਟ ਮੈਸੇਜਾਂ ਜਾਂ ਲਗਾਤਾਰ ਜਾਂਚ ਕਰਨ ਵਾਲੀਆਂ ਪੋਸਟਾਂ ਵੱਜੋਂ ਆਉਣ।
ਮੁੱਖ ਲਾਭ ਤੇਜ਼ੀ ਅਤੇ ਕਾਬੂ ਹੈ: ਤੁਸੀਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਜਲਦੀ ਪਤਾ ਲਗਾਉਂਦੇ ਹੋ, ਠੰਢੇ ਦਿਲ ਨਾਲ ਠੀਕ ਕਰਦੇ ਹੋ, ਅਤੇ ਲਗਾਤਾਰ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ ਕੇ ਭਰੋਸਾ ਬਣਾਉਂਦੇ ਹੋ।
ਉਂਝ ਸ਼ੁਰੂ ਕਰੋ ਜਦੋਂ ਤੁਸੀਂ ਤਿੰਨ ਚੀਜ਼ਾਂ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ:
ਜੇ ਤੁਸੀਂ ਹੁਣੇ ਇਹ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਸਕੋਪ ਨੂੰ ਤੰਗ ਕਰੋ ਅਤੇ ਲੰਬੀਆਂ ਤਰੀਖਾਂ ਨਿਰਧਾਰਤ ਕਰੋ, ਬਜਾਏ ਕਿ VDP ਛੱਡ ਦਿੱਤਾ ਜਾਵੇ।
ਸਧਾਰਣ VDP ਨੀਤੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਮੂਲ ਨੀਤੀ: ਉਹਨਾਂ ਸੰਪਤੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮਲਿਕੀਅਤ ਵਿੱਚ ਰੱਖਦੇ ਹੋ ਅਤੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਤੁਰੰਤ ਸਹੀ ਕਰ ਸਕਦੇ ਹੋ—ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੀ ਪ੍ਰੋਡਕਸ਼ਨ ਵੈਬ ਐਪ ਅਤੇ ਪਬਲਿਕ API।
ਉਹ ਚੀਜ਼ਾਂ ਬਾਹਰ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਸ਼ੁਰੂ 'ਤੇ ਜਾਂਚ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜਾਂ ਫਿਕਸ ਨਹੀਂ ਕਰ ਸਕਦੇ (ਪੁਰਾਣੇ ਪ੍ਰੋਟੋਟਾਈਪ, ਅੰਦਰੂਨੀ ਟੂਲ, ਤੀਜੀ ਪੱਖੀ ਸੇਵਾਵਾਂ)। ਵਰਕਫਲੋ ਸਥਿਰ ਹੋਣ 'ਤੇ ਤੁਸੀਂ ਸਕੋਪ ਵਧਾ ਸਕਦੇ ਹੋ।
ਆਮ ਬੇਸਲਾਈਨ ਨਿਯਮ:
ਸਪਸ਼ਟ ਸੂਰਤਾਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦੀਆਂ ਹਨ ਅਤੇ ਖੋਜਕਾਰਾਂ ਨੂੰ ਭਰੋਸਾ ਦਿੰਦੀਆਂ ਹਨ।
ਇੱਕ ਐਕਸ਼ਨਯੋਗ ਰਿਪੋਰਟ ਲਈ ਨੁਕਤੇ ਜੋ ਦੁਹਰਾਏ ਜਾ ਸਕਦੇ ਹਨ:
ਸੁਝਾਅਤ ਸਮਾਧਾਨ ਮਦਦਗਾਰ ਹਨ ਪਰ ਜ਼ਰੂਰੀ ਨਹੀਂ; ਪ੍ਰਭਾਵ ਨੂੰ ਦੁਹਰਾਉਣਾ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਹੈ।
ਇੱਕ ਮਾਲਿਕ (ਨਾਲ ਇੱਕ ਬੈਕਅਪ) ਚੁਣੋ ਅਤੇ ਸਧਾਰਣ ਫ਼ਲੋ ਫੋਲੋ ਕਰੋ:
VDP ਦਾ ਨੁਕਸਾਨ ਤਾਂ ਹੁੰਦਾ ਹੈ ਜਦ ਰਿਪੋਰਟਾਂ ਇੱਕ ਸਾਂਝੇ ਇਨਬਾਕਸ ਵਿੱਚ ਬੇਮਾਲਕੀ ਛੱਡ ਦਿੱਤੀ ਜਾਂਦੀਆਂ ਹਨ।
ਇੰਪੈਕਟ ਆਧਾਰਿਤ ਛੋਟਾ ਰੁਬ੍ਰਿਕ:
ਸ਼ੱਕ ਵਿਚ ਹੋਵੋ ਤਾਂ ਟ੍ਰਾਇਅਜ ਵੇਲੇ ਉੱਚ ਦਰਜੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਅਸਲੀ ਦੁਹਰਾਉਣ ਤੇ ਸੋਧੋ।
ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਪ੍ਰਯੋਗਿਕ ਡਿਫਾਲਟ:
ਜੇ ਤੁਸੀਂ ਇਹ ਮਿਲਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਹੁਣ ਹੀ ਇਹ ਸਮਾਂ ਵੱਡਾ ਕਰੋ ਅਤੇ ਫਿਰ ਆਪਣੇ ਟੀਚੇ ਨਾਲ ਉਤਾਰੋ।
ਜਦੋਂ ਤੁਸੀਂ ਵਧੇਰੇ ਵੋਲਯੂਮ ਸੰਭਾਲ ਸਕਦੇ ਹੋ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਇਹ ਹੋਵੇ:
VDP ਬੇਸਲਾਈਨ ਹੈ; ਬਾਊਂਟੀਜ਼ ਧਿਆਨ ਅਤੇ ਦਬਾਅ ਵਧਾਉਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਤਦ ਹੀ ਸ਼ੁਰੂ ਕਰੋ ਜਦੋਂ ਤੁਸੀਂ ਟੱਕਰਾ ਜਾਣ।
ਇਹ ਛੋਟਾ ਰੱਖੋ ਅਤੇ ਸਿਰਫ ਉਹੀ ਵਾਅਦੇ ਕਰੋ ਜੋ ਤੁਸੀਂ ਨਿਰੰਤਰ ਪੂਰੇ ਕਰ ਸਕਦੇ ਹੋ।