ਵਲਨਰੇਬਿਲਿਟੀ ਡਿਕਲੋਜ਼ਰ ਪ੍ਰੋਗਰਾਮ: ਛੋਟੀਆਂ ਟੀਮਾਂ ਲਈ ਸ਼ੁਰੂਆਤੀ ਗਾਈਡ

ਕਿਉਂ ਡਿਕਲੋਜ਼ਰ ਪ੍ਰੋਗਰਾਮ ਹੋਂਦੇ ਹਨ (ਅਤੇ ਇਹ ਫਾਇਦੇਮੰਦ ਕਿਉਂ ਹੋ ਸਕਦੇ ਹਨ)

ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਸੁਰੱਖਿਆ ਫੀਡਬੈਕ ਹੁੰਦੀ ਹੈ। ਪਰ ਉਹਨਾਂ ਕੋਲ ਇਸਦੇ ਲੀਏ ਇੱਕ ਸੁਰੱਖਿਅਤ ਥਾਂ ਨਹੀਂ ਹੁੰਦੀ।

ਇੱਕ vulnerability disclosure program (VDP) ਖੋਜਕਾਰਾਂ ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਮੁੱਦੇ ਰਿਪੋਰਟ ਕਰਨ ਦਾ ਇੱਕ ਸਾਫ਼, ਕਾਨੂੰਨੀ ਅਤੇ ਇਜ਼ਜ਼ਤਦਾਰ ਤਰੀਕਾ ਦਿੰਦਾ ਹੈ, ਪਹਿਲਾਂ ਦੀਆਂ ਖਬਰਾਂ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ। ਬਿਨਾਂ ਨੀਤੀ ਦੇ, ਰਿਪੋਰਟਾਂ ਸਭ ਤੋਂ ਗਲਤ ਵੇਲੇ, ਗਲਤ ਚੈਨਲ ਰਾਹੀਂ, ਅਤੇ ਅਸਪਸ਼ਟ ਉਮੀਦਾਂ ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ। ਇੱਕ ਚੰਗਾ-ਨیتی ਖੋਜਕਾਰ ਨੂੰ ਨਿੱਜੀ ਈਮੇਲ ਦੇ ਸਕਦਾ ਹੈ, ਧਿਆਨ ਖਿੱਚਣ ਲਈ ਪਬਲਿਕ ਪੋਸਟ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਜਵਾਬ ਮਿਲਣ ਤੱਕ ਨਿਰਤੰਤਰ ਪਰਖ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ। ਪਰ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਨਾਲ, ਹਰ ਕੋਈ ਜਾਣਦਾ ਹੈ ਕਿ ਰਿਪੋਰਟ ਕਿੱਥੇ ਭੇਜਣੀਆਂ ਹਨ, ਕਿਹੜੀ ਟੈਸਟਿੰਗ ਮਨਜ਼ੂਰ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਅਗਲਾ قدم ਕੀ ਲਵੇਗੀ।

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

VDP ਅਤੇ ਬੱਗ ਬਾਊਂਟੀਆਂ ਨੂੰ ਲੈ ਕੇ ਪ੍ਰਯੋਗਿਕ ਸੋਚ:

• ਜੇ ਤੁਸੀਂ ਸਪਸ਼ਟ ਸੰਚਾਰ ਅਤੇ ਸਮੇਂ-ਉੱਤੇ ਫਿਕਸ ਦਾ ਵਾਅਦਾ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ vulnerability disclosure program ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।
• ਜੇ ਤੁਸੀਂ ਭੁਗਤਾਨ, ਲਗਾਤਾਰ ਟ੍ਰਾਇਅਜ ਅਤੇ ਬਜਟ ਦੀ ਗਾਰੰਟੀ ਵੀ ਦੇ ਸਕਦੇ ਹੋ ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਬੱਗ ਬਾਊਂਟੀ ਸ਼ਾਮਲ ਕਰੋ।

Katie Moussouris ਨੇ ਇੱਕ ਸਧਾਰਣ ਕਾਰੋਬਾਰੀ ਫਰੇਮਿੰਗ ਨੂੰ ਲੋਕਪ੍ਰਿਯ ਕੀਤਾ ਜਿਸ ਨਾਲ ਕੰਪਨੀਆਂ ਲਈ ਬੱਗ ਬਾਊਂਟੀਆਂ ਮੰਨਣ ਆਸਾਨ ਹੋ ਗਈਆਂ: ਸੁਰੱਖਿਆ ਖੋਜਕਾਰ “ਦੁਸ਼ਮਣ” ਨਹੀਂ ਹਨ। ਉਹ ਗੁਣਵੱਤਾ ਲਈ ਇੱਕ ਪ੍ਰਬੰਧਿਤ, ਸਕਾਰਾਤਮਕ-ਜ਼ੀਰੋ-ਸੰਖਿਆ ਇਨਪੁੱਟ ਹੋ ਸਕਦੇ ਹਨ। ਇਹੀ ਤਰਕ VDPs 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਮੁੱਦੇ ਬੁਲਾ ਰਹੇ ਨਹੀਂ ਹੋ, ਤੁਸੀਂ ਉਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਲਈ ਇੱਕ ਨਿਯੰਤਰਤ ਇੰਟੇਕ ਬਣਾ ਰਹੇ ਹੋ ਜੋ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਮੌਜੂਦ ਹਨ।

ਛੋਟੀ ਟੀਮ ਲਈ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਦੀ ਹੈ (ਮਿਸਾਲ ਵਜੋਂ, ਇੱਕ ਵੈਬ ਐਪ ਜਿਸਦਾ React ਫਰੰਟ-ਐਂਡ ਅਤੇ API ਹੈ), ਫਾਇਦਾ ਆਮ ਤੌਰ 'ਤੇ ਤੁਰੰਤ ਹੁੰਦਾ ਹੈ: ਘੱਟ ਅਚਾਨਕ ਤੇਜ਼-ਬੜ੍ਹੀਆਂ, ਸਪਸ਼ਟ ਫਿਕਸ ਪ੍ਰਾਇਓਰਿਟੀ, ਅਤੇ ਸੁਰੱਖਿਆ ਰਿਪੋਰਟਾਂ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਲੈਣ ਦੀ شہرت।

ਇੱਕ vulnerability disclosure program ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

VDP ਇੱਕ ਸਰਵਜਨਿਕ ਅਤੇ ਪੂਰਵਧਾਰਿਤ ਤਰੀਕਾ ਹੈ ਜਿੱਥੇ ਲੋਕ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਆ ਮੁੱਦੇ ਰਿਪੋਰਟ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰ ਸਕਦੀ ਹੈ। ਇਹ ਇਨਾਮ ਦੇਣ ਵਾਲੇ ਕਾਰਜ ਨਹੀਂ ਹਨ। ਮਕਸਦ ਮੁੱਦਿਆਂ ਨੂੰ ਯੂਜ਼ਰਾਂ ਨੂੰ ਨੁਕਸਾਨ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰਨਾ ਹੈ।

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

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

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

ਰਿਪੋਰਟ ਮਿਲਣ 'ਤੇ ਤੁਸੀਂ ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਕੁਝ ਵਾਅਦੇ ਕਰਦੇ ਹੋ, ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ responsible disclosure policy ਵਿੱਚ। ਛੋਟੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਸਿਰਫ ਉਹੀ ਵਾਅਦੇ ਕਰੋ ਜੋ ਤੁਸੀਂ ਰੱਖ ਸਕਦੇ ਹੋ। ਘੱਟੋ-ਘੱਟ: ਤੁਸੀਂ ਰਿਪੋਰਟ ਨੂੰ ਅਕਨਾਲੇਜ ਕਰੋਗੇ, ਬੁਨਿਆਦੀ ਟ੍ਰਾਇਅਜ ਕਰੋਂਗੇ, ਅਤੇ ਰਿਪੋਰਟਰ ਨੂੰ ਅਪਡੇਟ ਰੱਖੋਗੇ।

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

ਬੱਗ ਬਾਊਂਟੀਜ਼ বনਾਮ VDPs: ਸਹੀ ਸ਼ੁਰੂਆਤ ਚੁਣੋ

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

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

ਬਾਊਂਟੀ ਤਦ ਹੀ ਸਮਝਦਾਰ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਹਾਡੀ ਟੀਮ ਇਹ ਨਿਭਾ ਸਕੇ। ਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ ਰੋਜ਼ ਬਦਲਦਾ ਹੈ, ਲੌਗਿੰਗ ਕਮਜ਼ੋਰ ਹੈ, ਜਾਂ ਕਿਸੇ ਕੋਲ ਵੀ ਸੁਰੱਖਿਆ ਟ੍ਰਾਇਅਜ ਦੀ ਮਲਕੀਅਤ ਨਹੀਂ, ਤਾਂ ਬਾਊਂਟੀ ਇੱਕ ऐसी ਕਤਾਰ ਬਣਾਈਗਾ ਜੋ ਤੁਸੀਂ ਸਾਫ਼ ਨਹੀਂ ਕਰ ਸਕੋਗੇ। ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਥਿਰ ਸਰਫੇਸ, ਖੋਜ ਲਾਇਕ ਪ੍ਰਾਪਤੀ ਪਾਉਣ ਲਈ ਕਾਫੀ ਐਕਸਪੋਜ਼ਰ, ਹੋਰਤੀ ਤੌਰ 'ਤੇ ਦਿਨਾਂ ਜਾਂ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਟ੍ਰਾਇਅਜ ਅਤੇ ਫਿਕਸ ਕਰਨ ਦੀ ਸਮਰੱਥਾ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਬਜਟ ਅਤੇ ਭੁਗਤਾਨ ਤਰੀਕਾ ਹੋਵੇ ਤਾਂ ਬਾਊਂਟੀ ਬਾਰੇ ਸੋਚੋ।

ਇਨਾਮ ਲਈ, ਇਸਨੂੰ ਸਧਾਰਨ ਰੱਖੋ: ਗੰਭੀਰਤਾ ਦੇ ਅਧਾਰ 'ਤੇ ਫਿਕਸ ਰੇਂਜ (low ਤੋਂ critical), ਅਤੇ ਅਸਧਾਰਣ ਤੌਰ 'ਤੇ ਸਪੱਸ਼ਟ, ਦੁਹਰਾਉਣ ਯੋਗ ਰਿਪੋਰਟਾਂ ਲਈ ਛੋਟੇ ਬੋਨਸ।

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

ਕਦਮ 1: ਅਜਿਹਾ ਸਕੋਪ ਨਿਰਧਾਰਤ ਕਰੋ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਸੰਭਾਲ ਸਕੇ

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

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

ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਕੀ ਸਕੋਪ ਵਿੱਚ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ। ਕੁਝ ਨਮੂਨੇ ਸ਼ਾਮਲ ਕਰਨ ਨਾਲ ਬਹੁਤ ਘਟ-ਵਿੱਚਾਰ ਹੁੰਦਾ ਹੈ:

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

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

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

ਉਦਾਹਰਨ: ਇੱਕ ਛੋਟੀ SaaS ਟੀਮ ਜੋ Koder.ai ਐਪ ਚਲਾਉਂਦੀ ਹੈ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀ ਹੈ "ਪ੍ਰੋਡਕਸ਼ਨ ਐਪ + ਸਾਡੇ ਮੁੱਖ ਡੋਮੇਨ 'ਤੇ ਪਬਲਿਕ API" ਨਾਲ ਅਤੇ ਗਾਹਕਾਂ ਦੀ self-hosted ਡੀਪਲੋਇਮੈਂਟ ਨੂੰ ਇਕਸਪਲਿਸਿਟ ਤੌਰ 'ਤੇ ਬਾਹਰ ਰੱਖ ਸਕਦੀ ਹੈ ਜਦ ਤੱਕ ਟੀਮ ਕੋਲ ਦੁਹਰਾਉਣ ਅਤੇ ਫਿਕਸ ਕਰਨ ਦਾ ਸਪਸ਼ਟ ਤਰੀਕਾ ਨਹੀਂ ਹੁੰਦਾ।

ਕਦਮ 2: ਐਜੇਹੇ ਨਿਯਮ ਲਿਖੋ ਜੋ ਯੂਜ਼ਰਾਂ ਅਤੇ ਖੋਜਕਾਰਾਂ ਦੀ ਰੱਖਿਆ ਕਰਨ

ਚੰਗੇ ਨਿਯਮ ਦੋ ਕੰਮ ਇਕੱਠੇ ਕਰਦੇ ਹਨ: ਉਹ ਅਸਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਖੋਜਕਾਰਾਂ ਨੂੰ ਭਰੋਸਾ ਦਿੰਦਿਆਂ ਹਨ ਕਿ ਉਹ ਚੰਗੇ ਇਰਾਦੇ ਨਾਲ ਰਿਪੋਰਟ ਕਰਨ 'ਤੇ ਸਜ਼ਾ ਨਹੀਂ ਪਾਉਣਗੇ। ਭਾਸ਼ਾ ਸਧਾਰਣ ਅਤੇ ਨਿਰਧਾਰਤ ਰੱਖੋ। ਜੇ ਇੱਕ ਟੈਸਟਰ ਨਹੀਂ ਸਮਝਦਾ ਕਿ ਕੀ ਮਨਜ਼ੂਰ ਹੈ, ਤਾਂ ਉਹ ਜਾਂ ਤਾਂ ਰੁਕ ਜਾਵੇਗਾ ਜਾਂ ਖਤਰਨਾਕ ਕਦਮ ਚੁੱਕੇਗਾ।

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

ਫਿਰ ਰਿਪੋਰਟ ਕਰਨ ਦਾ ਤਰੀਕਾ ਸਮਝਾਓ ਅਤੇ “ਉਪਯੋਗੀ” ਕੀ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਣ ਟੈਮਪਲੇਟ ਟ੍ਰਾਇਅਜ ਤੇਜ਼ ਕਰਦਾ ਹੈ: ਕਿੱਥੇ ਹੋਇਆ (URL/ਐਪ ਸਕ੍ਰੀਨ, ਵਾਤਾਵਰਣ, ਅਕਾਉਂਟ ਕਿਸਮ), ਦੁਹਰਾਉਣ ਲਈ ਨੰਬਰਵਾਰ ਕਦਮ, ਪ੍ਰਭਾਵ, ਸਬੂਤ ( ਸਕਰੀਨਸ਼ਾਟ, ਛੋਟੀ ਵੀਡੀਓ, request/response ), ਅਤੇ ਸੰਪਰਕ ਵੇਰਵੇ।

ਪ੍ਰਾਈਵੇਸੀ ਬਾਰੇ ਸਪਸ਼ਟ ਰਹੋ। ਖੋਜਕਾਰਾਂ ਨੂੰ ਕਹੋ ਕਿ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਘਟਾਓ, ਡਾਟਾਸੈਟ ਡਾਊਨਲੋਡ ਕਰਨ ਤੋਂ ਬਚੋ, ਅਤੇ ਸਕਰੀਨਸ਼ਾਟਾਂ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ (ਈਮੇਲ, ਟੋਕਨ, ਨਿੱਜੀ ਵੇਰਵੇ) ਨੂੰ ਰੈਡੈਕਟ ਕਰੋ। ਜੇ ਉਹਨਾਂ ਨੂੰ ਪਹੁੰਚ ਸਾਬਤ ਕਰਨ ਲਈ ਕੁਝ ਦਿਖਾਉਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਤਾਂ ਸਭ ਤੋਂ ਛੋਟਾ ਸਮਾਂਪਲ ਮੰਗੋ।

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

ਕਦਮ 3: ਇੱਕ ਐਸਾ ਟ੍ਰਾਇਅਜ ਵਰਕਫਲੋ ਬਣਾਓ ਜੋ ਰੁਕਾਵਟ ਨਾ ਹੋਵੇ

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

ਪੂਰੇ ਟੀਮ ਲਈ ਲਾਗੂ ਕੀਤੀ ਜਾ ਸਕਣ ਵਾਲਾ ਇੱਕ ਛੋਟਾ severity rubric ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:

• Critical: ਰਿਮੋਟ ਕੋਡ ਏਗਜ਼ੈਕਿਊਸ਼ਨ, ਅਥੈਂਟ ਬਾਈਪਾਸ, ਜਾਂ ਵਿਆਪਕ ਡੇਟਾ ਖੁਲਾਸਾ।
• High: ਇੱਕ ਯੂਜ਼ਰ ਲਈ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਖੁਲਾਸਾ, ਗੰਭੀਰ ਪਰਮੀਸ਼ਨ ਮੁੱਦੇ, ਜਾਂ ਭਰੋਸੇਯੋਗ ਅਕਾਊਂਟ ਟੇਕਓਵਰ।
• Medium: ਸੀਮਿਤ ਪ੍ਰਭਾਵ ਵਾਲੇ ਬੱਗ, ਮੁਸ਼ਕਿਲ-ਇਕਸਪਲੌਇਟ ਇਸ਼ੂਜ਼, ਅੰਸ਼ਿਕ ਜਾਣਕਾਰੀ ਲੀਕ।
• Low: ਕੋਈ ਸਪਸ਼ਟ ਪ੍ਰਭਾਵ ਨਾ ਰੱਖਣ ਵਾਲੇ ਬਿਹਤਰ ਅਭਿਆਸ ਸੰਬੰਧੀ ਖ਼ਾਮੀਆਂ (ਉਦਾਹਰਨ ਵਜੋਂ, ਗੁੰਮ ਹੋਏ ਹेडਰ)।

ਪਹਿਲੀ ਪ੍ਰਤੀਕਿਰਿਆ ਇੱਕ ਵਿਅਕਤੀ (ਸੁਰੱਖਿਆ ਲੀਡ, on-call ਇੰਜੀਨੀਅਰ, ਜਾਂ ਫਾਉਂਡਰ) ਨੂੰ ਸੌਂਪੋ, ਨਾਲ ਹੀ ਹਫ਼ਤੇ ਦੇ ਅੰਤ ਅਤੇ ਛੁੱਟੀਆਂ ਲਈ ਬੈਕਅਪ ਰੱਖੋ। ਇਹ ਇਕੱਲਾ ਫੈਸਲਾ "ਕੋਈ ਹੋਰ ਸੰਭਾਲੇਗਾ" ਦੇ ਡੀਫ਼ਾਲਟ ਨੂੰ ਰੋਕਦਾ ਹੈ।

ਝੂਠੇ ਸਕੈਨ ਆਉਟਪੁੱਟ ਅਤੇ "ਸੁਰੱਖਿਆ ਥੀਏਟਰ" ਘਟਾਉਣ ਲਈ ਇੱਕ ਵਸਤੁ ਸੰਪੱਦ ਚਾਹੋ: ਇੱਕ ਦੁਹਰਾਉਣਯੋਗ ਸਬੂਤ। ਇਹ ਕਦਮ, ਇੱਕ ਛੋਟੀ ਵੀਡੀਓ, ਜਾਂ ਨਿਊਨਤਮ request/response ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਦੁਹਰਾਇਆ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਇਹ ਕਹੋ, ਜੋ ਤੁਸੀਂ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਉਹ ਵਰਨਣ ਕਰੋ, ਅਤੇ ਇੱਕ ਲਕੜੀ ਲਈ ਸਵਾਲ ਪੁੱਛੋ। ਸਕੈਨਰ ਆਉਟਪੁੱਟ ਨੂੰ ਨੀਰਣੈਯਕ ਨਹੀਂ, ਇੱਕ ਇਸ਼ਾਰਾ ਸਮਝੋ।

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

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

ਕਦਮ 4: ਪ੍ਰਤੀਕਿਰਿਆ ਸਮਾਂ-ਰੇਖਾ ਨਿਰਧਾਰਤ ਕਰੋ ਅਤੇ ਉਨ੍ਹਾਂ 'ਤੇ ਟਿਕੇ ਰਹੋ

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

ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਬਹੁਤੀਆਂ ਵਾਅਦੀਆਂ ਜੋ ਅਕਸਰ ਸੰਭਵ ਹੁੰਦੀਆਂ ਹਨ:

• ਪ੍ਰਾਪਤੀ ਦੀ ਪੁਸ਼ਟੀ: 1-2 ਕਾਰੋਬਾਰੀ ਦਿਨਾਂ ਦੇ ਅੰਦਰ
• ਪ੍ਰਾਰੰਭਿਕ ਟ੍ਰਾਇਅਜ: 5 ਕਾਰੋਬਾਰੀ ਦਿਨਾਂ ਦੇ ਅੰਦਰ
• ਗੰਭੀਰਤਾ ਦੇ ਅਧਾਰ 'ਤੇ ਫਿਕਸ ਟਾਰਗੇਟ: Critical 7-14 ਦਿਨ, High 30 ਦਿਨ, Medium 60 ਦਿਨ, Low 90 ਦਿਨ
• ਖੋਜਕਾਰ ਅਪਡੇਟਸ: ਬੰਦ ਹੋਣ ਤੱਕ ਘੱਟੋ-ਘੱਟ ਹਰ 7-14 ਦਿਨ
• ਕਲੋਜ਼ਰ: ਫਿਕਸ ਦੀ ਪੁਸ਼ਟੀ, ਸਮਨ્વਿਤ ਡਿਕਲੋਜ਼ਰ, ਨਤੀਜੇ ਦਾ ਦਸਤਾਵੇਜ਼

ਜੇ ਤੁਸੀਂ ਇਹ ਨੰਬਰ ਨਹੀਂ ਮਿਲਾ ਸਕਦੇ, ਤਾਂ ਹੁਣ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਧ ਕਰੋ ਬਜਾਏ ਕਿ ਬਾਅਦ ਵਿੱਚ ਨਾਂ-ਪਾਲਨਾ ਕਰੋਂ। ਵਧੀਆ ਹੈ ਕਿ "30 ਦਿਨ" ਬੋਲੋ ਅਤੇ 20 ਵਿੱਚ ਡਿਲਿਵਰ ਕਰੋ ਬਜਾਏ "7 ਦਿਨ" ਦਾ ਵਾਅਦਾ ਕਰਨ ਦੇ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਖਾਮੋਸ਼ ਹੋ ਜਾਣ ਦੀ।

ਸਥਿਤੀ ਅਪਡੇਟ ਜੋ ਗੱਲਾਂ ਨੂੰ ਸ਼ਾਂਤ ਰੱਖਦੀਆਂ ਹਨ

ਰਿਪੋਰਟ ਖੋਜਕਾਰਾਂ ਲਈ ਤਤਕਾਲ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ। ਭਾਵੇਂ ਤੁਹਾਡੇ ਕੋਲ ਹੁਣੇ ਫਿਕਸ ਨਾ ਹੋਵੇ, ਨਿਯਮਤ ਅਪਡੇਟ ਨਿਰਾਸ਼ਾ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਜਨਤਕ ਸਥਿਤੀ ਲਈ ਪ੍ਰੇਰਿਤ ਹੋਣ ਤੋਂ ਰੋਕਦੇ ਹਨ। ਇੱਕ ਪੇਸ਼ਗੋਈ ਕੈਡੈਂਸ ਵਰਤੋ ਅਤੇ ਸ਼ਾਮਿਲ ਕਰੋ: ਮੌਜੂਦਾ ਸਥਿਤੀ (ਟ੍ਰਾਇਅਜ, ਫਿਕਸ, ਜਾਂ ਟੈਸਟਿੰਗ), ਅੱਗਲਾ ਕਦਮ, ਅਤੇ ਅਗਲੀ ਅਪਡੇਟ ਦੀ ਤਾਰੀਖ।

ਸਮਨਵਿਤ ਡਿਕਲੋਜ਼ਰ ਅਤੇ ਪਬਲਿਕ ਸਮਾਂ-ਰੇਖਾ

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

ਟ੍ਰਾਇਅਜ ਤੋਂ ਬਾਅਦ: ਫਿਕਸ ਅਤੇ ਸੰਚਾਰ ਕਿਵੇਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

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

ਛੋਟੀਆਂ-ਸ਼ੌਰਟ ਟਰਮ ਮਿਟੀਗੇਸ਼ਨ ਉਸ ਸਮੇਂ ਸਮਾਂ ਖਰੀਦਦੇ ਹਨ ਜਦੋਂ ਇੱਕ ਪੂਰਾ ਫਿਕਸ ਖਤਰਨਾਕ ਜਾਂ धीਮਾ ਹੋਵੇ। ਆਮ ਵਿਕਲਪ ਵਿੱਚ ਇੱਕ ਫੀਚਰ ਨੂੰ ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਬੰਦ ਕਰਨਾ, ਰੇਟ ਲਿਮਿਟਸ ਕਸਣਾ, ਗਲਤ ਰਿਕਵੈਸਟ ਪੈਟਰਨ ਨੂੰ ব্লੌਕ ਕਰਨਾ, ਪ੍ਰਕਾਸ਼ਤ ਗੁਪਤਚਾਬੀਆਂ ਨੂੰ ਘੁਮਾ ਦੈਣਾ, ਜਾਂ ਲੌਗਿੰਗ ਅਤੇ ਅਲਰਟਜ਼ ਜੋੜਨਾ ਸ਼ਾਮਲ ਹਨ। ਮਿਟੀਗੇਸ਼ਨ ਨੂੰ ਅੰਤਿਆ ਟੀਕ ਨਹੀਂ ਮੰਨਣਾ ਚਾਹੀਦਾ, ਪਰ ਇਹ ਨੁਕਸਾਨ ਘਟਾਉਂਦੀਆਂ ਹਨ ਜਦ ਤੱਕ ਤੁਸੀਂ ਅਸਲੀ ਮੁਰੰਮਤ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋ।

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

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

ਜਦੋਂ ਮੁੱਦਾ ਕਈ ਯੂਜ਼ਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ, ਮੁੜਖੋਜ ਲਈ ਸੰਭਾਵਨਾ ਜ਼ਿਆਦਾ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਯੂਜ਼ਰ ਐਕਸ਼ਨ ਜਰੂਰੀ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਛੋਟੀ ਸਲਾਹ-ਮਸ਼ਵਰਾ ਜਾਰੀ ਕਰੋ। ਇੱਕ ਸੰਖੇਪ ਸਮਰੀ, ਗੰਭੀਰਤਾ, ਪ੍ਰਭਾਵਿਤ ਕੰਪੋਨੈਂਟ, ਫਿਕਸ ਦੀ ਤਾਰੀਖ, ਅਤੇ ਰਿਪੋਰਟਰ ਨੂੰ ਕ੍ਰੈਡਿਟ (ਜੇ ਉਹ ਚਾਹੁੰਦੇ ਹਨ) ਸ਼ਾਮਲ ਕਰੋ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ, ਜਿੱਥੇ ਐਪ ਡਿਪਲੌਯਡ ਅਤੇ ਹੋਸਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਐਡਵਾਈਜ਼ਰੀ ਉਹਨਾਂ ਟੀਮਾਂ ਨੂੰ ਵੀ ਮਦਦ ਕਰਦੇ ਹਨ ਜੋ exports ਜਾਂ custom ਡੋਮੇਨ ਵਰਤ ਰਹੀਆਂ ਹਨ ਤਾਂ ਕਿ ਉਹ ਜਾਣ ਸਕਣ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਦੁਬਾਰਾ ਡਿਪਲੌਯ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਨਹੀਂ।

ਛੋਟੀਆਂ ਟੀਮਾਂ ਦੀਆਂ ਆਮ ਗਲਤੀਆਂ (ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ ਕਿਵੇਂ ਬਚਣਾ)

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

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

ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਸਭ ਤੋਂ ਸਰਲ ਠੀਕ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ:

• ਪਹਿਲੇ ਦਿਨ ਹਰ ਐਸੈੱਟ ਅਤੇ ਹਰ ਬੱਗ ਕਿਸਮ ਲੈ लेना। ਠੀਕ: ਇੱਕ ਤੰਗ ਸਕੋਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ (ਇੱਕ ਐਪ, ਇੱਕ ਡੋਮੇਨ, ਇੱਕ API) ਅਤੇ ਕੇਵਲ ਫਿਰ ਵਧਾਓ ਜਦੋਂ ਤੁਸੀਂ ਨਿਭਾ ਸਕੋ।
• ਅਧੁਰੇ ਨਿਯਮ ਛਪਾਉਣਾ। ਠੀਕ: ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ ਲਿਖੋ (ਕਿਹੜੀ ਟੈਸਟਿੰਗ ਮਨਜ਼ੂਰ ਹੈ, ਕਿਹੜਾ ਡੇਟਾ ਨਹੀਂ ਛੇਡਣਾ, ਕਿਵੇਂ ਰਿਪੋਰਟ ਕਰਨਾ)।
• ਕੋਈ ਸਪਸ਼ਟ ਟ੍ਰਾਇਅਜ ਮਾਲਕ ਨਹੀਂ। ਠੀਕ: ਇੱਕ ਇਨਬਾਕਸ ਅਤੇ ਇੱਕ ਵਿਅਕਤੀ (ਸਾਥੀ ਬੈਕਅਪ) ਨਿਰਧਾਰਤ ਕਰੋ ਜੋ ਰਿਪੋਰਟਾਂ ਨੂੰ ਅਕਨਾਲੇਜ ਕਰੇ।
• ਅਜਿਹੇ ਪ੍ਰਤੀਕਿਰਿਆ ਜਾਂ ਭੁਗਤਾਨ ਸ਼ਰਤਾਂ ਦਾ ਵਾਅਦਾ ਕਰਦਾ ਜੋ ਤੁਸੀਂ ਪੂਰ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਠੀਕ: ਸੰਭਾਲੀ ਗਈਆਂ ਸਮਾਂ-ਰੇਖਾ ਅਤੇ ਇਨਾਮ ਨਿਰਧਾਰਿਤ ਕਰੋ, ਫਿਰ ਉਹਨਾਂ ਤੋਂ ਤੇਜ਼ ਕਰੋ।
• ਖੋਜਕਾਰਾਂ ਨੂੰ ਦੁਸ਼ਮਣ ਵਾਂਗ ਪ੍ਰਭਾਵਿਤ ਕਰਨਾ। ਠੀਕ: ਪਹਿਲਾਂ ਚੰਗਾ-ਇਰਾਦਾ ਮੰਨੋ, ਸਪਸ਼ਟ سوال ਪੁੱਛੋ, ਅਤੇ ਝੂਠੀ ਚੇਤਾਵਨੀ 'ਤੇ ਵੀ ਧੰਨਵਾਦ ਕਰੋ।

ਉਦਾਹਰਨ: ਇੱਕ ਖੋਜਕਾਰ ਨੇ ਇਕ ਇਕਸਪੋਜ਼ਡ ਸਟੇਜਿੰਗ ਐਂਡਪੌਇੰਟ ਰਿਪੋਰਟ ਕੀਤਾ। ਜੇ ਤੁਹਾਡੇ ਨਿਯਮ ਸਟੇਜਿੰਗ ਦਾ ਜ਼ਿਕਰ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਤੁਹਾਡੀ ਟੀਮ ਦਿਨਾਂ ਤੱਕ ਇਸ 'ਤੇ بحث ਕਰ ਸਕਦੀ ਹੈ। ਜੇ ਸਟੇਜਿੰਗ ਸ਼ਾਮਲ ਹੈ ਜਾਂ ਖੁੱਲ੍ਹਾ-ਖੁੱਲ੍ਹਾ ਬਾਹਰ ਰੱਖਿਆ ਗਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ ਸਕਦੇ ਹੋ, ਸਹੀ ਰਸਤੇ 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਗੱਲਬਾਤ ਸ਼ਾਂਤ ਰੱਖ ਸਕਦੇ ਹੋ।

ਤੁਰੰਤ ਚੈੱਕਲਿਸਟ: ਤੁਹਾਡਾ ਘੱਟੋ-ਘੱਟ ਯੋਗ VDP

ਇੱਕ ਘੱਟੋ-ਘੱਟ ਯੋਗ vulnerability disclosure program ਇਸ ਗੱਲ ਬਾਰੇ ਘੱਟ ਨਹੀਂ ਕਿ ਕਾਗਜ਼ੀ ਕਾਰਵਾਈ ਪੂਰਨ ਹੋਵੇ, ਸਗੋਂ ਯਕੀਨੀ ਵਤੀਵਾਹਾਰ ਬਾਰੇ ਹੈ। ਲੋਕਾਂ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਕੀ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹਨ, ਕਿਵੇਂ ਰਿਪੋਰਟ ਕਰਨਾ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਕਦੋਂ ਪ੍ਰਤੀਕਿਰਿਆ ਮਿਲੇਗੀ।

ਚੈੱਕਲਿਸਟ ਛੋਟੀ ਰੱਖੋ:

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

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

ਉਦਾਹਰਣ ਸਿਨਾਰੀਓ: ਇਕ ਪਹਿਲੀ ਰਿਪੋਰਟ ਇੱਕ ਸੁਰੱਖਿਆ ਖੋਜਕਾਰ ਤੋਂ

ਇੱਕ ਤਿੰਨ-ਇਨਸਾਨ SaaS ਟੀਮ ਨੂੰ ਇੱਕ ਈਮੇਲ ਮਿਲਦੀ ਹੈ ਸਿਰਲੇਖ ਨਾਲ: “Possible account takeover via password reset.” ਖੋਜਕਾਰ ਕਹਿੰਦਾ ਹੈ ਕਿ ਉਹ ਕਿਸੇ ਪੀੜਤ ਦੇ ਈਮੇਲ ਪਤਾ ਨੂੰ ਜਾਣ ਕੇ ਪਾਸਵਰਡ ਰੀਸੈਟ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਰੀਸੈਟ ਲਿੰਕ ਪੁਰਾਣਾ ਹੋਣ 'ਤੇ ਵੀ ਵੈਧ ਰਹਿੰਦਾ ਹੈ।

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

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

ਉਹ ਇਸਨੂੰ High severity ਲੇਬਲ ਕਰਦੇ ਹਨ: ਇਹ ਇੱਕ ਹਕੀਕਤੀ ਰਾਹ ਨਾਲ ਖਾਤਾ ਟੇਕਓਵਰ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ। ਆਪਣੀ ਨੀਤੀ ਤਹਿਤ, ਉਹ 72 ਘੰਟਿਆਂ ਵਿੱਚ ਮਿਟੀਗੇਸ਼ਨ ਅਤੇ 7 ਦਿਨਾਂ ਵਿੱਚ ਪੂਰਾ ਫਿਕਸ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ।

ਉਹ ਰਿਪੋਰਟਰ ਨੂੰ ਹਰ ਪੜਾਅ 'ਤੇ ਅਪਡੇਟ ਰੱਖਦੇ ਹਨ:

• Day 0: “Received. We are validating in a test environment. We will update you within 24 hours.”
• Day 1: “Confirmed. This is High severity. Mitigation planned within 72 hours.”
• Day 3: “Mitigation shipped: invalidate prior reset tokens when a new one is issued.”
• Day 7: “Full fix shipped: tokens now expire faster and are single-use. Can you re-test?”

ਬੰਦ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਉਹ ਦੁਹਰਾਵਟਾਂ ਨੂੰ ਰੋਕਣ ਲਈ ਇੱਕ ਆਟੋਮੇਟੈਡ ਟੈਸਟ ਜੋੜਦੇ ਹਨ ਜੋ single-use reset tokens ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਅਣੁਸਾਰ reset ਵਾਲੀ ਰਕਤ ਲਈ ਮਾਨਨਕ ਤਾਕਤ ਦੇਖਦੇ ਹਨ, ਅਤੇ ਆਪਣੀ ਅੰਦਰੂਨੀ ਚੈੱਕਲਿਸਟ ਅੱਪਡੇਟ ਕਰਦੇ ਹਨ: “ਕੋਈ ਵੀ ਲੌਗਿਨ ਜਾਂ ਰੀਸੈਟ ਟੋਕਨ single-use, ਛੋਟੀ ਮਿਆਦ ਵਾਲਾ, ਅਤੇ ਨਵੀਂ ਜਾਰੀਗੀ 'ਤੇ ਅਵੈਲਿਡੇਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।”

ਅਗਲੇ ਕਦਮ: ਛੋਟੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਮਾਸਿਕ ਸੁਧਾਰ ਕਰੋ, ਅਤੇ ਜ਼ਿੰਮੇਵਾਰ ਤਰੀਕੇ ਨਾਲ ਸਕੇਲ ਕਰੋ

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

ਕੁਝ ਗਿਣਤੀ ਟ੍ਰੈਕ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਤਰੱਕੀ ਵੇਖ ਸਕੋ ਬਿਨਾਂ ਇਸਨੂੰ ਫੁੱਲ-ਟਾਈਮ ਕੰਮ ਬਣਾਇਆ:

• ਅਕਨਾਲੇਜ ਕਰਨ ਦਾ ਸਮਾਂ
• ਟ੍ਰਾਇਅਜ ਕਰਨ ਦਾ ਸਮਾਂ
• ਫਿਕਸ ਕਰਨ ਦਾ ਸਮਾਂ (ਜਾਂ ਸੁਰੱਖਿਅਤ ਮਿਟੀਗੇਸ਼ਨ ਲਿਆਉਣ ਦਾ ਸਮਾਂ)
• ਰੀਓਪਨ ਦਰ
• ਕਿੰਨੀ ਰਿਪੋਰਟਾਂ ਵਾਸਤਵ ਵਿੱਚ ਕਾਰਜਯੋਗ ਸਨ

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

ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਦੀ ਹੈ, ਤਾਂ “ਸੁਰੱਖਿਅਤ ਰਿਲੀਜ਼” ਨੂੰ ਯੋਜਨਾ ਦਾ ਹਿੱਸਾ ਬਣਾਓ। ਛੋਟੇ, ਵਾਪਸ ਲਿਆਂਦੇ ਜਾ ਸਕਣ ਵਾਲੇ ਬਦਲਾਅ ਲਈ ਨਿਸ਼ਾਨ ਬਣਾਓ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ snapshots ਅਤੇ rollback ਉਪਲਬਧ ਹਨ ਤਾਂ ਉਹ ਵਰਤੋ ਤਾਂ ਕਿ ਇੱਕ ਸੁਰੱਖਿਆ ਫਿਕਸ ਇੱਕ ਲੰਬੇ ਆਉਟਜ ਵਿਚ ਨਾ ਬਦਲ ਜਾਵੇ।

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਮਾਸਿਕ ਰਿਦਮ:

• ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਇੱਕ ਜਾਂ ਦੋ ਸੁਸਤ ਕੇਸਸ ਦੀ ਸਮੀਖਿਆ ਕਰੋ
• ਜਿੱਥੇ ਗਲਤਫਹਮੀ ਵੇਖੀ ਗਈ, ਉਥੇ ਸਕੋਪ ਅਤੇ ਨਿਯਮ ਤੰਗ ਕਰੋ
• ਆਪਣੀ ਟ੍ਰਾਇਅਜ ਚੈੱਕਲਿਸਟ ਅਤੇ ਗੰਭੀਰਤਾ ਉਦਾਹਰਨ ਅਪਡੇਟ ਕਰੋ
• ਇੱਕ ਵਾਰੀ rollback ਜਾਂ recovery ਕਦਮ ਟੈਸਟ ਕਰੋ

ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) 'ਤੇ ਬਣਾਓ, ਤਾਂ ਡਿਪਲੌਇਮੈਂਟ ਅਤੇ ਹੋਸਟਿੰਗ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਹਨ, ਅਤੇ ਜਦੋਂ ਤੁਹਾਨੂੰ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸੋর্স ਕੋਡ export ਉਪਲਬਧ ਹੁੰਦਾ ਹੈ। ਇਹ ਸੁਰੱਖਿਆ ਫਿਕਸ ਤੇਜ਼ੀ ਨਾਲ ਪুশ ਕਰਨ ਅਤੇ ਜੇ ਕਿਸੇ ਬਦਲاؤ ਤੋਂ ਸਾਈਡ-ਇਫੈਕਟ ਆ ਜਾਵੇ ਤਾਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ recuperação ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ।