ਦਹਾਕਿਆਂ ਤੋਂ, static application security testing (SAST) ਉਹਨਾਂ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਰਿਹਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨਾਲ ਸੁਰੱਖਿਆ ਟੀਮਾਂ ਕੋਡ ਸਮੀਖਿਆ ਨੂੰ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਕਰ ਸਕਦੀਆਂ ਹਨ.
ਪਰ ਜਦੋਂ ਅਸੀਂ Codex Security ਬਣਾਇਆ, ਅਸੀਂ ਸੋਚ-ਸਮਝ ਕੇ ਇੱਕ ਡਿਜ਼ਾਈਨ ਚੋਣ ਕੀਤੀ: ਅਸੀਂ static analysis ਰਿਪੋਰਟ ਇੰਪੋਰਟ ਕਰਕੇ ਅਤੇ ਏਜੰਟ ਨੂੰ ਉਸ ਦੀ triage ਕਰਨ ਲਈ ਕਹਿ ਕੇ ਸ਼ੁਰੂਆਤ ਨਹੀਂ ਕੀਤੀ. ਅਸੀਂ ਸਿਸਟਮ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਕਿ ਉਹ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਹੀ ਸ਼ੁਰੂ ਕਰੇ—ਇਸ ਦੀ ਆਰਕੀਟੈਕਚਰ, trust boundaries, ਅਤੇ ਮਨਚਾਹੇ ਵਿਹਾਰ ਤੋਂ—ਅਤੇ ਜੋ ਕੁਝ ਇਹ ਲੱਭੇ, ਉਸ 'ਤੇ ਕਿਸੇ ਮਨੁੱਖ ਦਾ ਸਮਾਂ ਲੱਗਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਨੂੰ validate ਕਰੇ.
ਇਸ ਦਾ ਕਾਰਨ ਸਧਾਰਨ ਹੈ: ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਕਮਜ਼ੋਰੀਆਂ ਆਮ ਤੌਰ 'ਤੇ dataflow ਸਮੱਸਿਆਵਾਂ ਨਹੀਂ ਹੁੰਦੀਆਂ. ਉਹ ਤਦ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਕੋਡ ਐਸਾ ਲੱਗਦਾ ਹੈ ਕਿ ਉਹ ਸੁਰੱਖਿਆ ਜਾਂਚ ਲਾਗੂ ਕਰ ਰਿਹਾ ਹੈ, ਪਰ ਅਸਲ ਵਿੱਚ ਉਹ ਜਾਂਚ ਉਸ ਗੁਣ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੀ ਜਿਸ 'ਤੇ ਸਿਸਟਮ ਨਿਰਭਰ ਕਰਦਾ ਹੈ. ਹੋਰ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਚੁਣੌਤੀ ਸਿਰਫ਼ ਇਹ ਟ੍ਰੈਕ ਕਰਨ ਦੀ ਨਹੀਂ ਕਿ ਡਾਟਾ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਕਿਵੇਂ ਗੁਜ਼ਰਦਾ ਹੈ—ਇਹ ਵੀ ਤੈਅ ਕਰਨਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕੋਡ ਵਿੱਚ ਲੱਗੀਆਂ ਰੱਖਿਆਵਾਂ ਵਾਸਤਵ ਵਿੱਚ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਜਾਂ ਨਹੀਂ.
SAST ਨੂੰ ਅਕਸਰ ਇੱਕ ਸੁਚੱਜੀ pipeline ਵਜੋਂ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ: ਬੇਭਰੋਸੇਯੋਗ input ਦਾ source ਪਛਾਣੋ, ਡਾਟੇ ਨੂੰ ਪ੍ਰੋਗਰਾਮ ਵਿਚ ਟ੍ਰੈਕ ਕਰੋ, ਅਤੇ ਉਹ ਮਾਮਲੇ flag ਕਰੋ ਜਿੱਥੇ ਉਹ ਡਾਟਾ ਬਿਨਾਂ sanitization ਦੇ ਕਿਸੇ sensitive sink ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ. ਇਹ ਇੱਕ ਸੁੰਦਰ ਮਾਡਲ ਹੈ, ਅਤੇ ਇਹ ਕਈ ਅਸਲੀ bugs ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ.
ਅਮਲ ਵਿੱਚ, ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਕੰਮਯੋਗ ਰਹਿਣ ਲਈ SAST ਨੂੰ ਅਨੁਮਾਨ ਲਗਾਉਣੇ ਪੈਂਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਅਸਲੀ codebases ਵਿੱਚ ਜਿੱਥੇ indirection, dynamic dispatch, callbacks, reflection, ਅਤੇ framework-heavy control flow ਹੁੰਦੇ ਹਨ. ਇਹ ਅਨੁਮਾਨ SAST ਦੀ ਕਮੀ ਨਹੀਂ ਹਨ; ਇਹ ਉਸ ਹਕੀਕਤ ਦਾ ਹਿੱਸਾ ਹਨ ਜਿੱਥੇ ਕੋਡ ਨੂੰ ਚਲਾਏ ਬਿਨਾਂ ਉਸ ਬਾਰੇ ਰੀਜ਼ਨਿੰਗ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ.
ਇਹ ਆਪਣੇ ਆਪ ਵਿੱਚ ਉਹ ਕਾਰਨ ਨਹੀਂ ਹੈ ਕਿ Codex Security SAST ਰਿਪੋਰਟ ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦਾ.
ਅਸਲ ਵਿੱਚ ਹੋਰ ਡੂੰਘਾ ਮੁੱਦਾ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਤੁਸੀਂ source ਤੋਂ sink ਤੱਕ ਸਫਲਤਾਪੂਰਵਕ trace ਕਰ ਲੈਂਦੇ ਹੋ, ਉਸ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ.
ਭਾਵੇਂ static analysis ਕਈ functions ਅਤੇ layers ਰਾਹੀਂ input ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ trace ਕਰ ਲਏ, ਫਿਰ ਵੀ ਉਸ ਨੂੰ ਉਹ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਪੈਂਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਮਜ਼ੋਰੀ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ:
ਇੱਕ ਆਮ pattern ਲਓ: ਕੋਡ ਬੇਭਰੋਸੇਯੋਗ ਸਮੱਗਰੀ render ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ sanitize_html() ਵਰਗਾ ਕੁਝ ਕਾਲ ਕਰਦਾ ਹੈ. ਇੱਕ static analyzer ਇਹ ਵੇਖ ਸਕਦਾ ਹੈ ਕਿ sanitizer ਚੱਲਿਆ ਸੀ. ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਇਹ ਨਹੀਂ ਤੈਅ ਕਰ ਸਕਦਾ ਕਿ ਕੀ ਉਹ sanitizer ਅਸਲ ਵਿੱਚ ਖ਼ਾਸ rendering context, template engine, encoding ਵਿਹਾਰ, ਅਤੇ ਸ਼ਾਮਲ downstream transformations ਲਈ ਕਾਫ਼ੀ ਹੈ ਜਾਂ ਨਹੀਂ.
ਇਥੇ ਹੀ ਗੱਲ ਜਟਿਲ ਬਣਦੀ ਹੈ. ਸਮੱਸਿਆ ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਕਿ ਡਾਟਾ sink ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਜਾਂ ਨਹੀਂ. ਗੱਲ ਇਹ ਹੈ ਕਿ ਕੀ ਕੋਡ ਦੀਆਂ ਜਾਂਚਾਂ ਵਾਸਤਵ ਵਿੱਚ ਮੁੱਲ ਨੂੰ ਉਸ ਤਰੀਕੇ ਨਾਲ ਸੀਮਿਤ ਕਰਦੀਆਂ ਹਨ ਜਿਵੇਂ ਸਿਸਟਮ ਮੰਨਦਾ ਹੈ ਕਿ ਉਹ ਕਰਦੀਆਂ ਹਨ.
ਹੋਰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਕਹੀਏ: “ਕੋਡ ਇੱਕ sanitizer ਕਾਲ ਕਰਦਾ ਹੈ” ਅਤੇ “ਸਿਸਟਮ ਸੁਰੱਖਿਅਤ ਹੈ.” ਵਿੱਚ ਵੱਡਾ ਫਰਕ ਹੈ.
ਇਹ ਇੱਕ pattern ਹੈ ਜੋ ਅਸਲੀ ਸਿਸਟਮਾਂ ਵਿੱਚ ਬਾਰੰਬਾਰ ਵੇਖਣ ਨੂੰ ਮਿਲਦਾ ਹੈ.
ਇੱਕ web application ਇੱਕ JSON payload ਲੈਂਦੀ ਹੈ, ਉਸ ਵਿਚੋਂ redirect_url ਕੱਢਦੀ ਹੈ, ਉਸ ਨੂੰ allowlist regex ਦੇ ਮੁਕਾਬਲੇ validate ਕਰਦੀ ਹੈ, ਉਸ ਦਾ URL-decode ਕਰਦੀ ਹੈ, ਅਤੇ ਨਤੀਜਾ redirect handler ਨੂੰ ਭੇਜਦੀ ਹੈ.
ਇੱਕ ਕਲਾਸਿਕ source-to-sink ਰਿਪੋਰਟ ਇਸ flow ਦਾ ਵਰਣਨ ਕਰ ਸਕਦੀ ਹੈ:
untrusted input → regex check → URL decode → redirect
ਪਰ ਅਸਲੀ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ ਜਾਂਚ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ. ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕੀ ਅਗਲੇ transformations ਤੋਂ ਬਾਅਦ ਵੀ ਉਹ ਜਾਂਚ ਮੁੱਲ ਨੂੰ ਸੀਮਿਤ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ.
ਜੇ regex decoding ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਕੀ ਉਹ ਵਾਕਈ decoded URL ਨੂੰ ਉਸ ਤਰੀਕੇ ਨਾਲ ਸੀਮਿਤ ਕਰਦਾ ਹੈ ਜਿਵੇਂ redirect handler ਉਸ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ?
ਇਸ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਪੂਰੀ transformation chain ਬਾਰੇ ਰੀਜ਼ਨਿੰਗ ਕਰਨੀ ਪੈਂਦੀ ਹੈ: regex ਕੀ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, decoding ਅਤੇ normalization ਕਿਵੇਂ ਵਰਤਾਓ ਕਰਦੇ ਹਨ, URL parsing edge cases ਨਾਲ ਕਿਵੇਂ ਨਿਪਟਦੀ ਹੈ, ਅਤੇ redirect logic schemes ਅਤੇ authorities ਨੂੰ ਕਿਵੇਂ resolve ਕਰਦੀ ਹੈ.
ਅਮਲ ਵਿੱਚ ਮਹੱਤਵਪੂਰਣ ਕਈ ਕਮਜ਼ੋਰੀਆਂ ਇਸੇ ਤਰ੍ਹਾਂ ਦੀਆਂ ਦਿਖਦੀਆਂ ਹਨ: operations ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਗਲਤੀਆਂ, ਅਧੂਰਾ normalization, parsing ambiguities, ਅਤੇ validation ਅਤੇ interpretation ਵਿਚਕਾਰ ਅਣਮੈਲ. Dataflow ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ. ਕਮਜ਼ੋਰੀ ਇਸ ਵਿੱਚ ਹੁੰਦੀ ਹੈ ਕਿ transformation chain ਰਾਹੀਂ ਪਾਬੰਦੀਆਂ ਕਿਵੇਂ ਅੱਗੇ ਵਧਦੀਆਂ ਹਨ—ਜਾਂ ਨਹੀਂ ਵਧਦੀਆਂ.
ਇਹ ਸਿਰਫ਼ ਸਿਧਾਂਤਕ pattern ਨਹੀਂ ਹੈ. CVE-2024-29041(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਵਿੱਚ, Express ਇੱਕ open redirect ਸਮੱਸਿਆ ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਹੋਇਆ ਸੀ ਜਿੱਥੇ malformed URLs, redirect targets ਨੂੰ encode ਅਤੇ ਫਿਰ interpret ਕਰਨ ਦੇ ਤਰੀਕੇ ਕਰਕੇ, ਆਮ allowlist implementations ਨੂੰ bypass ਕਰ ਸਕਦੇ ਸਨ. Dataflow ਸਿੱਧਾ ਸੀ. ਔਖਾ ਸਵਾਲ—ਅਤੇ ਉਹੀ ਜਿਸ ਨੇ ਤੈਅ ਕੀਤਾ ਕਿ bug ਮੌਜੂਦ ਸੀ ਜਾਂ ਨਹੀਂ—ਇਹ ਸੀ ਕਿ transformation chain ਤੋਂ ਬਾਅਦ ਵੀ validation ਕਾਇਮ ਰਹਿੰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ.
Codex Security ਇੱਕ ਸਧਾਰਨ ਲਕਸ਼ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਾਇਆ ਗਿਆ ਹੈ: ਵਧੇਰੇ ਮਜ਼ਬੂਤ ਸਬੂਤਾਂ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਸਾਹਮਣੇ ਲਿਆ ਕੇ triage ਘਟਾਉਣਾ. ਪ੍ਰੋਡਕਟ ਵਿੱਚ, ਇਸ ਦਾ ਅਰਥ ਹੈ repo-specific context (ਜਿਸ ਵਿੱਚ threat model ਵੀ ਸ਼ਾਮਲ ਹੈ) ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਅਤੇ high-signal issues ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਕ ਅਲੱਗ environment ਵਿੱਚ validate ਕਰਨਾ.
ਜਦੋਂ Codex Security ਨੂੰ ਕੋਈ ਐਸੀ boundary ਮਿਲਦੀ ਹੈ ਜੋ “validation” ਜਾਂ “sanitization” ਵਰਗੀ ਲੱਗਦੀ ਹੈ, ਤਾਂ ਉਹ ਇਸ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ checkbox ਵਜੋਂ ਨਹੀਂ ਵੇਖਦਾ. ਉਹ ਸਮਝਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਕਿ ਕੋਡ ਕਿਸ ਗਾਰੰਟੀ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੁੰਦਾ ਹੈ—ਅਤੇ ਫਿਰ ਉਹ ਉਸ ਗਾਰੰਟੀ ਨੂੰ ਗਲਤ ਸਾਬਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ.
ਅਮਲ ਵਿੱਚ, ਇਹ ਅਕਸਰ ਇਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਦੇ ਮਿਲੇ-ਜੁਲੇ ਰੂਪ ਵਾਂਗ ਲੱਗਦਾ ਹੈ:
- ਪੂਰੇ ਰਿਪੋਜ਼ਟਰੀ context ਨਾਲ ਸੰਬੰਧਿਤ code path ਪੜ੍ਹਨਾ, ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਜਿਵੇਂ ਕੋਈ security researcher ਪੜ੍ਹੇਗਾ, ਅਤੇ ਮਨਸ਼ਾ ਅਤੇ implementation ਵਿਚਕਾਰ ਅਣਮੈਲ ਲੱਭਣਾ. ਇਸ ਵਿੱਚ comments ਵੀ ਸ਼ਾਮਲ ਹਨ, ਪਰ ਮਾਡਲ ਲਾਜ਼ਮੀ ਨਹੀਂ ਕਿ comments 'ਤੇ ਵਿਸ਼ਵਾਸ ਕਰੇ, ਇਸ ਲਈ ਆਪਣੇ ਕੋਡ ਦੇ ਉੱਪਰ //Halvar says: this is not a bug ਲਿਖ ਦੇਣ ਨਾਲ, ਜੇ ਅਸਲ ਵਿੱਚ bug ਹੈ, ਤਾਂ ਇਹ ਗੁੰਝਲ ਵਿੱਚ ਨਹੀਂ ਪੈਂਦਾ.
- ਸਮੱਸਿਆ ਨੂੰ ਸਭ ਤੋਂ ਛੋਟੀ testable slice ਤੱਕ ਘਟਾਉਣਾ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ input ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀ transformation pipeline), ਤਾਂ ਜੋ ਤੁਸੀਂ ਬਾਕੀ ਸਿਸਟਮ ਦੀ ਰੁਕਾਵਟ ਤੋਂ ਬਿਨਾਂ ਉਸ ਬਾਰੇ ਰੀਜ਼ਨਿੰਗ ਕਰ ਸਕੋ. ਇਸ ਮਾਇਨੇ ਵਿੱਚ, Codex Security ਛੋਟੀਆਂ code slices ਕੱਢਦਾ ਹੈ ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਲਈ micro-fuzzers ਲਿਖਦਾ ਹੈ.
- ਹਰ ਜਾਂਚ ਨੂੰ ਅਲੱਗ-ਅਲੱਗ ਦੇਖਣ ਦੀ ਬਜਾਏ transformations ਰਾਹੀਂ ਪਾਬੰਦੀਆਂ ਬਾਰੇ ਰੀਜ਼ਨਿੰਗ ਕਰਨੀ. ਜਿੱਥੇ ਉਚਿਤ ਹੋਵੇ, ਇਸ ਵਿੱਚ satisfiability question ਵਜੋਂ formalization ਵੀ ਸ਼ਾਮਲ ਹੋ ਸਕਦੀ ਹੈ. ਹੋਰ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਅਸੀਂ ਮਾਡਲ ਨੂੰ z3-solver ਵਾਲੇ Python environment ਤੱਕ ਪਹੁੰਚ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਲੋੜ ਪੈਣ 'ਤੇ ਉਹ ਇਸ ਦਾ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ ਉਪਯੋਗ ਕਰਦਾ ਹੈ, ਬਿਲਕੁਲ ਉਹੋ ਜਿਹਾ ਜਿਵੇਂ ਕੋਈ ਮਨੁੱਖ ਕਿਸੇ ਖ਼ਾਸੇ ਜਟਿਲ input constraint ਸਮੱਸਿਆ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਸਮੇਂ ਕਰੇਗਾ. ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ non-standard architectures 'ਤੇ integer overflows ਜਾਂ ਇਸ ਵਰਗੀਆਂ bugs ਦੀ ਜਾਂਚ ਲਈ ਲਾਭਦਾਇਕ ਹੈ.
- ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, hypotheses ਨੂੰ sandboxed validation environment ਵਿੱਚ ਚਲਾਉਣਾ, ਤਾਂ ਜੋ “ਇਹ ਸਮੱਸਿਆ ਹੋ ਸਕਦੀ ਹੈ” ਅਤੇ “ਇਹ ਸਮੱਸਿਆ ਹੈ” ਵਿਚਕਾਰ ਫ਼ਰਕ ਕੀਤਾ ਜਾ ਸਕੇ. Debug mode ਵਿੱਚ compile ਕੀਤੇ ਕੋਡ ਨਾਲ ਪੂਰਾ end-to-end PoC ਤੋਂ ਵਧੀਆ ਸਬੂਤ ਕੋਈ ਨਹੀਂ ਹੈ.
ਇਹੀ ਮੁੱਖ ਬਦਲਾਅ ਹੈ: “ਇੱਕ ਜਾਂਚ ਮੌਜੂਦ ਹੈ” 'ਤੇ ਰੁਕਣ ਦੀ ਬਜਾਏ, ਸਿਸਟਮ “invariant ਕਾਇਮ ਹੈ (ਜਾਂ ਨਹੀਂ), ਅਤੇ ਇਹ ਰਹੇ ਸਬੂਤ” ਵੱਲ ਧੱਕਦਾ ਹੈ. ਅਤੇ ਮਾਡਲ ਉਸ ਕੰਮ ਲਈ ਸਭ ਤੋਂ ਉਚਿਤ tool ਚੁਣਦਾ ਹੈ.
ਇੱਕ ਵਾਜਬ ਪ੍ਰਤੀਕਿਰਿਆ ਇਹ ਹੈ: ਦੋਵੇਂ ਕਿਉਂ ਨਹੀਂ? SAST ਰਿਪੋਰਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਏਜੰਟ ਨੂੰ ਹੋਰ ਡੂੰਘੀ ਰੀਜ਼ਨਿੰਗ ਕਰਨ ਦਿਓ.
ਕੁਝ ਐਸੇ ਮਾਮਲੇ ਹਨ ਜਿੱਥੇ ਪਹਿਲਾਂ ਤੋਂ ਗਿਣੇ findings ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਸਿਮਟੇ ਹੋਏ, ਜਾਣੇ-ਪਛਾਣੇ bug classes ਲਈ. ਪਰ ਜਦੋਂ ਕੋਈ ਏਜੰਟ context ਵਿੱਚ ਕਮਜ਼ੋਰੀਆਂ ਖੋਜਣ ਅਤੇ validate ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੋਵੇ, ਤਾਂ SAST ਰਿਪੋਰਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨਾ ਤਿੰਨ ਅਨੁਮਾਨਿਤ ਨਾਕਾਮੀ ਮੋਡ ਪੈਦਾ ਕਰਦਾ ਹੈ.
ਪਹਿਲਾਂ, ਇਹ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਘੇਰਾ ਸਿਮਟਾਉਣ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕਰ ਸਕਦਾ ਹੈ. Findings ਦੀ ਸੂਚੀ ਉਹ ਨਕਸ਼ਾ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਕੋਈ tool ਪਹਿਲਾਂ ਹੀ ਦੇਖ ਚੁੱਕਾ ਹੈ. ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਮੰਨ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਿਸਟਮ ਨੂੰ ਉਸੇ ਖੇਤਰਾਂ ਵਿੱਚ, ਉਸੇ abstractions ਨਾਲ, ਅਸਮਾਨੁਪਾਤਿਕ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵੱਲ ਝੁਕਾ ਸਕਦੇ ਹੋ, ਅਤੇ ਉਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਦੀਆਂ ਕਿਸਮਾਂ ਖੋ ਸਕਦੇ ਹੋ ਜੋ tool ਦੀ worldview ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਬੈਠਦੀਆਂ.
ਦੂਜਾ, ਇਹ ਐਸੇ ਅਪਰੋક્ષ ਫ਼ੈਸਲੇ ਲਿਆ ਸਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮੁੜ ਖੋਲ੍ਹਣਾ ਔਖਾ ਹੁੰਦਾ ਹੈ. ਕਈ SAST findings sanitization, validation, ਜਾਂ trust boundaries ਬਾਰੇ ਧਾਰਣਾਵਾਂ ਨੂੰ encode ਕਰਦੇ ਹਨ. ਜੇ ਉਹ ਧਾਰਣਾਵਾਂ ਗਲਤ ਹਨ—ਜਾਂ ਸਿਰਫ਼ ਅਧੂਰੀਆਂ—ਤਾਂ reasoning loop ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਏਜੰਟ ਨੂੰ “ਜਾਂਚ ਕਰੋ” ਤੋਂ “ਪੁਸ਼ਟੀ ਕਰੋ ਜਾਂ ਰੱਦ ਕਰੋ” ਵੱਲ ਧੱਕ ਸਕਦਾ ਹੈ, ਜੋ ਅਸੀਂ ਏਜੰਟ ਤੋਂ ਨਹੀਂ ਚਾਹੁੰਦੇ.
ਤੀਜਾ, ਇਹ reasoning system ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ ਹੋਰ ਮੁਸ਼ਕਲ ਬਣਾ ਸਕਦਾ ਹੈ. ਜੇ pipeline ਦੀ ਸ਼ੁਰੂਆਤ SAST output ਨਾਲ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਵੱਖ ਕਰਨਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਏਜੰਟ ਨੇ ਆਪਣੀ ਵਿਸ਼ਲੇਸ਼ਣ ਨਾਲ ਕੀ ਲੱਭਿਆ ਅਤੇ ਕਿਸੇ ਹੋਰ tool ਤੋਂ ਕੀ ਵਾਰਸਤ ਵਿੱਚ ਲਿਆ. ਜੇ ਤੁਸੀਂ ਸਿਸਟਮ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਸਹੀ ਤੌਰ 'ਤੇ ਮਾਪਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਵੱਖਰਾ ਕਰਨਾ ਮਹੱਤਵਪੂਰਣ ਹੈ, ਕਿਉਂਕਿ ਸਮੇਂ ਦੇ ਨਾਲ ਸਿਸਟਮ ਵਿੱਚ ਸੁਧਾਰ ਲਈ ਇਹ ਲਾਜ਼ਮੀ ਹੈ.
ਇਸ ਲਈ ਅਸੀਂ Codex Security ਨੂੰ ਉੱਥੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਬਣਾਇਆ ਜਿੱਥੇ security research ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ: ਕੋਡ ਅਤੇ ਸਿਸਟਮ ਦੀ ਮਨਸ਼ਾ ਤੋਂ, ਅਤੇ ਮਨੁੱਖ ਨੂੰ ਵਿਘਨ ਪਾਉਣ ਤੋਂ ਪਹਿਲਾਂ confidence bar ਵਧਾਉਣ ਲਈ validation ਦੀ ਵਰਤੋਂ ਨਾਲ.
SAST tools ਉਹ ਕੰਮ ਬੇਹੱਦ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰ ਸਕਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਲਈ ਉਹ ਬਣਾਏ ਗਏ ਹਨ: ਸੁਰੱਖਿਅਤ coding standards ਲਾਗੂ ਕਰਨਾ, ਸਧਾਰਣ source-to-sink ਸਮੱਸਿਆਵਾਂ ਫੜਨਾ, ਅਤੇ ਅੰਦਾਜ਼ੇਯੋਗ tradeoffs ਨਾਲ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਜਾਣੇ-ਪਛਾਣੇ patterns ਦੀ ਪਹਿਚਾਣ ਕਰਨਾ. ਇਹ defense-in-depth ਦਾ ਮਜ਼ਬੂਤ ਹਿੱਸਾ ਹੋ ਸਕਦੇ ਹਨ.
ਇਹ ਪੋਸਟ ਹੋਰ ਸਿਮਟੀ ਹੋਈ ਗੱਲ ਕਰਦੀ ਹੈ: ਇਹ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਵਿਹਾਰ ਬਾਰੇ ਰੀਜ਼ਨਿੰਗ ਕਰਨ ਅਤੇ findings ਨੂੰ validate ਕਰਨ ਲਈ ਬਣੇ ਇੱਕ ਏਜੰਟ ਨੂੰ ਆਪਣਾ ਕੰਮ static findings list ਨਾਲ anchored ਕਰਕੇ ਕਿਉਂ ਨਹੀਂ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ.
ਇਹ pure source-to-sink thinking ਦੀ ਇੱਕ ਸੰਬੰਧਿਤ ਸੀਮਾ ਨੂੰ ਵੀ ਰੋਸ਼ਨ ਕਰਦਾ ਹੈ: ਹਰ ਕਮਜ਼ੋਰੀ dataflow ਸਮੱਸਿਆ ਨਹੀਂ ਹੁੰਦੀ. ਕਈ ਅਸਲੀ ਨਾਕਾਮੀਆਂ state ਅਤੇ invariant ਸਮੱਸਿਆਵਾਂ ਹੁੰਦੀਆਂ ਹਨ—workflow bypasses, authorization gaps, ਅਤੇ “ਸਿਸਟਮ ਗਲਤ state ਵਿੱਚ ਹੈ” ਕਿਸਮ ਦੀਆਂ bugs. ਇਸ ਕਿਸਮ ਦੀਆਂ bugs ਵਿੱਚ, ਕੋਈ tainted value ਕਿਸੇ ਇੱਕ “dangerous sink” ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੀ. ਜੋਖ਼ਮ ਉਸ ਵਿੱਚ ਹੁੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਪ੍ਰੋਗਰਾਮ ਹਮੇਸ਼ਾਂ ਸੱਚ ਮੰਨ ਕੇ ਚਲਦਾ ਹੈ.
ਸਾਨੂੰ ਉਮੀਦ ਹੈ ਕਿ security tooling ecosystem ਲਗਾਤਾਰ ਸੁਧਰਦਾ ਰਹੇਗਾ: static analysis, fuzzing, runtime guards, ਅਤੇ agentic workflows ਸਭ ਦੀਆਂ ਆਪਣੀਆਂ ਭੂਮਿਕਾਵਾਂ ਹੋਣਗੀਆਂ.
ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ Codex Security ਉਸ ਹਿੱਸੇ ਵਿੱਚ ਵਧੀਆ ਹੋਵੇ ਜਿਸ ਦੀ security teams ਲਈ ਸਭ ਤੋਂ ਵੱਧ ਲਾਗਤ ਹੁੰਦੀ ਹੈ: “ਇਹ ਸ਼ੱਕੀ ਲੱਗਦਾ ਹੈ” ਨੂੰ “ਇਹ ਅਸਲ ਹੈ, ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਰਹੀ ਸਿਸਟਮ ਦੀ ਮਨਸ਼ਾ ਨਾਲ ਮਿਲਦੀ-ਜੁਲਦੀ fix” ਵਿੱਚ ਬਦਲਣਾ.
ਜੇ ਤੁਸੀਂ ਹੋਰ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ Codex Security ਰਿਪੋਜ਼ਟਰੀਆਂ ਨੂੰ ਕਿਵੇਂ scan ਕਰਦਾ ਹੈ, findings ਨੂੰ ਕਿਵੇਂ validate ਕਰਦਾ ਹੈ, ਅਤੇ fixes ਕਿਵੇਂ ਸੁਝਾਉਂਦਾ ਹੈ, ਤਾਂ ਸਾਡਾ ਦਸਤਾਵੇਜ਼(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਵੇਖੋ.
