ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುವ AI ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸಲು, ಮೊದಲು ಅವುಗಳನ್ನು ಭೇದಿಸಲು ಪ್ರಯತ್ನಿಸಬೇಕು. ಹಣಕಾಸು ಸೇವೆಗಳ ಗ್ರಾಹಕಮುಖಿ AI ಅನ್ವಯವನ್ನು ಪರೀಕ್ಷಿಸಿ, ಅದರ ದೌರ್ಬಲ್ಯಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ನಾವು ದಾಳಿಕೋರರಂತೆ ವರ್ತಿಸಿ ರೆಡ್ ಟೀಮಿಂಗ್ ನಡೆಸಿದೆವು. ಭದ್ರತೆಯಲ್ಲಿ ರಾಜಿ ಮಾಡಿಕೊಳ್ಳಲಾಗದ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ LLM ಆಧಾರಿತ ಅನ್ವಯಗಳನ್ನು ನಿಯೋಜಿಸುವ ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ನಮ್ಮ ಸಂಶೋಧನೆಗಳು ಮುಖ್ಯವಾಗಿವೆ.
ನಿಜವಾದ ದಾಳಿಕೋರರು ದೌರ್ಬಲ್ಯಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಮೊದಲೇ ಅವುಗಳನ್ನು ಸರಿಪಡಿಸಲು, ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿಮ್ಮ AI ವ್ಯವಸ್ಥೆಯನ್ನು ಭೇದಿಸಲು ಪ್ರಯತ್ನಿಸುವ ವಿಧಾನವೇ ರೆಡ್ ಟೀಮಿಂಗ್. ಹಣಕಾಸು ಸೇವೆಗಳಲ್ಲಿ ಅಪಾಯ ವಿಶೇಷವಾಗಿ ಹೆಚ್ಚು: AI ಅನ್ವಯಗಳು ಗ್ರಾಹಕರ ದತ್ತಾಂಶವನ್ನು ಬಳಸುತ್ತವೆ, ವಹಿವಾಟುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತವೆ ಮತ್ತು ಹಣಕಾಸು ಒಳನೋಟಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ. ವೈಫಲ್ಯದ ಪರಿಣಾಮವು ಕಳಪೆ ಬಳಕೆದಾರ ಅನುಭವದಿಂದ ಹಿಡಿದು ನಿಯಂತ್ರಣ ಉಲ್ಲಂಘನೆಗಳು, ಹಣಕಾಸು ನಷ್ಟಗಳು ಮತ್ತು ಸರಿಪಡಿಸಲಾಗದ ಬ್ರ್ಯಾಂಡ್ ಹಾನಿಯವರೆಗೆ ಇರಬಹುದು.
ದೌರ್ಬಲ್ಯಗಳನ್ನು ಮೊದಲೇ ಪತ್ತೆಹಚ್ಚುವುದು, ವಾಸ್ತವಿಕ ದಾಳಿ ಮಾದರಿಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಮತ್ತು ನಿಯಂತ್ರಕರು ಅತ್ಯಂತ ಗಂಭೀರವಾಗಿ ಪರಿಗಣಿಸುವ AI ಸುರಕ್ಷತಾ ನಿರೀಕ್ಷೆಗಳನ್ನು ಪೂರೈಸಲು ಸಂಸ್ಥೆಗೆ ನೆರವಾಗುವುದು ನಮ್ಮ ಗುರಿಯಾಗಿತ್ತು.
ಇಲ್ಲಿ ಗಮನಿಸಬೇಕಾದ ಒಂದು ವ್ಯತ್ಯಾಸವಿದೆ: ಜೈಲ್‌ಬ್ರೇಕ್ ದಾಳಿಯು ಆಧಾರವಾಗಿರುವ ಮಾಡೆಲ್‌ನ ಸುರಕ್ಷತಾ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಗುರಿಯಾಗಿಸುತ್ತದೆ; ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್ ದಾಳಿಯು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಬಳಕೆದಾರ ಇನ್‌ಪುಟ್ ಅನ್ನು ಡೆವಲಪರ್‌ನ ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರಾಂಪ್ಟ್ ಜೊತೆಗೆ ಸೇರಿಸಿ ಅನ್ವಯವನ್ನೇ ಗುರಿಯಾಗಿಸುತ್ತದೆ. ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್ ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ ಮಾಡೆಲ್ ಬದಲಿಗೆ ನಿಮ್ಮ ವ್ಯವಸ್ಥೆ ಮತ್ತು ಅದು ನಿರ್ವಹಿಸುವ ಗೌಪ್ಯ ದತ್ತಾಂಶವನ್ನೇ ಗುರಿಯಾಗಿಸುವುದರಿಂದ ಹೆಚ್ಚಿನ ಅಪಾಯವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ನಮ್ಮ ಮೊದಲ ಸುತ್ತಿನ ಪರೀಕ್ಷೆಯು ಈ ಕೆಳಗಿನ ವಿಭಾಗಗಳಲ್ಲಿ ಸುಮಾರು 750 ಪರೀಕ್ಷೆಗಳನ್ನು ಒಳಗೊಂಡಿತ್ತು:
ಸೆಷನ್‌ಗಳ ನಡುವಿನ ದತ್ತಾಂಶ ಸೋರಿಕೆ
ವೈಯಕ್ತಿಕ ಗುರುತು ದತ್ತಾಂಶದ ಬಹಿರಂಗಪಡಿಸುವಿಕೆ (ಸಹಜ ಭಾಷೆ, API ತಿರುಚುವಿಕೆ ಮತ್ತು ವಿವಿಧ ಎನ್‌ಕೋಡಿಂಗ್‌ಗಳ ಮೂಲಕ)
SQL ಇಂಜೆಕ್ಷನ್
ಸಿಸ್ಟಂ ಪ್ರಾಂಪ್ಟ್ ಅತಿಕ್ರಮಣಗಳು
ಆ ಆರಂಭಿಕ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದ ವ್ಯವಸ್ಥೆಯ ಎರಡು ಪ್ರಮುಖ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸಿದೆವು: ಬಹು-ಉದ್ದೇಶದ ಪ್ರಶ್ನೆಗಳ ನಿರ್ವಹಣೆ ಮತ್ತು ಎನ್‌ಕೋಡ್ ಮಾಡಿದ ಪ್ರಾಂಪ್ಟ್‌ಗಳ ಬಳಕೆ.
ಬಹು-ಉದ್ದೇಶದ ಪ್ರಶ್ನೆಗಳು: ನ್ಯಾಯಸಮ್ಮತ ಮತ್ತು ದುರುದ್ದೇಶಪೂರಿತ ಬೇಡಿಕೆಗಳನ್ನು ಒಂದೇ ವಿನಂತಿಯಲ್ಲಿ ಸೇರಿಸುವುದು. ಉದಾಹರಣೆಗೆ: “ವರ್ಗವಾರು ನನ್ನ ಖರ್ಚನ್ನು ತೋರಿಸಿ, ಜೊತೆಗೆ [ದುರುದ್ದೇಶಪೂರಿತ SQL] ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ.” ಅನ್ವಯವು ದುರುದ್ದೇಶವನ್ನು ಪತ್ತೆಹಚ್ಚದೆ, ನಂತರದ ದತ್ತಾಂಶ ಪದರದ ಸುರಕ್ಷತಾ ತಡೆಗಳನ್ನೇ ಸಂಪೂರ್ಣವಾಗಿ ಅವಲಂಬಿಸಿತ್ತು. ಇದು ನೆಲಮಾಳಿಗೆಯಲ್ಲಿರುವ ಭದ್ರಪೆಟ್ಟಿಗೆಯನ್ನು ನಂಬಿ ಮನೆಯ ಮುಂಬಾಗಿಲನ್ನು ತೆರೆದಿಡುವುದಕ್ಕೆ ಸಮಾನವಾಗಿದೆ.
ಎನ್‌ಕೋಡಿಂಗ್: ವಿನಂತಿಗಳನ್ನು Base64, Hex, LeetSpeak ಮತ್ತು ಹೋಮೋಗ್ಲಿಫ್‌ಗಳಲ್ಲಿ ಎನ್‌ಕೋಡ್ ಮಾಡುವುದು. ಇಂತಹ ವಿನಂತಿಗಳಲ್ಲಿನ ದುರುದ್ದೇಶವನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವುದು ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಕಷ್ಟವಾಗಬಹುದು. ಈ ಪ್ರಶ್ನೆಗಳು ಸೂಕ್ಷ್ಮ ದತ್ತಾಂಶವನ್ನು ಬಹಿರಂಗಪಡಿಸದಿದ್ದರೂ, ವ್ಯವಸ್ಥೆಯನ್ನು ಗಣನೀಯವಾಗಿ ಅಸ್ಥಿರಗೊಳಿಸಿದವು ಎಂಬುದು ಕಂಡುಬಂತು (ಭ್ರಮಾತ್ಮಕ ಉತ್ತರಗಳು, ದುರುದ್ದೇಶಪೂರಿತ SQL ಅನ್ನು ಬಳಕೆದಾರರಿಗೆ ಹಾಗೆಯೇ ಹಿಂತಿರುಗಿಸುವುದು, ಗೊಂದಲಮಯ ಉದ್ದೇಶ ವರ್ಗೀಕರಣ ಮುಂತಾದವು).
ನಮ್ಮ ಆರಂಭಿಕ ಪರೀಕ್ಷೆಯ ಫಲಿತಾಂಶಗಳು ಹೀಗಿದ್ದವು:
ಕಾಲಸಂಬಂಧಿ ಭ್ರಮಾತ್ಮಕ ಉತ್ತರಗಳು: ಮಾಡೆಲ್ ಕಟ್ಟುಕಥೆಯ ದಿನಾಂಕಗಳು, ವಹಿವಾಟಿನ ಸಮಯಮುದ್ರೆಗಳು ಅಥವಾ ನಿರ್ದಿಷ್ಟ ಅವಧಿಯ ಸಾರಾಂಶಗಳನ್ನು ದೃಢವಾಗಿ ಹೇಳುವುದು. ತಪ್ಪು ದಿನಾಂಕವನ್ನು ಆಧರಿಸಿ ಗ್ರಾಹಕರು ಕ್ರಮ ಕೈಗೊಂಡರೆ ನೈಜ ಪರಿಣಾಮಗಳು ಉಂಟಾಗಬಹುದಾದ ಹಣಕಾಸು ಸನ್ನಿವೇಶದಲ್ಲಿ ಇದು ಗಮನಾರ್ಹ ಅಪಾಯವಾಗಿದೆ
ದುರುದ್ದೇಶಪೂರಿತ SQL ಅನ್ನು ಬಳಕೆದಾರರಿಗೆ ಹಾಗೆಯೇ ಹಿಂತಿರುಗಿಸುವುದು (ಮೆಮೊರಿ ವಿಷಗೊಳಿಸುವಿಕೆಯ ಅಪಾಯದ ದೃಷ್ಟಿಯಿಂದ ಕಳವಳಕಾರಿ)
ಗೊಂದಲಮಯ ಉದ್ದೇಶ ವರ್ಗೀಕರಣ
ಅಸ್ತವ್ಯಸ್ತ ಔಟ್‌ಪುಟ್ ಸ್ವರೂಪ
ಆ ಸಂಶೋಧನೆಗಳ ಆಧಾರದಲ್ಲಿ ನಾವು ನಮ್ಮ ಗಮನವನ್ನು ಕೇಂದ್ರೀಕರಿಸಿದೆವು. SQL ಇಂಜೆಕ್ಷನ್ ಮತ್ತು ಎನ್‌ಕೋಡಿಂಗ್ ಪರೀಕ್ಷೆಗಳಿಗೆ ಕಡಿಮೆ ಆದ್ಯತೆ ನೀಡಲಾಯಿತು (ತಂಡವು ಈಗಾಗಲೇ ಅವುಗಳನ್ನು ಸರಿಪಡಿಸುತ್ತಿತ್ತು). ಬದಲಾಗಿ, ಹೆಚ್ಚು ಯಶಸ್ವಿಯಾದ ದಾಳಿ ಮಾರ್ಗಗಳಾದ ವೈಯಕ್ತಿಕ ಗುರುತು ದತ್ತಾಂಶದ ಬಹಿರಂಗಪಡಿಸುವಿಕೆ ಮತ್ತು ಸೆಷನ್‌ಗಳ ನಡುವಿನ ಸೋರಿಕೆಯ ಮೇಲೆ ಗಮನ ಕೇಂದ್ರೀಕರಿಸಿದೆವು.
ಎರಡನೇ ಸುತ್ತಿನ ಅತ್ಯಂತ ಗಮನಾರ್ಹ ಸಂಶೋಧನೆ ಆಶ್ಚರ್ಯಕರವಾಗಿ ಸರಳವಾಗಿತ್ತು: ಅನೇಕ ಬಾರಿ ಯಾವುದೇ ಚಾಣಾಕ್ಷ ತಂತ್ರವೇ ಬೇಕಾಗುವುದಿಲ್ಲ.
ಅನೇಕ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನ್ಯಾಯಸಮ್ಮತವೆಂದು ತೋರುವ ವಿನಂತಿಯ ಭಾಗವಾಗಿ ಆಂತರಿಕ ದತ್ತಾಂಶವನ್ನು ಸರಳವಾಗಿ ಕೇಳುವುದೇ ಅದನ್ನು ಬಹಿರಂಗಪಡಿಸಲು ವ್ಯವಸ್ಥೆ ಒಪ್ಪಿಕೊಳ್ಳುವಂತೆ ಮಾಡಲು ಸಾಕಾಗಿತ್ತು. ಸರಳ ಪ್ರಶ್ನೆಗಳಿಗೂ ಅಂತಿಮ ಬಳಕೆದಾರರಿಗೆ ಎಂದಿಗೂ ಕಾಣಿಸಬಾರದ ಆಂತರಿಕ ಗುರುತುಗಳು ಮತ್ತು ಸಿಸ್ಟಂ ಫೀಲ್ಡ್‌ಗಳನ್ನು ಉಲ್ಲೇಖಿಸುವ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಬರುತ್ತಿದ್ದವು.
ಇನ್ನಷ್ಟು ಆಳವಾಗಿ ಪರಿಶೀಲಿಸಿದಾಗ, ಇದು ಕೇವಲ ಅನ್ವಯ ಮಟ್ಟದ ವೈಫಲ್ಯವಲ್ಲ ಎಂಬುದು ತಿಳಿಯಿತು. ನಂತರದ ಪಠ್ಯದಿಂದ-SQL ಸೇವೆಯು ಅಗತ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಫೀಲ್ಡ್‌ಗಳನ್ನು ಕೇಳುವ ಪ್ರಶ್ನೆಗಳನ್ನು ರಚಿಸುತ್ತಿತ್ತು ಮತ್ತು ಅದರ ವಿವರಣಾತ್ಮಕ ಪ್ರತಿಕ್ರಿಯೆಗಳು ನಿರ್ಬಂಧಿಸಬೇಕಾಗಿದ್ದ ದತ್ತಾಂಶವನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತಿದ್ದವು. ಇದು ವ್ಯವಸ್ಥೆಗಳ ನಡುವಿನ ನೈಜ ಬಿರುಕನ್ನು ಬಹಿರಂಗಪಡಿಸಿತು. ಪ್ರತ್ಯೇಕ ಘಟಕಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸುವ ಬದಲು ಸಂಪೂರ್ಣ ತಂತ್ರಜ್ಞಾನ ಪದರವನ್ನು ಪರೀಕ್ಷಿಸಿದಾಗ ಮಾತ್ರ ಇಂತಹ ದೌರ್ಬಲ್ಯ ಗೋಚರಿಸುತ್ತದೆ.
ಮಾಡೆಲ್‌ಗಲ್ಲ, ವ್ಯವಸ್ಥೆಗೆ ರೆಡ್ ಟೀಮಿಂಗ್ ನಡೆಸಿ. LLM ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸುವುದರಿಂದ ನಿಮ್ಮ ಅನ್ವಯದ ಭದ್ರತಾ ಸ್ಥಿತಿಯ ಕುರಿತು ಬಹಳ ಕಡಿಮೆ ಮಾಹಿತಿ ಸಿಗುತ್ತದೆ. ಬಳಕೆದಾರರು ಸಂವಹಿಸುವಂತೆಯೇ, ಸಂಪೂರ್ಣ ತಂತ್ರಜ್ಞಾನ ಪದರವನ್ನು ಮೊದಲಿನಿಂದ ಕೊನೆಯವರೆಗೆ ಪರೀಕ್ಷಿಸಿ.
ಇನ್‌ಪುಟ್ ಮೌಲ್ಯೀಕರಣವು LLM ತಲುಪುವ ಮೊದಲೇ ನಡೆಯಬೇಕು. ಎನ್‌ಕೋಡ್ ಮಾಡಿದ ಪ್ರಶ್ನೆಗಳು, ಬಹು-ಉದ್ದೇಶದ ದಾಳಿಗಳು ಮತ್ತು ಮೂಲಭೂತ ಇಂಜೆಕ್ಷನ್ ಪ್ರಯತ್ನಗಳನ್ನು ಹೊರವಲಯದಲ್ಲೇ ಪತ್ತೆಹಚ್ಚಬೇಕು; ನಂತರದ ಸೇವೆಗಳಿಗೆ ವಹಿಸಬಾರದು.
ವ್ಯವಸ್ಥೆಗಳ ನಡುವಿನ ಜೋಡಣೆಗಳನ್ನು ನಂಬಬೇಡಿ. ಬಹು-ಸೇವಾ ವಿನ್ಯಾಸಗಳಲ್ಲಿ ಅತ್ಯಂತ ಗಮನಾರ್ಹ ದೌರ್ಬಲ್ಯಗಳು ವ್ಯವಸ್ಥೆಗಳ ನಡುವಿನ ಬಿರುಕುಗಳಲ್ಲೇ ಅಡಗಿರುತ್ತವೆ. ಶೂನ್ಯ-ವಿಶ್ವಾಸ ಎಂದರೆ ಯಾವುದನ್ನೂ ನಂಬದಿರುವುದು; ಆದ್ದರಿಂದ ಪ್ರತಿಯೊಂದು ಪದರದಲ್ಲೂ ಎಲ್ಲವನ್ನೂ ಮೌಲ್ಯೀಕರಿಸಿ.
ಸರಳ ದಾಳಿಗಳೂ ಯಶಸ್ವಿಯಾಗುತ್ತವೆ. ಅತ್ಯಾಧುನಿಕ ಜೈಲ್‌ಬ್ರೇಕ್‌ಗಳು ಸುದ್ದಿಯಾಗುತ್ತವೆ, ಆದರೆ ಕೆಲವೊಮ್ಮೆ ನೀವು ಸುಮ್ಮನೆ... ಕೇಳಿದರೆ ಸಾಕು. ಇತರ ರೀತಿಯಲ್ಲಿ ನ್ಯಾಯಸಮ್ಮತವಾಗಿರುವ ಪ್ರಶ್ನೆಯಲ್ಲಿ ಬಳಕೆದಾರರು ಆಂತರಿಕ ಗುರುತುಗಳನ್ನು ಸೇರಿಸಿದಾಗ ನಿಮ್ಮ ವ್ಯವಸ್ಥೆ ಅವುಗಳನ್ನು ಸುಲಭವಾಗಿ ಬಹಿರಂಗಪಡಿಸಿದರೆ, ಅದು ಸಮಸ್ಯೆಯಾಗಿದೆ.
ನೀವು ನಿಜವಾಗಿ ಏನನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ. ತಿಳಿದಿರುವ ದಾಳಿ ಮಾದರಿಗಳನ್ನು ನಿಮ್ಮ ಸುರಕ್ಷತಾ ತಡೆಗಳ ಬದಲು LLMನ ಸ್ವಂತ ತರಬೇತಿಯೇ ಪತ್ತೆಹಚ್ಚುತ್ತಿರಬಹುದು. ನಿಜವಾಗಿ ಯಾವ ನಿಯಂತ್ರಣಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಿಮ್ಮ ರೆಡ್ ಟೀಮಿಂಗ್‌ನಲ್ಲಿ ವೀಕ್ಷಣಾ ಸಾಮರ್ಥ್ಯವನ್ನು ಅಳವಡಿಸಿ.
ನಿರ್ಬಂಧಿತ ಪರಿಸರಗಳಿಗೆ ಸೃಜನಾತ್ಮಕ ಪರಿಹಾರಗಳು ಅಗತ್ಯ. ಕಸ್ಟಮ್ ಪೂರೈಕೆದಾರರು ಮತ್ತು ಸ್ಥಳೀಯ ಮಾಡೆಲ್ ಬೆಂಬಲವು ವಿಶೇಷ ಕ್ಲೌಡ್ ಪ್ರವೇಶವಿಲ್ಲದೆಯೂ ಅರ್ಥಪೂರ್ಣ ರೆಡ್ ಟೀಮಿಂಗ್ ನಡೆಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತವೆ. ಆದರೆ ಇದರಿಂದ ಉಂಟಾಗುವ ಮಿತಿಗಳ ಕುರಿತು ಪಾರದರ್ಶಕವಾಗಿರಿ.
ರೆಡ್ ಟೀಮಿಂಗ್ ಒಂದೇ ಬಾರಿಯ ಪ್ರಕ್ರಿಯೆಯಲ್ಲ. ಇದು ಪುನರಾವರ್ತಿತ ಪ್ರಕ್ರಿಯೆ; ಸಾಧ್ಯವಿರುವಲ್ಲಿ ಇದನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬೇಕು ಮತ್ತು ನಿಮ್ಮ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಇದೂ ವಿಕಸಿಸಬೇಕು. ನಾಳೆ ಮುಖ್ಯವಾಗುವ ದಾಳಿಗಳು ಇಂದು ಮುಖ್ಯವಾಗಿರುವ ದಾಳಿಗಳಂತೆಯೇ ಇರುವುದಿಲ್ಲ.
ನಿಯಂತ್ರಿತ ಪರಿಸರಗಳಲ್ಲಿನ AI ವ್ಯವಸ್ಥೆಗಳ ಮೇಲಿನ ಪರಿಶೀಲನೆ ಕಡಿಮೆಯಾಗದೆ ಇನ್ನಷ್ಟು ಹೆಚ್ಚಾಗಲಿದೆ. ಭದ್ರತಾ ಪರೀಕ್ಷೆಯನ್ನು ಬಿಡುಗಡೆಗೂ ಮುನ್ನ ಗುರುತು ಹಾಕಬೇಕಾದ ಪಟ್ಟಿಯ ಅಂಶವೆಂದು ಕಾಣದೆ, ನಿರಂತರ ಶಿಸ್ತಾಗಿ ಪರಿಗಣಿಸುವ ಸಂಸ್ಥೆಗಳು ಆ ಪರಿಶೀಲನೆಯನ್ನು ಎದುರಿಸಲು ಉತ್ತಮ ಸ್ಥಿತಿಯಲ್ಲಿರುತ್ತವೆ. ಜೊತೆಗೆ, ಗ್ರಾಹಕರ ವಿಶ್ವಾಸ ಕಳೆದುಕೊಳ್ಳುವ ಸಾರ್ವಜನಿಕ ಸಂಪರ್ಕ ವೈಫಲ್ಯಗಳನ್ನೂ ತಪ್ಪಿಸಬಹುದು.