Codex ಭದ್ರತೆ SAST ವರದಿಯನ್ನು ಏಕೆ ಒಳಗೊಂಡಿಲ್ಲ

ದಶಕಗಳಿಂದ, ಸ್ಥಿರ ಅಪ್ಲಿಕೇಶನ್ ಭದ್ರತಾ ಪರೀಕ್ಷೆ (SAST) ಭದ್ರತಾ ತಂಡಗಳಿಗೆ ಕೋಡ್ ವಿಮರ್ಶೆಯನ್ನು ಪ್ರಮಾಣದಲ್ಲಿ ವಿಸ್ತರಿಸಲು ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿ ವಿಧಾನಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. 

ಆದರೆ ನಾವು Codex ಭದ್ರತೆಯನ್ನು ನಿರ್ಮಿಸಿದಾಗ, ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಒಂದು ವಿನ್ಯಾಸ ನಿರ್ಧಾರ ಕೈಗೊಂಡೆವು: ಸ್ಥಿರ ವಿಶ್ಲೇಷಣಾ ವರದಿಯನ್ನು ಇಂಪೋರ್ಟ್ ಮಾಡಿ ಅದನ್ನು ಟ್ರೈಯಾಜ್ ಮಾಡಲು ಏಜೆಂಟ್‌ಗೆ ಕೇಳುವುದರಿಂದ ನಾವು ಆರಂಭಿಸಲಿಲ್ಲ. ನಾವು ವ್ಯವಸ್ಥೆಯನ್ನು ರಿಪೊಸಿಟರಿಯನ್ನೇ ಆಧಾರವಾಗಿ ಆರಂಭಿಸುವಂತೆ ವಿನ್ಯಾಸಗೊಳಿಸಿದ್ದೇವೆ—ಅದರ ವಾಸ್ತುಶಿಲ್ಪ, ನಂಬಿಕೆಯ ಗಡಿಗಳು, ಮತ್ತು ಉದ್ದೇಶಿತ ವರ್ತನೆ—ಮತ್ತು ಅದು ಕಂಡುಹಿಡಿಯುವುದನ್ನು ಮಾನವನು ಅದರಲ್ಲಿ ಸಮಯ ಹೂಡುವಂತೆ ಕೇಳುವ ಮೊದಲು ಪರಿಶೀಲಿಸಿ ದೃಢಪಡಿಸುವಂತೆ. 

ಕಾರಣ ಸರಳವಾಗಿದೆ: ಅತ್ಯಂತ ಕಠಿಣ ದುರ್ಬಲತೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾಫ್ಲೋ ಸಮಸ್ಯೆಗಳಾಗಿರುವುದಿಲ್ಲ. ಕೋಡ್ ಒಂದು ಸುರಕ್ಷತಾ ಪರಿಶೀಲನೆಯನ್ನು ಜಾರಿಗೊಳಿಸುವಂತೆ ಕಾಣುವಾಗ ಅವು ಸಂಭವಿಸುತ್ತವೆ, ಆದರೆ ಆ ಪರಿಶೀಲನೆ ಸಿಸ್ಟಮ್‌ ಅವಲಂಬಿಸುವ ಗುಣಲಕ್ಷಣವನ್ನು ವಾಸ್ತವವಾಗಿ ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ಬೇರೊಂದು ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಸವಾಲು ಕೇವಲ ಪ್ರೋಗ್ರಾಂ ಮೂಲಕ ಡೇಟಾ ಹೇಗೆ ಚಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅನುಸರಿಸುವುದಲ್ಲ—ಕೋಡ್‌ನಲ್ಲಿರುವ ರಕ್ಷಣೆಗಳು ನಿಜವಾಗಿಯೂ ಕೆಲಸ ಮಾಡುತ್ತವೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದಾಗಿದೆ.

SAST ಅನ್ನು ಬಹುಶಃ ಸ್ವಚ್ಛ ಪೈಪ್‌ಲೈನ್‌ ಆಗಿ ರೂಪಿಸಲಾಗುತ್ತದೆ: ನಂಬಲರ್ಹವಲ್ಲದ ಇನ್‌ಪುಟ್‌ನ ಮೂಲವನ್ನು ಗುರುತಿಸಿ, ಪ್ರೋಗ್ರಾಂ ಮೂಲಕ ಡೇಟಾವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ ಮತ್ತು ಶುದ್ಧೀಕರಣವಿಲ್ಲದೆ ಆ ಡೇಟಾ ಸಂವೇದನಾಶೀಲ ಸಿಂಕ್‌ಗೆ ತಲುಪುವ ಸಂದರ್ಭಗಳನ್ನು ಫ್ಲ್ಯಾಗ್ ಮಾಡಿ. ಇದು ಒಂದು ಸುಂದರವಾದ ಮಾಡೆಲ್ ಮತ್ತು ಇದು ಬಹಳಷ್ಟು ನಿಜವಾದ ಬಗ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ, SAST ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ನಿರ್ವಹಣೀಯವಾಗಿರಲು ಅಂದಾಜುಗಳನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ—ವಿಶೇಷವಾಗಿ ಇಂಡೈರೆಕ್ಷನ್, ಡೈನಾಮಿಕ್ ಡಿಸ್ಪ್ಯಾಚ್, ಕಾಲ್‌ಬ್ಯಾಕ್‌ಗಳು, ರಿಫ್ಲೆಕ್ಷನ್ ಮತ್ತು ಫ್ರೇಮ್‌ವರ್ಕ್-ಹೆವಿ ಕಂಟ್ರೋಲ್ ಫ್ಲೋ ಇರುವ ನೈಜ ಕೋಡ್‌ಬೇಸ್‌ಗಳಲ್ಲಿ. ಆ ಅಂದಾಜುಗಳು SAST ಮೇಲೆ ಟೀಕೆ ಅಲ್ಲ; ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸದೆ ಅದರ ಬಗ್ಗೆ ತರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸುವ ವಾಸ್ತವಿಕತೆ.

ಅದು, ಸ್ವತಃ, Codex ಭದ್ರತೆ SAST ವರದಿಯಿಂದ ಪ್ರಾರಂಭಿಸದಿರುವುದಕ್ಕೆ ಕಾರಣವಲ್ಲ.

ಆಳವಾದ ಸಮಸ್ಯೆ ಎಂದರೆ ನೀವು ಮೂಲವನ್ನು ಗುರಿಯೊಂದಿಗೆ ಯಶಸ್ವಿಯಾಗಿ ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಏನಾಗುತ್ತದೆ ಎಂಬುದು.

ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆ ಅನೇಕ ಫಂಕ್ಷನ್‌ಗಳು ಮತ್ತು ಲೇಯರ್‌ಗಳ ಅಡ್ಡಲಾಗಿ ಇನ್‌ಪುಟ್ ಅನ್ನು ಸರಿಯಾಗಿ ಟ್ರೇಸ್ ಮಾಡಿದರೂ ಸಹ, ದೌರ್ಬಲ್ಯ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆಯೇ ಎಂಬುದನ್ನು ನಿಜವಾಗಿ ನಿರ್ಧರಿಸುವ ಪ್ರಶ್ನೆಗೆ ಅದು ಇನ್ನೂ ಉತ್ತರಿಸಲೇಬೇಕು:

ಒಂದು ಸಾಮಾನ್ಯ ಮಾದರಿಯನ್ನು ಪರಿಗಣಿಸಿ: ನಂಬಿಕರ್ಹವಲ್ಲದ ವಿಷಯವನ್ನು ರೆಂಡರ್ ಮಾಡುವ ಮೊದಲು ಕೋಡ್ sanitize_html() ಅನ್ನು ಕರೆಸುತ್ತದೆ. ಸ್ಥಿರ ವಿಶ್ಲೇಷಕವು ಸ್ಯಾನಿಟೈಜರ್ ಕಾರ್ಯನಿರ್ವಹಿಸಿದೆ ಎಂಬುದನ್ನು ನೋಡಬಹುದು. ಸಾಮಾನ್ಯವಾಗಿ ಅದು ನಿರ್ಧರಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ, ಆ ಸ್ಯಾನಿಟೈಜರ್ ಆ ನಿರ್ದಿಷ್ಟ ರೆಂಡರಿಂಗ್ ಸಂದರ್ಭ, ಟೆಂಪ್ಲೇಟ್ ಎಂಜಿನ್, ಎನ್‌ಕೋಡಿಂಗ್ ವರ್ತನೆ ಮತ್ತು ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಪರಿವರ್ತನೆಗಳಿಗೆ ನಿಜವಾಗಿಯೂ ಸಾಕಷ್ತವೇ ಎಂಬುದನ್ನು.

ಅಲ್ಲೇ ವಿಷಯಗಳು ಕಷ್ಟಕರವಾಗುತ್ತವೆ. ಸಮಸ್ಯೆ ಕೇವಲ ಡೇಟಾ ಸಿಂಕ್‌ಗೆ ತಲುಪುತ್ತದೆಯೇ ಎಂಬುದಷ್ಟೇ ಅಲ್ಲ. ಇದು ಕೋಡ್‌ನಲ್ಲಿರುವ ಚೆಕ್‌ಗಳು ವ್ಯವಸ್ಥೆ ಅವು ಮಾಡುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ರೀತಿಯಲ್ಲಿ ಮೌಲ್ಯವನ್ನು ವಾಸ್ತವವಾಗಿ ನಿರ್ಬಂಧಿಸುತ್ತವೆಯೇ ಎಂಬುದರ ಬಗ್ಗೆ.

ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ: “ಕೋಡ್ ಒಂದು ಸ್ಯಾನಿಟೈಸರ್ ಅನ್ನು ಕರೆಸುತ್ತದೆ” ಮತ್ತು “ವ್ಯವಸ್ಥೆ ಸುರಕ್ಷಿತವಾಗಿದೆ.”ಇವರ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಬಹಳ ದೊಡ್ಡದು.

ನಿಜವಾದ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಪದೇಪದೇ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಒಂದು ಮಾದರಿ ಇಲ್ಲಿದೆ.

ಒಂದು ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ JSON ಪೇಲೋಡ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಅದರಿಂದ redirect_url ಅನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ, ಅನುಮತಿಪಟ್ಟಿ regex ವಿರುದ್ಧ ಅದನ್ನು ಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ, URL-ಡಿಕೋಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ರೀಡೈರೆಕ್ಟ್ ಹ್ಯಾಂಡ್ಲರ್‌ಗೆ ಪಾಸ್ ಮಾಡುತ್ತದೆ.

ಒಂದು ಶ್ರೇಷ್ಠ ಮೂಲ-ದಿಂದ-ಸಿಂಕ್ ವರದಿ ಹರಿವಿನ ವಿವರವನ್ನು ನೀಡಬಹುದು:

ನಂಬಿಕರ್ಹವಲ್ಲದ ಇನ್‌ಪುಟ್ → regex ಪರಿಶೀಲನೆ → URL ಡಿಕೋಡ್ → ಮರುನಿರ್ದೇಶನ

ಆದರೆ ನಿಜವಾದ ಪ್ರಶ್ನೆಯೆಂದರೆ ಪರಿಶೀಲನೆ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆಯೇ ಎಂಬುದಲ್ಲ. ಮುಂದೆ ನಡೆಯುವ ಪರಿವರ್ತನೆಗಳ ನಂತರವೂ ಆ ಪರಿಶೀಲನೆ ಇನ್ನೂ ಮೌಲ್ಯವನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತಿದೆಯೇ ಎಂಬುದೇ ಪ್ರಶ್ನೆ.

ರೆಜೆಕ್ಸ್ ಡಿಕೋಡಿಂಗ್ ಮಾಡುವ ಮೊದಲು ಚಾಲನೆಗೊಂಡರೆ, ರೀಡೈರೆಕ್ಟ್ ಹ್ಯಾಂಡ್ಲರ್ ಅದನ್ನು ಹೇಗೆ ಅರ್ಥೈಸುತ್ತದೋ ಆ ರೀತಿಯಲ್ಲಿ ಅದು ನಿಜವಾಗಿಯೂ ಡಿಕೋಡ್ ಮಾಡಿದ URL ಅನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆಯೇ?

ಅದಕ್ಕೆ ಉತ್ತರಿಸುವುದು ಎಂದರೆ ಸಂಪೂರ್ಣ ಪರಿವರ್ತನೆ ಸರಣಿಯ ಬಗ್ಗೆ ರೀಜನಿಂಗ್ ಆಲೋಚಿಸುವುದು: regex ಏನನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಡಿಕೋಡಿಂಗ್ ಮತ್ತು ನಾರ್ಮಲೈಜೇಶನ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, URL ಪಾರ್ಸಿಂಗ್ ಎಡ್ಜ್ ಕೇಸ್‌ಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ರೀಡೈರೆಕ್ಟ್ ಲಾಜಿಕ್ ಸ್ಕೀಮ್‌ಗಳು ಮತ್ತು ಆಥಾರಿಟಿಗಳನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುತ್ತದೆ.

ಪ್ರಯೋಗದಲ್ಲಿ ಮುಖ್ಯವಾಗುವ ಅನೇಕ ದುರ್ಬಲತೆಗಳು ಹೀಗೆ ಕಾಣುತ್ತವೆ: ಕಾರ್ಯಗಳ ಕ್ರಮದ ತಪ್ಪುಗಳು, ಭಾಗಶಃ ಸಾಮಾನ್ಯೀಕರಣ, ಪಾರ್ಸಿಂಗ್‌ನ ಅಸ್ಪಷ್ಟತೆಗಳು ಮತ್ತು ಮಾನ್ಯತೆ ಹಾಗೂ ವ್ಯಾಖ್ಯಾನದ ನಡುವಿನ ಹೊಂದಾಣಿಕೆಯಾಗದಿರುವಿಕೆ. ಡೇಟಾ ಹರಿವು ಗೋಚರಿಸುತ್ತದೆ. ದೌರ್ಬಲ್ಯವು ನಿರ್ಬಂಧಗಳು ಪರಿವರ್ತನೆಗಳ ಸರಣಿಯ ಮೂಲಕ ಹೇಗೆ ಹರಡುತ್ತವೆ—ಅಥವಾ ಹರಡದೆ ಉಳಿಯುತ್ತವೆ—ಎಂಬುದರಲ್ಲಿ ಇದೆ.

ಇದು ಕೇವಲ ಸೈದ್ಧಾಂತಿಕ ಮಾದರಿಯಲ್ಲ. In CVE-2024-29041⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ), Express ನಲ್ಲಿ ಓಪನ್ ರಿಡೈರೆಕ್ಟ್ ಸಮಸ್ಯೆಯ ಪರಿಣಾಮವಿತ್ತು; ಅಲ್ಲಿ ತಪ್ಪಾಗಿ ರೂಪಿಸಿದ URL ಗಳು, ಮರುನಿರ್ದೇಶನ ಗುರಿಗಳನ್ನು ಎನ್‌ಕೋಡ್ ಮಾಡಿ ನಂತರ ಅರ್ಥೈಸಿದ ವಿಧಾನದಿಂದಾಗಿ, ಸಾಮಾನ್ಯ ಅನುಮತಿಪಟ್ಟಿ ಅನುಷ್ಠಾನಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡಬಹುದಾಗಿತ್ತು. ಡೇಟಾಫ್ಲೋ ಸರಳವಾಗಿತ್ತು. ಇನ್ನೂ ಕಷ್ಟಕರವಾದ ಪ್ರಶ್ನೆ—ಮತ್ತು ದೋಷ ಅಸ್ತಿತ್ವದಲ್ಲಿತ್ತೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿದ ಪ್ರಶ್ನೆ—ಅಂದರೆ ಪರಿವರ್ತನಾ ಸರಪಳಿಯ ನಂತರವೂ ಮಾನ್ಯೀಕರಣವು ಇನ್ನೂ ಇದ್ದಿತ್ತೇ ಎಂಬುದಾಗಿತ್ತು.

Codex ಭದ್ರತೆಯನ್ನು ಸರಳ ಗುರಿಯ ಮೇಲೆ ನಿರ್ಮಿಸಲಾಗಿದೆ: ಹೆಚ್ಚು ಬಲವಾದ ಸಾಕ್ಷ್ಯಗಳ ಮೂಲಕ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊರತರುವ ಮೂಲಕ ಟ್ರಯಾಜ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು. ಉತ್ಪನ್ನದಲ್ಲಿ, ರೆಪೋ-ನಿರ್ದಿಷ್ಟ ಸಂದರ್ಭವನ್ನು (ಥ್ರೆಟ್ ಮಾಡೆಲ್ ಸೇರಿದಂತೆ) ಬಳಸುವುದು ಮತ್ತು ಅವುಗಳನ್ನು ಹೊರಹೊಮ್ಮಿಸುವ ಮೊದಲು ಪ್ರತ್ಯೇಕ ಪರಿಸರದಲ್ಲಿ ಹೈ-ಸಿಗ್ನಲ್ ಸಮಸ್ಯೆಗಳನ್ನು ಮಾನ್ಯಗೊಳಿಸುವುದು. 

Codex ಭದ್ರತೆ “ವ್ಯಾಲಿಡೇಶನ್” ಅಥವಾ “ಸ್ಯಾನಿಟೈಸೇಶನ್” ಎಂಬುದಾಗಿ ಕಾಣುವ ಒಂದು ಗಡಿಯನ್ನು ಎದುರಿಸಿದಾಗ, ಅದನ್ನು ಚೆಕ್‌ಬಾಕ್ಸ್‌ನಂತೆ ಪರಿಗಣಿಸುವುದಿಲ್ಲ. ಇದು ಕೋಡ್ ಯಾವ ಖಾತರಿಯನ್ನು ನೀಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ—ಮತ್ತೆ ಆ ಖಾತರಿಯನ್ನು ತಪ್ಪೆಂದು ಸಾಬೀತುಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಇವುಗಳ ಮಿಶ್ರಣದಂತೆ ಕಾಣುತ್ತದೆ:

• ಸಂಪೂರ್ಣ ರಿಪೊಸಿಟರಿ ಸಂದರ್ಭದೊಂದಿಗೆ ಸಂಬಂಧಿತ ಕೋಡ್ ಪಾತ್ ಅನ್ನು ಭದ್ರತಾ ಸಂಶೋಧಕನು ಮಾಡುವ ರೀತಿಯಲ್ಲಿ ಓದಿ, ಉದ್ದೇಶ ಮತ್ತು ಅನುಷ್ಠಾನದ ನಡುವಿನ ಹೊಂದಿಕೆಯಾಗದತೆಗಳನ್ನು ಹುಡುಕುವುದು. ಇದರಲ್ಲಿ ಕಾಮೆಂಟ್‌ಗಳು ಸೇರಿವೆ, ಆದರೆ ಮಾಡೆಲ್ ಅವುಗಳನ್ನು ಅವಶ್ಯಕವಾಗಿ ನಂಬುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ನಿಮ್ಮ ಕೋಡ್ ಮೇಲ್ಭಾಗದಲ್ಲಿ //Halvar ಹೇಳಿದ್ದು: ಇದು ಬಗ್ ಅಲ್ಲ ಅನ್ನು ಸೇರಿಸುವುದು, ನಿಜವಾಗಿಯೂ ಬಗ್ ಇದ್ದರೆ, ಮಾಡೆಲ್ ಗೊಂದಲಗೊಳ್ಳುವುದಿಲ್ಲ.
• ಸಮಸ್ಯೆಯನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಚಿಕ್ಕ ಪರೀಕ್ಷಿಸಬಹುದಾದ ಭಾಗಕ್ಕೆ (ಉದಾಹರಣೆಗೆ, ಒಂದೇ ಇನ್‌ಪುಟ್ ಸುತ್ತಲಿನ ರೂಪಾಂತರ ಪೈಪ್‌ಲೈನ್), ಇಳಿಸುವುದು, ಇದರಿಂದ ಉಳಿದ ವ್ಯವಸ್ಥೆ ಅಡ್ಡಿಯಾಗದೆ ನೀವು ಅದರ ಬಗ್ಗೆ ತರ್ಕಿಸಬಹುದು. ಈ ಅರ್ಥದಲ್ಲಿ, Codex ಭದ್ರತೆ ಸಣ್ಣ ಕೋಡ್ ತುಣುಕುಗಳನ್ನು ತೆಗೆದು ನಂತರ ಅವುಗಳಿಗಾಗಿ ಮೈಕ್ರೋ-ಫಜರ್‌ಗಳನ್ನು ಬರೆಯುತ್ತದೆ.
• ಪರಿವರ್ತನೆಗಳಾದ್ಯಂತ ನಿರ್ಬಂಧಗಳ ಬಗ್ಗೆ ರೀಜನಿಂಗ್, ಪ್ರತಿ ಪರಿಶೀಲನೆಯನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಪರಿಗಣಿಸುವ ಬದಲು. ಯೋಗ್ಯವಾದ ಸಂದರ್ಭದಲ್ಲಿ, ಇದರಲ್ಲಿ ತೃಪ್ತಿಸಾಧ್ಯತಾ ಪ್ರಶ್ನೆಯಾಗಿ ರೂಪೀಕರಣವನ್ನು ಸೇರಿಸಬಹುದು. ಇನ್ನೊಂದು ಮಾತಿನಲ್ಲಿ, ನಾವು ಮಾಡೆಲ್‌ಗೆ z3-solver ಇರುವ Python ಪರಿಸರಕ್ಕೆ ಪ್ರವೇಶವನ್ನು ನೀಡುತ್ತೇವೆ ಮತ್ತು ಅದು ಅಗತ್ಯವಿದ್ದಾಗ ಅದನ್ನು ಬಳಸುವಲ್ಲಿ ನಿಪುಣವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ಸಂಕೀರ್ಣವಾದ ಇನ್‌ಪುಟ್ ನಿರ್ಬಂಧ ಸಮಸ್ಯೆಗೆ ಉತ್ತರಿಸುವಾಗ ಮಾನವನಿಗೆ ಹೇಗೆ ಮಾಡಬೇಕಾಗುತ್ತದೆಯೋ ಹಾಗೆಯೇ. ಅಸಾಮಾನ್ಯ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳಲ್ಲಿ ಇಂಟಿಜರ್ ಓವರ್‌ಫ್ಲೋಗಳು ಅಥವಾ ಅದಕ್ಕೆ ಸಮಾನವಾದ ದೋಷಗಳನ್ನು ನೋಡಲು ಇದು ವಿಶೇಷವಾಗಿ ಉಪಯುಕ್ತವಾಗಿದೆ.
• ಸಾಧ್ಯವಾದಲ್ಲಿ, “ಇದು ಸಮಸ್ಯೆಯಾಗಬಹುದು” ಎಂಬುದನ್ನು “ಇದು ಸಮಸ್ಯೆಯೇ” ಎಂಬುದರಿಂದ ಬೇರ್ಪಡಿಸಲು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಮೌಲ್ಯೀಕರಣ ಪರಿಸರದಲ್ಲಿ ಹೈಪೊಥೆಸಿಸ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು. ಡೀಬಗ್ ಮೋಡ್‌ನಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಕಾಂಪೈಲ್ ಮಾಡಿ ಮಾಡುವ ಪೂರ್ಣ ಎಂಡ್-ಟು-ಎಂಡ್ PoC ಗಿಂತ ಉತ್ತಮ ಪುರಾವೆ ಇಲ್ಲ. 

ಇದು ಪ್ರಮುಖ ಬದಲಾವಣೆ: “ಒಂದು ಪರಿಶೀಲನೆ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ” ಎಂಬಲ್ಲಿಯೇ ನಿಲ್ಲುವುದಕ್ಕಿಂತ, ವ್ಯವಸ್ಥೆ “ಅಪರಿವರ್ತ್ಯತೆ ಮಾನ್ಯವಾಗಿದೆ (ಅಥವಾ ಅಲ್ಲ) ಮತ್ತು ಇಲ್ಲಿದೆ ಸಾಕ್ಷ್ಯ” ಎಂಬತ್ತ ತಳ್ಳುತ್ತದೆ. ಮತ್ತು ಮಾಡೆಲ್ ಆ ಕೆಲಸಕ್ಕೆ ಅತ್ಯುತ್ತಮ ಸಾಧನವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ.

ಸಮಂಜಸವಾದ ಪ್ರತಿಕ್ರಿಯೆ ಎಂದರೆ: ಎರಡನ್ನೂ ಏಕೆ ಮಾಡಬಾರದು? SAST ವರದಿಯಿಂದ ಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಇನ್ನಷ್ಟು ಆಳವಾಗಿ ತಾರ್ಕಿಕತೆ ಮಾಡಲು ಏಜೆಂಟ್ ಅನ್ನು ಬಳಸಿ.

ಪೂರ್ವಗಣಿತ ಕಂಡುಹಿಡಿಕೆಗಳು ಸಹಾಯಕವಾಗುವ ಸಂದರ್ಭಗಳಿವೆ—ವಿಶೇಷವಾಗಿ ಸೀಮಿತ, ತಿಳಿದಿರುವ ಬಗ್ ವರ್ಗಗಳಿಗೆ. ಆದರೆ, ಸಂದರ್ಭದಲ್ಲೇ ದುರ್ಬಲತೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ಮಾನ್ಯಗೊಳಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಏಜೆಂಟ್‌ಗೆ, SAST ವರದಿಯಿಂದ ಪ್ರಾರಂಭಿಸುವುದು ಮೂರು ಊಹಿಸಬಹುದಾದ ವೈಫಲ್ಯ ವಿಧಾನಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

ಮೊದಲು, ಇದು ಮುಂಚಿತವಾಗಿ ಸೀಮಿತಗೊಳಿಸುವಿಕೆಯನ್ನು ಪ್ರೋತ್ಸಾಹಿಸಬಹುದು. ಕಂಡುಹಿಡಿತಗಳ ಪಟ್ಟಿ ಎಂದರೆ ಸಾಧನವು ಈಗಾಗಲೇ ಎಲ್ಲಿ ನೋಡಿದೆ ಎಂಬ ನಕ್ಷೆ. ನೀವು ಇದನ್ನೇ ಆರಂಭಿಕ ಬಿಂದುವೆಂದು ಪರಿಗಣಿಸಿದರೆ, ಅದೇ ಪ್ರದೇಶಗಳಲ್ಲಿ ಅತಿಯಾಗಿ ಪ್ರಯತ್ನ ಹೂಡುವಂತೆ, ಅದೇ ಅಮೂರ್ತ ಕಲ್ಪನೆಗಳನ್ನು ಬಳಸುವಂತೆ ಮತ್ತು ಸಾಧನದ ವಿಶ್ವದೃಷ್ಟಿಗೆ ಹೊಂದದ ಕೆಲವು ರೀತಿಯ ಸಮಸ್ಯೆಗಳನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುವಂತೆ ನೀವು ವ್ಯವಸ್ಥೆಯನ್ನು ವಾಲಿಸಬಹುದು.

ಎರಡನೆಯದಾಗಿ, ಇದು ಹಿಂತೆಗೆದುಕೊಳ್ಳಲು ಕಷ್ಟವಾಗುವ ಅಪ್ರತ್ಯಕ್ಷ ತೀರ್ಮಾನಗಳನ್ನು ಪರಿಚಯಿಸಬಹುದು. ಅನೇಕ SAST ಕಂಡುಹಿಡಿತಗಳು ಸ್ಯಾನಿಟೈಸೇಶನ್, ವ್ಯಾಲಿಡೇಶನ್ ಅಥವಾ ನಂಬಿಕೆ ಗಡಿಗಳ ಬಗ್ಗೆ ಊಹೆಗಳನ್ನು ಸಂಕೇತಿಸುತ್ತವೆ. ಆ ಊಹೆಗಳು ತಪ್ಪಾಗಿದ್ದರೆ ಅಥವಾ ಕೇವಲ ಅಪೂರ್ಣವಾಗಿದ್ದರೆ, ಅವುಗಳನ್ನು ರೀಜನಿಂಗ್ ಲೂಪ್‌ಗೆ ನೀಡುವುದರಿಂದ ಏಜೆಂಟ್ “ತನಿಖೆ”ಯಿಂದ “ದೃಢೀಕರಿಸಿ ಅಥವಾ ತಳ್ಳಿ ಹಾಕಿ”ಗೆ ಬದಲಾಯಿಸಬಹುದು, ಇದು ನಾವು ಏಜೆಂಟ್‌ನಿಂದ ಬಯಸುವುದಿಲ್ಲ.

ಮೂರನೆಯದಾಗಿ, ಇದು ರೀಜನಿಂಗ್ ವ್ಯವಸ್ಥೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಹೆಚ್ಚು ಕಷ್ಟವಾಗಿಸಬಹುದು. ಪೈಪ್‌ಲೈನ್ SAST ಔಟ್‌ಪುಟ್‌ನಿಂದ ಪ್ರಾರಂಭವಾದರೆ, ಏಜೆಂಟ್ ತನ್ನ ವಿಶ್ಲೇಷಣೆಯಿಂದ ಕಂಡುಹಿಡಿದದ್ದನ್ನು ಮತ್ತೊಂದು ಸಾಧನದಿಂದ ಪಡೆದದ್ದರಿಂದ ಬೇರ್ಪಡಿಸುವುದು ಕಷ್ಟವಾಗುತ್ತದೆ. ಆ ಬೇರ್ಪಡಿಸುವಿಕೆ ಮುಖ್ಯವಾಗಿದೆ, ನೀವು ವ್ಯವಸ್ಥೆಯ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನಿಖರವಾಗಿ ಅಳೆಯಲು ಬಯಸಿದರೆ, ಅದು ವ್ಯವಸ್ಥೆಯು ಕಾಲಕ್ರಮೇಣ ಸುಧಾರಿಸಲು ಅಗತ್ಯವಾಗಿದೆ.

ಆದ್ದರಿಂದ ನಾವು Codex ಭದ್ರತೆಯನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ, ಭದ್ರತಾ ಸಂಶೋಧನೆ ಆರಂಭವಾಗುವ ಸ್ಥಳದಿಂದ ಆರಂಭಿಸಲು: ಕೋಡ್ ಮತ್ತು ವ್ಯವಸ್ಥೆಯ ಉದ್ದೇಶದಿಂದ, ಮತ್ತು ಮಾನವನನ್ನು ವ್ಯತ್ಯಯಗೊಳಿಸುವ ಮೊದಲು ವಿಶ್ವಾಸದ ಮಟ್ಟವನ್ನು ಹೆಚ್ಚಿಸಲು ಮಾನ್ಯತೆಯನ್ನು ಬಳಸುತ್ತೇವೆ.

SAST tools ಅವುಗಳಿಗೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ವಿಷಯದಲ್ಲಿ ಅತ್ಯುತ್ತಮವಾಗಿರಬಹುದು: ಭದ್ರ ಕೋಡಿಂಗ್ ಮಾನದಂಡಗಳನ್ನು ಜಾರಿಗೊಳಿಸುವುದು, ಸರಳವಾದ ಸೋರ್ಸ್-ಟು-ಸಿಂಕ್ ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು ಮತ್ತು ನಿರೀಕ್ಷಿತ ವಿನಿಮಯಗಳೊಂದಿಗೆ ವ್ಯಾಪಕ ಮಟ್ಟದಲ್ಲಿ ತಿಳಿದ ಮಾದರಿಗಳನ್ನು ಗುರುತಿಸುವುದು. ಅವು ಆಳವಾದ ರಕ್ಷಣಾ ತಂತ್ರದ ಬಲವಾದ ಭಾಗವಾಗಬಹುದು.

ಈ ಪೋಸ್ಟ್ ಹೆಚ್ಚು ಸೀಮಿತವಾಗಿದೆ: ನಡವಳಿಕೆಯನ್ನು ಕುರಿತು ತರ್ಕಿಸಲು ಮತ್ತು ಸಂಶೋಧನೆಗಳನ್ನು ಮೌಲ್ಯೀಕರಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಏಜೆಂಟ್ ತನ್ನ ಕೆಲಸವನ್ನು ಸ್ಥಿರ ಸಂಶೋಧನೆಗಳ ಪಟ್ಟಿಗೆ ಆಧಾರಿತವಾಗಿಯೇ ಆರಂಭಿಸಬಾರದು ಎಂಬುದರ ಕುರಿತು ಇದು.

ಮೂಲದಿಂದ ಸಿಂಕ್‌ಗೆ ಎಂಬ ಸರಳ ಆಲೋಚನೆಗೆ ಸಂಬಂಧಿಸಿದ ಮತ್ತೊಂದು ಮಿತಿಯನ್ನು ಗಮನಿಸುವುದು ಕೂಡ ಮೌಲ್ಯಯುತವಾಗಿದೆ: ಪ್ರತಿಯೊಂದು ದುರ್ಬಲತೆಯೂ ಡೇಟಾಫ್ಲೋ ಸಮಸ್ಯೆಯಲ್ಲ. ಅನೇಕ ನೈಜ ವೈಫಲ್ಯಗಳು ಸ್ಥಿತಿ ಮತ್ತು ಸ್ಥಿರತೆಯ ಸಮಸ್ಯೆಗಳಾಗಿವೆ—ಕಾರ್ಯಪ್ರವಾಹದ ಬೈಸಾಸ್‌ಗಳು, ಅಧಿಕಾರೀಕರಣದ ಖಾಲಿತನಗಳು ಮತ್ತು “ವ್ಯವಸ್ಥೆ ತಪ್ಪಾದ ಸ್ಥಿತಿಯಲ್ಲಿ ಇದೆ” ದೋಷಗಳು. ಈ ರೀತಿಯ ದೋಷಗಳಲ್ಲಿ, ದೋಷಿತ ಮೌಲ್ಯವು ಒಂದೇ “ಅಪಾಯಕಾರಿ ಸಿಂಕ್” ಅನ್ನು ತಲುಪುವುದಿಲ್ಲ. ಕಾರ್ಯಕ್ರಮವು ಯಾವುದು ಯಾವಾಗಲೂ ಸತ್ಯವಾಗಿರುತ್ತದೆ ಎಂದು ಊಹಿಸುತ್ತದೆ ಎಂಬುದರಲ್ಲಿ ಅಪಾಯವಿದೆ. 

ನಾವು ಭದ್ರತಾ ಪರಿಕರಗಳ ಪರಿಸರ ಮುಂದುವರಿದು ಸುಧಾರಣೆಗೊಳ್ಳುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ: ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆ, ಫಜ್ಝಿಂಗ್, ರನ್‌ಟೈಮ್ ಗಾರ್ಡ್‌ಗಳು ಮತ್ತು ಏಜೆಂಟಿಕ್ ವರ್ಕ್‌ಫ್ಲೋಗಳು ಎಲ್ಲವೂ ತಮ್ಮ ಪಾತ್ರವನ್ನು ವಹಿಸುವುವು.

ನಾವು Codex ಭದ್ರತೆಯನ್ನು ಭದ್ರತಾ ತಂಡಗಳಿಗೆ ಅತ್ಯಂತ ಹೆಚ್ಚು ವೆಚ್ಚವಾಗುವ ಭಾಗದಲ್ಲಿ ಉತ್ತಮವಾಗಿರಬೇಕೆಂದು ಬಯಸುತ್ತೇವೆ: “ಇದು ಅನುಮಾನಾಸ್ಪದವಾಗಿ ಕಾಣುತ್ತದೆ” ಅನ್ನು “ಇದು ನಿಜವಾಗಿದೆ, ಇದು ಹೇಗೆ ವಿಫಲವಾಗುತ್ತದೆ ಮತ್ತು ಸಿಸ್ಟಮ್ ಉದ್ದೇಶಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳುವ ಪರಿಹಾರ ಇಲ್ಲಿದೆ” ಎಂದು ಪರಿವರ್ತಿಸುವುದು. 

Codex ಭದ್ರತೆ ರಿಪೊಸಿಟರಿಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವ ವಿಧಾನ, ಕಂಡುಬಂದಿಕೆಗಳನ್ನು ಮಾನ್ಯಗೊಳಿಸುವುದು ಮತ್ತು ಸರಿಪಡಿಕೆಗಳನ್ನು ಪ್ರಸ್ತಾಪಿಸುವುದು ಎಂಬುದರ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ತಿಳಿಯಲು, ನಮ್ಮ ಡಾಕ್ಯುಮೆಂಟೇಶನ್⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಅನ್ನು ನೋಡಿ.