ਕਮਜ਼ੋਰੀ ਸਕੈਨਿੰਗ ਅਤੇ ਸੁਰੱਖਿਅਤ ਵਿਕਾਸ। ਭਾਗ 1

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

ਤਕਨੀਕੀ ਤਰੱਕੀ ਅਜੇ ਉਸ ਬਿੰਦੂ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚੀ ਹੈ ਜਿੱਥੇ ਇੱਕ ਸਾਧਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਅਤੇ ਸੌਫਟਵੇਅਰ ਦੀ ਸੁਰੱਖਿਆ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਇੱਕ ਵਿਅਕਤੀ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ.
ਇਹ ਸਮਝਣਾ ਦਿਲਚਸਪ ਹੈ ਕਿ ਅਜਿਹਾ ਕਿਉਂ ਹੈ ਅਤੇ ਕਿਸੇ ਨੂੰ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

ਪ੍ਰਕਿਰਿਆਵਾਂ

ਕਮਜ਼ੋਰੀ ਪ੍ਰਬੰਧਨ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਸੁਰੱਖਿਆ ਅਤੇ ਪੈਚ ਪ੍ਰਬੰਧਨ ਦੀ ਨਿਰੰਤਰ ਨਿਗਰਾਨੀ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ।
ਸਕਿਓਰ SDLC ਪ੍ਰਕਿਰਿਆ ("ਸੁਰੱਖਿਅਤ ਵਿਕਾਸ ਚੱਕਰ") ਵਿਕਾਸ ਅਤੇ ਸੰਚਾਲਨ ਦੌਰਾਨ ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਤਿਆਰ ਕੀਤੀ ਗਈ ਹੈ।

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

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

ਇੱਕ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸਕੈਨਰ ਨੂੰ ਅਕਸਰ ਟਾਈਮਰ ਨਾਲ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਮੈਂ ਇਸਨੂੰ ਰੱਖਦਾ ਹਾਂ avleonov. ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ, ਸ਼ੁੱਧ ਤੌਰ 'ਤੇ ਅੰਕੜਿਆਂ ਦੇ ਰੂਪ ਵਿੱਚ, ਤੁਸੀਂ ਆਪਣੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਕਮਜ਼ੋਰ ਸਮਝ ਸਕਦੇ ਹੋ ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਮਹੀਨੇ ਲਈ ਅਪਡੇਟ ਨਹੀਂ ਕੀਤਾ ਹੈ, ਕਹੋ।

ਸੰਦ

ਸਕੈਨਿੰਗ, ਜਿਵੇਂ ਸੁਰੱਖਿਆ ਵਿਸ਼ਲੇਸ਼ਣ, ਬਲੈਕ ਬਾਕਸ ਜਾਂ ਸਫੈਦ ਬਾਕਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਬਲੈਕ ਬਾਕਸ

ਬਲੈਕਬਾਕਸ ਸਕੈਨ ਕਰਨ ਵੇਲੇ, ਟੂਲ ਨੂੰ ਉਸੇ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਸੇਵਾ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਰਾਹੀਂ ਉਪਭੋਗਤਾ ਇਸਦੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ।

ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸਕੈਨਰ (ਟੇਨੇਬਲ ਨੇਸਸ, ਕੁਆਲਿਸ, ਮੈਕਸਪੈਟ੍ਰੋਲ, ਰੈਪਿਡ 7 ਨੇਕਸਪੋਜ਼, ਆਦਿ) ਓਪਨ ਨੈੱਟਵਰਕ ਪੋਰਟਾਂ ਦੀ ਖੋਜ ਕਰਦੇ ਹਨ, "ਬੈਨਰ" ਇਕੱਠੇ ਕਰਦੇ ਹਨ, ਇੰਸਟਾਲ ਕੀਤੇ ਸੌਫਟਵੇਅਰ ਦੇ ਸੰਸਕਰਣ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਕਮਜ਼ੋਰੀਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਲਈ ਉਹਨਾਂ ਦੇ ਗਿਆਨ ਅਧਾਰ ਦੀ ਖੋਜ ਕਰਦੇ ਹਨ। ਉਹ ਸੰਰਚਨਾ ਦੀਆਂ ਗਲਤੀਆਂ ਜਿਵੇਂ ਕਿ ਡਿਫੌਲਟ ਪਾਸਵਰਡ ਜਾਂ ਓਪਨ ਡਾਟਾ ਐਕਸੈਸ, ਕਮਜ਼ੋਰ SSL ਸਿਫਰ, ਆਦਿ ਦਾ ਪਤਾ ਲਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਵੀ ਕਰਦੇ ਹਨ।

ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਸਕੈਨਰ (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, ਆਦਿ) ਵੀ ਜਾਣੇ-ਪਛਾਣੇ ਹਿੱਸਿਆਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਸੰਸਕਰਣਾਂ (ਉਦਾਹਰਨ ਲਈ, CMS, ਫਰੇਮਵਰਕ, JS ਲਾਇਬ੍ਰੇਰੀਆਂ) ਦੀ ਪਛਾਣ ਕਰ ਸਕਦੇ ਹਨ। ਸਕੈਨਰ ਦੇ ਮੁੱਖ ਪੜਾਅ ਕ੍ਰੌਲਿੰਗ ਅਤੇ ਫਜ਼ਿੰਗ ਹਨ।
ਕ੍ਰੌਲਿੰਗ ਦੇ ਦੌਰਾਨ, ਸਕੈਨਰ ਮੌਜੂਦਾ ਐਪਲੀਕੇਸ਼ਨ ਇੰਟਰਫੇਸ ਅਤੇ HTTP ਪੈਰਾਮੀਟਰਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਦਾ ਹੈ। ਫਜ਼ਿੰਗ ਦੇ ਦੌਰਾਨ, ਪਰਿਵਰਤਿਤ ਜਾਂ ਉਤਪੰਨ ਡੇਟਾ ਨੂੰ ਇੱਕ ਗਲਤੀ ਨੂੰ ਭੜਕਾਉਣ ਅਤੇ ਇੱਕ ਕਮਜ਼ੋਰੀ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਸਾਰੇ ਖੋਜੇ ਪੈਰਾਮੀਟਰਾਂ ਵਿੱਚ ਸੰਮਿਲਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਅਜਿਹੇ ਐਪਲੀਕੇਸ਼ਨ ਸਕੈਨਰ DAST ਅਤੇ IAST ਕਲਾਸਾਂ ਨਾਲ ਸਬੰਧਤ ਹਨ - ਕ੍ਰਮਵਾਰ ਡਾਇਨਾਮਿਕ ਅਤੇ ਇੰਟਰਐਕਟਿਵ ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਟੈਸਟਿੰਗ।

ਵ੍ਹਾਈਟ ਬਾਕਸ

ਵ੍ਹਾਈਟਬਾਕਸ ਸਕੈਨਿੰਗ ਨਾਲ ਹੋਰ ਅੰਤਰ ਹਨ।
VM ਪ੍ਰਕਿਰਿਆ ਦੇ ਹਿੱਸੇ ਵਜੋਂ, ਸਕੈਨਰਾਂ (Vulners, Insecurity Couch, Vuls, Tenable Nessus, ਆਦਿ) ਨੂੰ ਅਕਸਰ ਪ੍ਰਮਾਣਿਤ ਸਕੈਨ ਕਰਕੇ ਸਿਸਟਮਾਂ ਤੱਕ ਪਹੁੰਚ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਸਕੈਨਰ ਨੈੱਟਵਰਕ ਸੇਵਾ ਬੈਨਰਾਂ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਗਾਏ ਬਿਨਾਂ, ਸਿਸਟਮ ਤੋਂ ਇੰਸਟਾਲ ਕੀਤੇ ਪੈਕੇਜ ਸੰਸਕਰਣਾਂ ਅਤੇ ਸੰਰਚਨਾ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਸਿੱਧਾ ਡਾਊਨਲੋਡ ਕਰ ਸਕਦਾ ਹੈ।
ਸਕੈਨ ਵਧੇਰੇ ਸਹੀ ਅਤੇ ਸੰਪੂਰਨ ਹੈ।

ਜੇਕਰ ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਵ੍ਹਾਈਟਬਾਕਸ ਸਕੈਨਿੰਗ (ਚੈੱਕਮਾਰਕਸ, ਐਚਪੀ ਫੋਰਟੀਫਾਈ, ਕਵਰਿਟੀ, RIPS, FindSecBugs, ਆਦਿ) ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਸਟੈਟਿਕ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ SAST ਕਲਾਸ ਦੇ ਢੁਕਵੇਂ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ - ਸਟੈਟਿਕ ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਟੈਸਟਿੰਗ।

ਸਮੱਸਿਆਵਾਂ

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

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

ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਸਕੈਨਿੰਗ ਮੁੱਦੇ

1. ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ. ਸਕੈਨਰਾਂ ਨੂੰ ਹਰੇਕ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਤੈਨਾਤ, ਸੰਰਚਨਾ, ਅਨੁਕੂਲਿਤ ਕਰਨ, ਸਕੈਨ ਲਈ ਇੱਕ ਟੈਸਟ ਵਾਤਾਵਰਨ ਨਿਰਧਾਰਤ ਕਰਨ ਅਤੇ ਇਸਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣਾਉਣ ਲਈ CI/CD ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਨਹੀਂ ਤਾਂ, ਇਹ ਇੱਕ ਬੇਕਾਰ ਰਸਮੀ ਪ੍ਰਕਿਰਿਆ ਹੋਵੇਗੀ ਜੋ ਸਿਰਫ ਝੂਠੇ ਸਕਾਰਾਤਮਕ ਪੈਦਾ ਕਰੇਗੀ
2. ਸਕੈਨ ਦੀ ਮਿਆਦ। ਇੱਥੋਂ ਤੱਕ ਕਿ 2019 ਵਿੱਚ, ਸਕੈਨਰ ਇੰਟਰਫੇਸ ਨੂੰ ਡੁਪਲੀਕੇਟ ਕਰਨ ਦਾ ਇੱਕ ਮਾੜਾ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਹਰ ਇੱਕ 'ਤੇ 10 ਪੈਰਾਮੀਟਰਾਂ ਦੇ ਨਾਲ ਇੱਕ ਹਜ਼ਾਰ ਪੰਨਿਆਂ ਨੂੰ ਸਕੈਨ ਕਰਨ ਵਿੱਚ ਦਿਨ ਬਿਤਾ ਸਕਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਵੱਖਰਾ ਸਮਝਦੇ ਹੋਏ, ਹਾਲਾਂਕਿ ਉਹੀ ਕੋਡ ਉਹਨਾਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਵਿਕਾਸ ਚੱਕਰ ਦੇ ਅੰਦਰ ਉਤਪਾਦਨ ਲਈ ਤੈਨਾਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਜਲਦੀ ਲਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ
3. ਮਾੜੀਆਂ ਸਿਫ਼ਾਰਸ਼ਾਂ। ਸਕੈਨਰ ਕਾਫ਼ੀ ਆਮ ਸਿਫ਼ਾਰਸ਼ਾਂ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਡਿਵੈਲਪਰ ਉਹਨਾਂ ਤੋਂ ਹਮੇਸ਼ਾਂ ਜਲਦੀ ਇਹ ਨਹੀਂ ਸਮਝ ਸਕਦਾ ਕਿ ਜੋਖਮ ਦੇ ਪੱਧਰ ਨੂੰ ਕਿਵੇਂ ਘਟਾਇਆ ਜਾਵੇ, ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਕੀ ਇਸਨੂੰ ਹੁਣੇ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਜਾਂ ਕੀ ਇਹ ਅਜੇ ਵੀ ਡਰਾਉਣਾ ਨਹੀਂ ਹੈ
4. ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਵਿਨਾਸ਼ਕਾਰੀ ਪ੍ਰਭਾਵ. ਸਕੈਨਰ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਇੱਕ DoS ਹਮਲਾ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਇਕਾਈਆਂ ਬਣਾ ਸਕਦੇ ਹਨ ਜਾਂ ਮੌਜੂਦਾ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਬਲੌਗ 'ਤੇ ਹਜ਼ਾਰਾਂ ਟਿੱਪਣੀਆਂ ਬਣਾਓ), ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਬਿਨਾਂ ਸੋਚੇ ਸਮਝੇ ਇੱਕ ਸਕੈਨ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ।
5. ਕਮਜ਼ੋਰੀ ਦਾ ਪਤਾ ਲਗਾਉਣ ਦੀ ਘੱਟ ਗੁਣਵੱਤਾ। ਸਕੈਨਰ ਆਮ ਤੌਰ 'ਤੇ ਪੇਲੋਡਾਂ ਦੀ ਇੱਕ ਨਿਸ਼ਚਿਤ ਐਰੇ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਇੱਕ ਕਮਜ਼ੋਰੀ ਨੂੰ ਗੁਆ ਸਕਦੇ ਹਨ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਜਾਣੇ-ਪਛਾਣੇ ਵਿਵਹਾਰ ਦੇ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਬੈਠਦੀ ਹੈ।
6. ਸਕੈਨਰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਨਹੀਂ ਸਮਝਦਾ ਹੈ। ਸਕੈਨਰ ਖੁਦ ਨਹੀਂ ਜਾਣਦੇ ਕਿ "ਇੰਟਰਨੈੱਟ ਬੈਂਕਿੰਗ", "ਭੁਗਤਾਨ", "ਟਿੱਪਣੀ" ਕੀ ਹਨ। ਉਹਨਾਂ ਲਈ, ਇੱਥੇ ਸਿਰਫ ਲਿੰਕ ਅਤੇ ਮਾਪਦੰਡ ਹਨ, ਇਸਲਈ ਸੰਭਾਵਿਤ ਵਪਾਰਕ ਤਰਕ ਦੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਦੀ ਇੱਕ ਵੱਡੀ ਪਰਤ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੇਪਰਦ ਰਹਿੰਦੀ ਹੈ; ਉਹ ਡਬਲ ਰਾਈਟ-ਆਫ ਕਰਨ, ਆਈਡੀ ਦੁਆਰਾ ਕਿਸੇ ਹੋਰ ਦੇ ਡੇਟਾ ਦੀ ਜਾਸੂਸੀ ਕਰਨ, ਜਾਂ ਰਾਊਂਡਿੰਗ ਦੁਆਰਾ ਸੰਤੁਲਨ ਵਧਾਉਣ ਬਾਰੇ ਨਹੀਂ ਸੋਚਣਗੇ।
7. ਸਕੈਨਰ ਪੰਨਿਆਂ ਦੇ ਅਰਥਾਂ ਨੂੰ ਨਹੀਂ ਸਮਝਦਾ। ਸਕੈਨਰ ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲਾਂ ਨੂੰ ਨਹੀਂ ਪੜ੍ਹ ਸਕਦੇ, ਕੈਪਚਾਂ ਨੂੰ ਪਛਾਣ ਨਹੀਂ ਸਕਦੇ, ਅਤੇ ਉਹ ਆਪਣੇ ਆਪ ਇਹ ਨਹੀਂ ਸਮਝਣਗੇ ਕਿ ਕਿਵੇਂ ਰਜਿਸਟਰ ਕਰਨਾ ਹੈ ਅਤੇ ਫਿਰ ਦੁਬਾਰਾ ਲੌਗਇਨ ਕਰਨਾ ਹੈ, ਕਿ ਤੁਸੀਂ "ਲੌਗਆਊਟ" 'ਤੇ ਕਲਿੱਕ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਪੈਰਾਮੀਟਰ ਬਦਲਣ ਵੇਲੇ ਬੇਨਤੀਆਂ 'ਤੇ ਦਸਤਖਤ ਕਿਵੇਂ ਕਰਨੇ ਹਨ। ਮੁੱਲ। ਨਤੀਜੇ ਵਜੋਂ, ਜ਼ਿਆਦਾਤਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸਕੈਨ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਸਰੋਤ ਕੋਡ ਨੂੰ ਸਕੈਨ ਕਰਨ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ

1. ਝੂਠੇ ਸਕਾਰਾਤਮਕ. ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਇੱਕ ਗੁੰਝਲਦਾਰ ਕੰਮ ਹੈ ਜਿਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਵਪਾਰ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਸ਼ੁੱਧਤਾ ਨੂੰ ਅਕਸਰ ਕੁਰਬਾਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਮਹਿੰਗੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸਕੈਨਰ ਵੀ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਝੂਠੇ ਸਕਾਰਾਤਮਕ ਪੈਦਾ ਕਰਦੇ ਹਨ
2. ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ. ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਸ਼ੁੱਧਤਾ ਅਤੇ ਸੰਪੂਰਨਤਾ ਨੂੰ ਵਧਾਉਣ ਲਈ, ਸਕੈਨਿੰਗ ਨਿਯਮਾਂ ਨੂੰ ਸੁਧਾਰਨਾ ਜ਼ਰੂਰੀ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਨਿਯਮਾਂ ਨੂੰ ਲਿਖਣਾ ਬਹੁਤ ਮਿਹਨਤੀ ਹੋ ਸਕਦਾ ਹੈ। ਕਦੇ-ਕਦਾਈਂ ਕਿਸੇ ਕਿਸਮ ਦੇ ਬੱਗ ਵਾਲੇ ਕੋਡ ਵਿੱਚ ਸਾਰੀਆਂ ਥਾਵਾਂ ਨੂੰ ਲੱਭਣਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਠੀਕ ਕਰਨਾ ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਇੱਕ ਨਿਯਮ ਲਿਖਣ ਨਾਲੋਂ ਸੌਖਾ ਹੁੰਦਾ ਹੈ
3. ਨਿਰਭਰਤਾ ਸਹਾਇਤਾ ਦੀ ਘਾਟ. ਵੱਡੇ ਪ੍ਰੋਜੈਕਟ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਫਰੇਮਵਰਕ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਜੋ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਵਧਾਉਂਦੇ ਹਨ। ਜੇਕਰ ਸਕੈਨਰ ਦੇ ਗਿਆਨ ਅਧਾਰ ਵਿੱਚ ਇਹਨਾਂ ਫਰੇਮਵਰਕ ਵਿੱਚ "ਸਿੰਕਸ" ਬਾਰੇ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਅੰਨ੍ਹਾ ਸਥਾਨ ਬਣ ਜਾਵੇਗਾ ਅਤੇ ਸਕੈਨਰ ਕੋਡ ਨੂੰ ਵੀ ਨਹੀਂ ਸਮਝ ਸਕੇਗਾ।
4. ਸਕੈਨ ਦੀ ਮਿਆਦ। ਕੋਡ ਵਿੱਚ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਲੱਭਣਾ ਐਲਗੋਰਿਦਮ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਗੁੰਝਲਦਾਰ ਕੰਮ ਹੈ। ਇਸ ਲਈ, ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਲੰਬਾ ਸਮਾਂ ਲੱਗ ਸਕਦਾ ਹੈ ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਕੰਪਿਊਟਿੰਗ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
5. ਘੱਟ ਕਵਰੇਜ। ਸਰੋਤ ਦੀ ਖਪਤ ਅਤੇ ਸਕੈਨਿੰਗ ਸਮੇਂ ਦੇ ਬਾਵਜੂਦ, SAST ਟੂਲ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਅਜੇ ਵੀ ਸਮਝੌਤਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਸਾਰੇ ਰਾਜਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਨਹੀਂ ਕਰਨਾ ਪੈਂਦਾ ਜੋ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ
6. ਖੋਜਾਂ ਦੀ ਪ੍ਰਜਨਨਯੋਗਤਾ। ਖਾਸ ਲਾਈਨ ਅਤੇ ਕਾਲ ਸਟੈਕ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨਾ ਜੋ ਇੱਕ ਕਮਜ਼ੋਰੀ ਵੱਲ ਖੜਦਾ ਹੈ, ਪਰ ਅਸਲ ਵਿੱਚ, ਅਕਸਰ ਸਕੈਨਰ ਬਾਹਰੋਂ ਇੱਕ ਕਮਜ਼ੋਰੀ ਦੀ ਮੌਜੂਦਗੀ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਆਖ਼ਰਕਾਰ, ਨੁਕਸ ਡੈੱਡ ਕੋਡ ਵਿੱਚ ਵੀ ਹੋ ਸਕਦਾ ਹੈ, ਜੋ ਹਮਲਾਵਰ ਲਈ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੈ

ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸਕੈਨਿੰਗ ਸਮੱਸਿਆਵਾਂ

1. ਨਾਕਾਫ਼ੀ ਵਸਤੂ-ਸੂਚੀ। ਵੱਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ, ਖਾਸ ਤੌਰ 'ਤੇ ਭੂਗੋਲਿਕ ਤੌਰ 'ਤੇ ਵੱਖ ਕੀਤੇ ਗਏ, ਇਹ ਜਾਣਨਾ ਅਕਸਰ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਮੇਜ਼ਬਾਨਾਂ ਨੂੰ ਸਕੈਨ ਕਰਨਾ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਸਕੈਨਿੰਗ ਕਾਰਜ ਸੰਪਤੀ ਪ੍ਰਬੰਧਨ ਕਾਰਜ ਨਾਲ ਨੇੜਿਓਂ ਜੁੜਿਆ ਹੋਇਆ ਹੈ
2. ਮਾੜੀ ਤਰਜੀਹ। ਨੈੱਟਵਰਕ ਸਕੈਨਰ ਅਕਸਰ ਖਾਮੀਆਂ ਦੇ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਨਤੀਜੇ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਅਭਿਆਸ ਵਿੱਚ ਸ਼ੋਸ਼ਣ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਪਰ ਰਸਮੀ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਦਾ ਜੋਖਮ ਪੱਧਰ ਉੱਚਾ ਹੁੰਦਾ ਹੈ। ਖਪਤਕਾਰ ਨੂੰ ਇੱਕ ਰਿਪੋਰਟ ਪ੍ਰਾਪਤ ਹੁੰਦੀ ਹੈ ਜਿਸਦੀ ਵਿਆਖਿਆ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਅਸਪਸ਼ਟ ਹੈ ਕਿ ਪਹਿਲਾਂ ਕੀ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
3. ਮਾੜੀਆਂ ਸਿਫ਼ਾਰਸ਼ਾਂ। ਸਕੈਨਰ ਦੇ ਗਿਆਨ ਅਧਾਰ ਵਿੱਚ ਅਕਸਰ ਕਮਜ਼ੋਰੀ ਅਤੇ ਇਸਨੂੰ ਕਿਵੇਂ ਠੀਕ ਕਰਨਾ ਹੈ ਬਾਰੇ ਬਹੁਤ ਹੀ ਆਮ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ, ਇਸਲਈ ਪ੍ਰਸ਼ਾਸਕਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ਗੂਗਲ ਨਾਲ ਜੋੜਨਾ ਹੋਵੇਗਾ। ਵਾਈਟਬਾਕਸ ਸਕੈਨਰਾਂ ਨਾਲ ਸਥਿਤੀ ਥੋੜ੍ਹੀ ਬਿਹਤਰ ਹੈ, ਜੋ ਠੀਕ ਕਰਨ ਲਈ ਇੱਕ ਖਾਸ ਕਮਾਂਡ ਜਾਰੀ ਕਰ ਸਕਦੀ ਹੈ
4. ਹੱਥੀਂ ਬਣਾਇਆ। ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਨੋਡ ਹੋ ਸਕਦੇ ਹਨ, ਜਿਸਦਾ ਅਰਥ ਹੈ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਖਾਮੀਆਂ, ਰਿਪੋਰਟਾਂ ਨੂੰ ਪਾਰਸ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਹਰੇਕ ਦੁਹਰਾਅ 'ਤੇ ਹੱਥੀਂ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
5. ਮਾੜੀ ਕਵਰੇਜ। ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਸਕੈਨਿੰਗ ਦੀ ਗੁਣਵੱਤਾ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਕਮਜ਼ੋਰੀਆਂ ਅਤੇ ਸੌਫਟਵੇਅਰ ਸੰਸਕਰਣਾਂ ਬਾਰੇ ਗਿਆਨ ਅਧਾਰ ਦੇ ਆਕਾਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਜਿਸ ਵਿੱਚ, ਤਬਦੀਲ ਹੋਣਾ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਮਾਰਕੀਟ ਲੀਡਰਾਂ ਕੋਲ ਇੱਕ ਵਿਆਪਕ ਗਿਆਨ ਅਧਾਰ ਨਹੀਂ ਹੈ, ਅਤੇ ਮੁਫਤ ਹੱਲਾਂ ਦੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ ਜੋ ਲੀਡਰਾਂ ਕੋਲ ਨਹੀਂ ਹੁੰਦੀ ਹੈ।
6. ਪੈਚਿੰਗ ਨਾਲ ਸਮੱਸਿਆਵਾਂ। ਬਹੁਤੇ ਅਕਸਰ, ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਪੈਚ ਕਰਨ ਵਿੱਚ ਇੱਕ ਪੈਕੇਜ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਜਾਂ ਇੱਕ ਸੰਰਚਨਾ ਫਾਈਲ ਨੂੰ ਬਦਲਣਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। ਇੱਥੇ ਵੱਡੀ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਇੱਕ ਸਿਸਟਮ, ਖਾਸ ਤੌਰ 'ਤੇ ਇੱਕ ਵਿਰਾਸਤ, ਇੱਕ ਅੱਪਡੇਟ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਅਚਾਨਕ ਵਿਵਹਾਰ ਕਰ ਸਕਦਾ ਹੈ। ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ, ਤੁਹਾਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਲਾਈਵ ਬੁਨਿਆਦੀ ਢਾਂਚੇ 'ਤੇ ਏਕੀਕਰਣ ਟੈਸਟ ਕਰਵਾਉਣੇ ਪੈਣਗੇ।

ਪਹੁੰਚ

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

1. ਵੱਖ-ਵੱਖ ਸਕੈਨਿੰਗ ਸਾਧਨਾਂ ਦਾ ਏਕੀਕਰਣ। ਕਈ ਸਕੈਨਰਾਂ ਦੀ ਸਹੀ ਵਰਤੋਂ ਨਾਲ, ਤੁਸੀਂ ਗਿਆਨ ਅਧਾਰ ਅਤੇ ਖੋਜ ਦੀ ਗੁਣਵੱਤਾ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਵਾਧਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਲਾਂਚ ਕੀਤੇ ਗਏ ਸਾਰੇ ਸਕੈਨਰਾਂ ਦੀ ਕੁੱਲ ਗਿਣਤੀ ਨਾਲੋਂ ਵੀ ਜ਼ਿਆਦਾ ਕਮਜ਼ੋਰੀਆਂ ਲੱਭ ਸਕਦੇ ਹੋ, ਜਦੋਂ ਕਿ ਤੁਸੀਂ ਜੋਖਮ ਦੇ ਪੱਧਰ ਦਾ ਵਧੇਰੇ ਸਹੀ ਮੁਲਾਂਕਣ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਹੋਰ ਸਿਫ਼ਾਰਸ਼ਾਂ ਕਰ ਸਕਦੇ ਹੋ
2. SAST ਅਤੇ DAST ਦਾ ਏਕੀਕਰਣ। DAST ਦੀ ਕਵਰੇਜ ਅਤੇ SAST ਦੀ ਸ਼ੁੱਧਤਾ ਨੂੰ ਉਹਨਾਂ ਵਿਚਕਾਰ ਜਾਣਕਾਰੀ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਕੇ ਵਧਾਉਣਾ ਸੰਭਵ ਹੈ। ਸਰੋਤਾਂ ਤੋਂ ਤੁਸੀਂ ਮੌਜੂਦਾ ਰੂਟਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ DAST ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੁਸੀਂ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਕਮਜ਼ੋਰੀ ਬਾਹਰੋਂ ਦਿਖਾਈ ਦੇ ਰਹੀ ਹੈ।
3. ਮਸ਼ੀਨ ਲਰਨਿੰਗ™। 2015 ਵਿੱਚ ਆਈ ਦੱਸਿਆ (ਅਤੇ ਹੋਰਸਕੈਨਰਾਂ ਨੂੰ ਹੈਕਰ ਦੀ ਸੂਝ ਦੇਣ ਅਤੇ ਉਹਨਾਂ ਦੀ ਗਤੀ ਵਧਾਉਣ ਲਈ ਅੰਕੜਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਬਾਰੇ। ਇਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਭਵਿੱਖ ਵਿੱਚ ਸਵੈਚਲਿਤ ਸੁਰੱਖਿਆ ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਵਿਕਾਸ ਲਈ ਚਾਰਾ ਹੈ।
4. ਆਟੋਟੈਸਟ ਅਤੇ OpenAPI ਨਾਲ IAST ਦਾ ਏਕੀਕਰਣ। CI/CD ਪਾਈਪਲਾਈਨ ਦੇ ਅੰਦਰ, HTTP ਉੱਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਇੱਕ HTTP ਪ੍ਰੌਕਸੀ ਅਤੇ ਫੰਕਸ਼ਨਲ ਟੈਸਟਾਂ ਦੇ ਤੌਰ ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਟੂਲਸ ਦੇ ਅਧਾਰ ਤੇ ਇੱਕ ਸਕੈਨਿੰਗ ਪ੍ਰਕਿਰਿਆ ਬਣਾਉਣਾ ਸੰਭਵ ਹੈ। OpenAPI/Swagger ਟੈਸਟ ਅਤੇ ਇਕਰਾਰਨਾਮੇ ਸਕੈਨਰ ਨੂੰ ਡੇਟਾ ਦੇ ਪ੍ਰਵਾਹ ਬਾਰੇ ਗੁੰਮ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਨਗੇ ਅਤੇ ਵੱਖ-ਵੱਖ ਰਾਜਾਂ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਕੈਨ ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਣਗੇ।
5. ਸਹੀ ਸੰਰਚਨਾ. ਹਰੇਕ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ, ਤੁਹਾਨੂੰ ਇੰਟਰਫੇਸ ਦੀ ਸੰਖਿਆ ਅਤੇ ਪ੍ਰਕਿਰਤੀ ਅਤੇ ਵਰਤੀਆਂ ਗਈਆਂ ਤਕਨਾਲੋਜੀਆਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਇੱਕ ਢੁਕਵੀਂ ਸਕੈਨਿੰਗ ਪ੍ਰੋਫਾਈਲ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ।
6. ਸਕੈਨਰ ਅਨੁਕੂਲਤਾ. ਅਕਸਰ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਕੈਨਰ ਨੂੰ ਸੋਧੇ ਬਿਨਾਂ ਸਕੈਨ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਇੱਕ ਉਦਾਹਰਨ ਇੱਕ ਭੁਗਤਾਨ ਗੇਟਵੇ ਹੈ ਜਿਸ ਵਿੱਚ ਹਰੇਕ ਬੇਨਤੀ 'ਤੇ ਦਸਤਖਤ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਗੇਟਵੇ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਇੱਕ ਕਨੈਕਟਰ ਨੂੰ ਲਿਖੇ ਬਿਨਾਂ, ਸਕੈਨਰ ਗਲਤ ਦਸਤਖਤ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਨਾਲ ਬੇਝਿਜਕ ਬੰਬਾਰੀ ਕਰਨਗੇ। ਕਿਸੇ ਖਾਸ ਕਿਸਮ ਦੇ ਨੁਕਸ ਲਈ ਵਿਸ਼ੇਸ਼ ਸਕੈਨਰ ਲਿਖਣਾ ਵੀ ਜ਼ਰੂਰੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਅਸੁਰੱਖਿਅਤ ਡਾਇਰੈਕਟ ਆਬਜੈਕਟ ਹਵਾਲਾ
7. ਖਤਰੇ ਨੂੰ ਪ੍ਰਬੰਧਨ. ਵੱਖ-ਵੱਖ ਸਕੈਨਰਾਂ ਦੀ ਵਰਤੋਂ ਅਤੇ ਬਾਹਰੀ ਪ੍ਰਣਾਲੀਆਂ ਜਿਵੇਂ ਕਿ ਸੰਪੱਤੀ ਪ੍ਰਬੰਧਨ ਅਤੇ ਧਮਕੀ ਪ੍ਰਬੰਧਨ ਨਾਲ ਏਕੀਕਰਣ ਜੋਖਮ ਦੇ ਪੱਧਰ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੇ ਮਾਪਦੰਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ, ਤਾਂ ਜੋ ਪ੍ਰਬੰਧਨ ਵਿਕਾਸ ਜਾਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਮੌਜੂਦਾ ਸੁਰੱਖਿਆ ਸਥਿਤੀ ਦੀ ਇੱਕ ਢੁਕਵੀਂ ਤਸਵੀਰ ਪ੍ਰਾਪਤ ਕਰ ਸਕੇ।

ਜੁੜੇ ਰਹੋ ਅਤੇ ਆਓ ਕਮਜ਼ੋਰੀ ਸਕੈਨਿੰਗ ਵਿੱਚ ਵਿਘਨ ਪਾਈਏ!

ਸਰੋਤ: www.habr.com