ಇದು ಮೂರನೇ ಕಂತು a ನಲ್ಲಿ ಲೇಖನಗಳ ಸರಣಿ ಅತ್ಯಂತ ಪ್ರಚಲಿತ ರೀತಿಯ ಸಾಫ್ಟ್ವೇರ್ ಪೂರೈಕೆ ಸರಪಳಿ ದಾಳಿಗಳ ಬಗ್ಗೆ: ಸಾರ್ವಜನಿಕ ನೋಂದಾವಣೆಯನ್ನು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳುವವುಗಳು ಮುಕ್ತ ಸಂಪನ್ಮೂಲ ಸಾಫ್ಟ್ವೇರ್ ಘಟಕಗಳು. ಹಿಂದಿನ ಸಂಚಿಕೆಯಲ್ಲಿ ವಿಶ್ಲೇಷಿಸಿದ ನಂತರ “ದುರುದ್ದೇಶಪೂರಿತ ಪ್ಯಾಕೇಜ್ಗಳ ಅಂಗರಚನಾಶಾಸ್ತ್ರ: ಪ್ರವೃತ್ತಿಗಳು ಯಾವುವು?"ಕೆಟ್ಟ ನಟರು ಹೊಸ ಅಥವಾ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರಕಟಿತ ಘಟಕಗಳಿಗೆ ದುರುದ್ದೇಶಪೂರಿತ ನಡವಳಿಕೆಯನ್ನು ಹೇಗೆ ಸೇರಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಲು, ನಾವು ನಮ್ಮ ಅಗ್ನಿಶಾಮಕ ಜಾಕೆಟ್ಗಳನ್ನು ಹಾಕಲು ಮತ್ತು ಈ ರೀತಿಯಲ್ಲಿ ವಿತರಿಸಲಾದ ದುರುದ್ದೇಶಪೂರಿತ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ನಾವು ಹೇಗೆ ಯಶಸ್ವಿಯಾಗಿ ನಿರ್ಬಂಧಿಸಬಹುದು ಎಂಬುದನ್ನು ಪರೀಕ್ಷಿಸಲು ಸಿದ್ಧರಿದ್ದೇವೆ, ಅಥವಾ ಪರ್ಯಾಯವಾಗಿ, ನಾವು ತಪ್ಪು ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಂಡ ಕಾರಣ ಗಂಭೀರವಾದ ಸೈಬರ್ ಘಟನೆಯನ್ನು ಹೇಗೆ ಎದುರಿಸಬಹುದು ಎಂಬುದನ್ನು ಪರೀಕ್ಷಿಸಲು ಸಿದ್ಧರಿದ್ದೇವೆ."
ಈ ಬೆದರಿಕೆಯನ್ನು ಹೇಗೆ ನಿಭಾಯಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಹೆಚ್ಚಿನ ಭದ್ರತಾ ಅರಿವುಳ್ಳ ವೃತ್ತಿಪರರು ಆಲೋಚನೆಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಭದ್ರತಾ ವ್ಯವಸ್ಥಾಪಕರು ಹಿಂಜರಿಕೆಯಿಲ್ಲದೆ ಹೇಳುವುದನ್ನು ನಾವು ಕೇಳಿದ್ದೇವೆ SCA ಪ್ಯಾಕೇಜ್ ಆವೃತ್ತಿಯು ಮಾಲ್ವೇರ್ ಆಗಿರುವಾಗ ಪರಿಕರಗಳು ಈಗಾಗಲೇ ನಿಮಗೆ ತಿಳಿಸುತ್ತವೆ. ಅಥವಾ ಅವು ಪ್ರಸಿದ್ಧ, ಹೆಚ್ಚು ಪರಿಶೀಲಿಸಿದ ಸಾಫ್ಟ್ವೇರ್ ಘಟಕಗಳನ್ನು ಅವಲಂಬಿಸಿವೆ, ಅಲ್ಲಿ ಯಾವುದೇ ಮಾಲ್ವೇರ್ ಅನ್ನು ತಕ್ಷಣವೇ ಪತ್ತೆಹಚ್ಚಲಾಗುತ್ತದೆ ಮತ್ತು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ. ದುರ್ಬಲತೆ ಪರಿಹಾರಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪಡೆಯಲು ಅವರು ತೆರೆದ ಮೈನರ್/ಪ್ಯಾಚ್ ಆವೃತ್ತಿಗಳನ್ನು ಬಳಸುತ್ತಾರೆ ಮತ್ತು ಅದು ತೆರೆದ ಮೂಲ ಅವಲಂಬನೆಗಳ ಮೇಲಿನ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಸರಿಯಾದ, ಶಿಫಾರಸು ಮಾಡಲಾದ ಮಾರ್ಗವಾಗಿದೆ, "ಬೇಗ ತೇಪೆ ಹಾಕು, ಆಗಾಗ್ಗೆ ತೇಪೆ ಹಾಕು”ತತ್ವ.
ಈ ಸಂಚಿಕೆಯಲ್ಲಿ, ಈ ವಿಚಾರಗಳು ಏಕೆ ತಪ್ಪಾಗಿವೆ, ಮತ್ತು ಅಂತಹ ತಪ್ಪು ಕಲ್ಪನೆಗಳು ಈ ದಾಳಿ ಕಾರ್ಯವಿಧಾನದ ಜನಪ್ರಿಯತೆಗೆ ಮತ್ತು ಸಂಸ್ಥೆಗಳು ಅನುಭವಿಸುತ್ತಿರುವ ಅಗಾಧ ಅಪಾಯಕ್ಕೆ ಹೇಗೆ ಕೊಡುಗೆ ನೀಡುತ್ತಿವೆ ಎಂಬುದನ್ನು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಏನು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಯಾವುದು ಒಳಗೊಂಡಿರುವ ಪ್ರಯತ್ನ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳು ಎಂಬುದರೊಂದಿಗೆ ನಾವು ಮುಕ್ತಾಯಗೊಳಿಸುತ್ತೇವೆ.
ಸಾಮಾನ್ಯ ತಪ್ಪುಗ್ರಹಿಕೆಗಳು
ಸಾಫ್ಟ್ವೇರ್ ಭದ್ರತೆಯೊಂದಿಗಿನ ನಮ್ಮ ಪ್ರಯಾಣದ ಸಮಯದಲ್ಲಿ, ದಾಳಿಯ ತಂತ್ರಗಳು ವಿಕಸನಗೊಳ್ಳುವುದನ್ನು ಮತ್ತು ಭದ್ರತಾ ಪ್ರಜ್ಞೆಯ ಜನರಿಂದ ವ್ಯಾಪಕವಾದ ವಿಚಾರಗಳನ್ನು ನಾವು ನೋಡಿದ್ದೇವೆ. ಸಂಸ್ಥೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಈ ಬೆದರಿಕೆಯ ವಿರುದ್ಧ ಏನು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಿಕೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಮೊದಲು ನಾವು ಏನು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ, ಇದನ್ನು ಈ ಕೆಳಗಿನ, ಸಮಗ್ರವಲ್ಲದ, ತಪ್ಪು ಕಲ್ಪನೆಗಳ ಪಟ್ಟಿಯಲ್ಲಿ ಸಂಕ್ಷೇಪಿಸುತ್ತೇವೆ.
ತಪ್ಪು ಕಲ್ಪನೆ # 1: SCA ಉಪಕರಣಗಳು ಈಗಾಗಲೇ ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತವೆ
ವಾಸ್ತವವಾಗಿ! ಆದರೆ ವಾಸ್ತವದ ನಂತರ… ಸಾಫ್ಟ್ವೇರ್ ನಿರ್ಮಾಣದಲ್ಲಿ ಅಂಶವನ್ನು ಬಳಸಿದ್ದರೆ ಮತ್ತು ಕೆಟ್ಟ ನಟರು ಈಗಾಗಲೇ ಡೆವಲಪರ್ನಲ್ಲಿ ನೆಲೆಗೊಂಡಿದ್ದರೆ ಅಥವಾ CI/CD ಹೋಸ್ಟ್. ರಹಸ್ಯಗಳನ್ನು ಹೊರಹಾಕಿರಬಹುದು, ಹೆಚ್ಚುವರಿ ಮಾಲ್ವೇರ್ ಡೌನ್ಲೋಡ್ ಮಾಡಿ ಸ್ಥಾಪಿಸಿರಬಹುದು ಮತ್ತು ಬಹುಶಃ ಎದುರಾಳಿಯು ಪಕ್ಕಕ್ಕೆ ಸರಿದು ಈಗಾಗಲೇ ಬೇರೆಡೆ ಪ್ರವೇಶ ಪಡೆದಿರಬಹುದು.
ಸಾಫ್ಟ್ವೇರ್ ಸಂಯೋಜನೆ ವಿಶ್ಲೇಷಣೆ (SCA) ಸಂಭಾವ್ಯ ತಿಳಿದಿರುವ ದುರ್ಬಲತೆಗಳನ್ನು ಗುರುತಿಸಲು ಪರಿಕರಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಆಧುನಿಕ ಪರಿಕರಗಳು ಸಿಗ್ನಲ್-ಶಬ್ದ ಅನುಪಾತವನ್ನು ಹೆಚ್ಚಿಸುವ ಮೂಲಕ ಉತ್ತಮ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ದುರ್ಬಲತೆಯು ನಿಜವಾಗಿಯೂ ತಲುಪಬಹುದೇ ಅಥವಾ ಬಳಸಿಕೊಳ್ಳಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಆದರೆ ಅವು ಹೊಸ ಮಾಲ್ವೇರ್ ವಿರುದ್ಧ ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿವೆ. ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕವನ್ನು ಶೂನ್ಯ-ದಿನದ ದುರ್ಬಲತೆ ಎಂದು ಪರಿಗಣಿಸಿ: ಅದರ ದುರುದ್ದೇಶಪೂರಿತ ನಡವಳಿಕೆ ಪತ್ತೆಯಾದಾಗ ಮಾತ್ರ, ಘಟಕವನ್ನು ಹೋಲ್ಡಿಂಗ್ ರಿಜಿಸ್ಟ್ರಿಗೆ ವರದಿ ಮಾಡಲಾಗುತ್ತದೆ, ಭದ್ರತಾ ತಂಡವು ಪರಿಶೀಲಿಸಿದ ನಂತರ ದುರುದ್ದೇಶಪೂರಿತವೆಂದು ದೃಢೀಕರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ರಿಜಿಸ್ಟ್ರಿಯಿಂದ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ. [1].
ಆ ಸಮಯದಲ್ಲಿ, ಜಗತ್ತು (ಸೇರಿದಂತೆ SCAs) ಘಟಕವನ್ನು (ಅಥವಾ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಘಟಕದ ಕೆಲವು ಆವೃತ್ತಿ(ಗಳು)) ಸ್ಥಾಪಿಸುವುದು ಅಥವಾ ಬಳಸುವುದು ಒಳ್ಳೆಯದಲ್ಲ ಎಂದು ತಿಳಿದಿದೆ. ಆದರೆ ಇದು ಘಟಕವು ನೋಂದಾವಣೆಯಿಂದ ಲಭ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಸಂಭವಿಸುತ್ತದೆ.. ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಘಟಕಗಳಲ್ಲಿ ಅಥವಾ ನೋಂದಾವಣೆಯಿಂದ ದುರುದ್ದೇಶಪೂರಿತ ಎಂದು ವರ್ಗೀಕರಿಸಲಾದ ಘಟಕಗಳಲ್ಲಿ ನನಗೆ ದುರ್ಬಲತೆಗಳಿವೆ ಎಂದು ತಿಳಿದುಕೊಳ್ಳುವುದು ಒಳ್ಳೆಯದು, ಆದರೆ ದುರದೃಷ್ಟವಶಾತ್ SCA ಅಥವಾ ಸಾಮಾನ್ಯ ಆಡಿಟ್ ಪರಿಕರಗಳು ಈ ಸಂದರ್ಭದಲ್ಲಿ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಹೊರತು SCA/audit ಉಪಕರಣವು ನಿಮ್ಮ ಸಂಸ್ಥೆಯಲ್ಲಿ ಒಂದು ಘಟಕವನ್ನು ಬಳಸುವ ಮೊದಲು ಅದು ದುರುದ್ದೇಶಪೂರಿತವಾಗಿದೆ ಎಂದು ನಿಜವಾಗಿಯೂ ಮೊದಲೇ ತಿಳಿದುಕೊಳ್ಳಬಹುದು..
ನೆನಪಿಡಿ, ದುರುದ್ದೇಶಪೂರಿತ ಮುಕ್ತ-ಮೂಲ ಘಟಕಗಳ ವಿರುದ್ಧದ ಯಾವುದೇ ಪರಿಹಾರವು ಅವುಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಬೇಕು ಹಾರಾಡುತ್ತಿರುವಾಗ, ಘಟಕವನ್ನು ನೋಂದಾವಣೆಯಲ್ಲಿ ಪ್ರಕಟಿಸಿದಾಗ ಮತ್ತು ನಿಮ್ಮ ಸಂಸ್ಥೆಯಲ್ಲಿ ಘಟಕವನ್ನು (ಆವೃತ್ತಿ) ಮೊದಲು ಬಳಸಿದಾಗ ನಡುವೆ. ಮತ್ತು ಅದು ಟ್ರಾನ್ಸಿಟಿವ್ ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.
ತಪ್ಪು ಕಲ್ಪನೆ #2: ನಿರ್ಮಾಣ ಸಮಯದಲ್ಲಿ ಅನುಸ್ಥಾಪನಾ ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ನಿಯಂತ್ರಿಸುವುದರಿಂದ ಮುಕ್ತ ಮೂಲ ಘಟಕಗಳಿಂದ ದುರುದ್ದೇಶಪೂರಿತ ನಡವಳಿಕೆಯನ್ನು ತಡೆಯುತ್ತದೆ.
ವಿವಿಧ ಪ್ಯಾಕೇಜ್ ವ್ಯವಸ್ಥಾಪಕರು ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ಚಲಾಯಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನೀಡುತ್ತಾರೆ (ಕಾಂಪೊನೆಂಟ್ ಟಾರ್ಬಾಲ್ನಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ [2]), ವಿವಿಧ ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳಲ್ಲಿ ಅಗತ್ಯವಿರುವ ವಸ್ತುಗಳನ್ನು ಕಂಪೈಲ್ ಮಾಡುವುದು, ಕೋಡ್ ರಚಿಸುವುದು ಅಥವಾ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವುದು ಮುಂತಾದ ಕಾನೂನುಬದ್ಧ ಕಾರಣಗಳಿಗಾಗಿ, ಮತ್ತು ಟಾರ್ಬಾಲ್ನಲ್ಲಿ ದುರುದ್ದೇಶಪೂರಿತ ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ಸೇರಿಸಿದರೆ ಅಥವಾ ಆಕ್ರಮಣಕಾರನು ಒಳ್ಳೆಯದಕ್ಕೆ ಬದಲಾಗಿ ದುರುದ್ದೇಶಪೂರಿತ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಚಲಾಯಿಸಿದರೆ ಕೆಟ್ಟ ನಟರು ಅವುಗಳನ್ನು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳಬಹುದು ಎಂದು ನಾವೆಲ್ಲರೂ ತಿಳಿದಿರಬೇಕು.
ಇದನ್ನು ತಿಳಿದುಕೊಂಡು, ನಾವು ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಅನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವಂತೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಉದಾಹರಣೆಗೆ, NPM ನೊಂದಿಗೆ -ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಿ ಫ್ಲ್ಯಾಗ್ (ಅಥವಾ ಒಂದು ಸಂರಚನಾ ಆಸ್ತಿಯಲ್ಲಿ .ಎನ್ಪಿಎಂಆರ್ಸಿ file) ಅನುಸ್ಥಾಪನೆಯ ಸಮಯದಲ್ಲಿ ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ. ಇದು ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು ಏಕೆಂದರೆ ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ಚಲಾಯಿಸುವುದು ಅನೇಕ ಪರಿಸರ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿದೆ: ಕೆಲವು ಪ್ಯಾಕೇಜ್ ವ್ಯವಸ್ಥಾಪಕರು ಸ್ಕ್ರಿಪ್ಟ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ಸಹ ಅನುಮತಿಸುವುದಿಲ್ಲ (ಸುಳಿವು: ಪ್ರಾಂಪ್ಟ್ “ಯಾವ ಪ್ಯಾಕೇಜ್ ವ್ಯವಸ್ಥಾಪಕರು ಅನುಸ್ಥಾಪನಾ ಸ್ಕ್ರಿಪ್ಟ್ಗಳ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ಅನುಮತಿಸುವುದಿಲ್ಲ?ನಿಮ್ಮ ನೆಚ್ಚಿನ AI ನಲ್ಲಿ ”). ಆದರೆ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ರಕ್ಷಿಸುವುದಿಲ್ಲ (ಸ್ಕಿಪ್ ಡಿಸೇಬಲ್ ಕಾನ್ಫಿಗರೇಶನ್ ಎಲ್ಲೆಡೆ ಇರಬೇಕೆಂದು ನಾವು ಜಾರಿಗೊಳಿಸಬೇಕಾಗಿದೆ).
ಮತ್ತು ದುರುದ್ದೇಶಪೂರಿತ ನಡವಳಿಕೆಯು ಇನ್ಸ್ಟಾಲ್ ಸ್ಕ್ರಿಪ್ಟ್ಗಳಲ್ಲಿ ಇಲ್ಲದೆ ರನ್ಟೈಮ್ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾದ ಸಾಫ್ಟ್ವೇರ್ನಲ್ಲಿದ್ದಾಗ, ಈ ಆಯ್ಕೆಯು ಮಾತ್ರ ನಮ್ಮನ್ನು ರಕ್ಷಿಸುವುದಿಲ್ಲ.
ತಪ್ಪು ಕಲ್ಪನೆ #3: ಆವೃತ್ತಿ ಪಿನ್ನಿಂಗ್ ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳನ್ನು ಸ್ಥಾಪಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ.
ಮೊದಲೇ ಪ್ಯಾಚ್ ಮಾಡುವುದರ ನಡುವೆ ಮತ್ತು ಆಗಾಗ್ಗೆ ಮುಕ್ತ ಆವೃತ್ತಿಗಳು (ಭದ್ರತಾ ಪರಿಹಾರಗಳಿಗಾಗಿ ಲಭ್ಯವಿರುವಾಗ ಪ್ಯಾಕೇಜ್ ವ್ಯವಸ್ಥಾಪಕವು ಹೊಸ ನವೀಕರಣಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸ್ಥಾಪಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ) ಮತ್ತು ಆವೃತ್ತಿ ಪಿನ್ನಿಂಗ್ (ಸ್ಥಿರ ಆವೃತ್ತಿಯಲ್ಲಿ ಸಾಫ್ಟ್ವೇರ್ಗೆ ಎಲ್ಲಾ ನೇರ ಮತ್ತು ಸಕರ್ಮಕ ಅವಲಂಬನೆಗಳನ್ನು ಹೊಂದಿದೆ). ಭದ್ರತಾ ತತ್ವಗಳು ಹಠಮಾರಿ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ವಿರೋಧಾತ್ಮಕವಾಗಿವೆ, "ಮುಂಚಿತವಾಗಿ ಪ್ಯಾಚ್ ಮಾಡಿ, ಆಗಾಗ್ಗೆ ಪ್ಯಾಚ್ ಮಾಡಿ" ಮತ್ತು "ಅಪ್ಗ್ರೇಡ್ ಮಾಡುವುದನ್ನು ಹಗುರವಾಗಿ ಪರಿಗಣಿಸಬಾರದು". ಕೆಲವು ಪ್ಯಾಕೇಜ್ ವ್ಯವಸ್ಥಾಪಕರು ಶಿಫಾರಸು ಮಾಡಿದ ರೀತಿಯಲ್ಲಿ ಸರ್ವರ್ ಶ್ರೇಣಿಗಳೊಂದಿಗೆ ಸ್ವಯಂಚಾಲಿತ ನವೀಕರಣಗಳನ್ನು ಮಾಡುತ್ತಾರೆ. ನೀವು ದುರುದ್ದೇಶಪೂರಿತ ನವೀಕರಣಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಬಯಸಿದರೆ ಉತ್ತಮ! ಹೌದು, ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ದುರ್ಬಲತೆಗಳನ್ನು ಮುಚ್ಚುವ ಭದ್ರತಾ ಪರಿಹಾರಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಘಟಕಗಳನ್ನು ನವೀಕರಿಸಬೇಕು, ಆದರೆ ... ಪ್ಯಾಕೇಜ್ ವ್ಯವಸ್ಥಾಪಕರು ಇದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾಡಲು ಎಂದಿಗೂ ಬಿಡಬೇಡಿ.
ತಪ್ಪು ಕಲ್ಪನೆ #4: ವಿಶ್ವಾಸಾರ್ಹ ಘಟಕಗಳನ್ನು ಬಳಸುವುದು ಸುರಕ್ಷಿತ. ಯಾವುದೇ ದುರುದ್ದೇಶಪೂರಿತ ಆವೃತ್ತಿಯನ್ನು ತಕ್ಷಣವೇ ಕಂಡುಹಿಡಿಯಲಾಗುತ್ತದೆ, ಬಹಿರಂಗಪಡಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ.
ಒಂದು ಘಟಕವು ಏಕೆ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ? ಬಹುಶಃ ಅದು ಹೆಚ್ಚು ಜನಪ್ರಿಯವಾಗಿರುವುದರಿಂದ, ಅನೇಕರು ದುರ್ಬಲತೆಗಳನ್ನು ಹುಡುಕುತ್ತಿದ್ದಾರೆ, ನಿರ್ವಹಣೆಗಾಗಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಕೊಡುಗೆದಾರರು, ಬಹು ಪ್ರಮುಖ ನಿರ್ವಹಣಾಕಾರರು ಎಲ್ಲವನ್ನೂ ಶ್ರದ್ಧೆಯಿಂದ ಪರಿಶೀಲಿಸುತ್ತಾರೆ pull requests. ವಾಸ್ತವವು ತುಂಬಾ ಭಿನ್ನವಾಗಿದೆ. ಕೆಲವು ಅಗತ್ಯ ಘಟಕಗಳನ್ನು ಒಬ್ಬನೇ, ಪಾವತಿಸದ ಡೆವಲಪರ್ ನಿರ್ವಹಿಸುತ್ತಾರೆ. ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುವ ಚೌಕಟ್ಟುಗಳು ಕೆಲವು ನಿಯಮಿತ ಕೊಡುಗೆದಾರರು, ವೇಗವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತಿರುವ ಸಂಖ್ಯೆಯೊಂದಿಗೆ commitಪ್ರತಿ ನಿರ್ವಹಣಾಕಾರರಿಗೆ s (ಜನಪ್ರಿಯ ಯೋಜನೆಗಳು ಕೆಲವು ಡ್ರೈವ್-ಬೈ ನಿರ್ವಹಿಸುವ ಕೊಡುಗೆದಾರರ ಉದ್ದನೆಯ ಬಾಲವನ್ನು ಹೊಂದಿವೆ commit ಮತ್ತು ಎಂದಿಗೂ ಹಿಂತಿರುಗುವುದಿಲ್ಲ). ಮತ್ತು ಒಂದೇ ನಿರ್ವಹಣೆದಾರನನ್ನು ಹೊಂದಿರುವ ಜನಪ್ರಿಯ ಯೋಜನೆಗಳು ಹೇರಳವಾಗಿವೆ.
ನೀವೇ ಹೀಗೆ ಹೇಳುತ್ತಿದ್ದೀರಿ ಎಂದು ಊಹಿಸಿಕೊಳ್ಳಿ "ಓಹ್, ನಾವು ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ / ಆಂಗ್ಯುಲರ್ / ರಿಯಾಕ್ಟ್ / ಪೈಟಾರ್ಚ್ / ಅಧಿಕೃತ ಬೇಸ್ ಡಾಕರ್ ಚಿತ್ರಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ನೀವು ಮಾತನಾಡುತ್ತಿರುವ ಅಪಾಯವು ತುಂಬಾ ಕಡಿಮೆಯಾಗಿದೆ." ಬಹುಶಃ ಅದು ನಿಜ, ನಾವು ಭದ್ರತಾ ಮಾರಾಟಗಾರರು ಯಾವಾಗಲೂ ಹೆದರಿಸುತ್ತೇವೆ ಮತ್ತು ಚರ್ಚಾಸ್ಪದ ಅಪಾಯವನ್ನು ತಗ್ಗಿಸಲು ಅಭಿವೃದ್ಧಿ ತಂಡಗಳೊಂದಿಗೆ ಹಸ್ತಕ್ಷೇಪ ಮಾಡುವುದು ಅಸಂಬದ್ಧ. ಅಪಾಯ ಸ್ವೀಕಾರ ಪ್ಯಾರಾಗ್ರಾಫ್ಗೆ (ಮುಂದಿನ ವಿಭಾಗದಲ್ಲಿ) ಜಿಗಿಯಲು ನೀವು ಪ್ರಚೋದಿಸಲ್ಪಡಬಹುದು ಮತ್ತು ಎಲ್ಲವೂ ಮುಗಿದಿದೆ. ದುರದೃಷ್ಟವಶಾತ್, ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಘಟಕಗಳು ಕೆಟ್ಟ ನಟರಿಗೆ ಗುರಿಯಾಗುತ್ತವೆ, ಮತ್ತು ಉದಾಹರಣೆಗೆ, ಜನಪ್ರಿಯ ಪೈಟಾರ್ಚ್ ಗ್ರಂಥಾಲಯದ ಮೇಲೆ ದಾಳಿ ಮಾಡಲಾಯಿತು. ಹಳೆಗಾಲದಲ್ಲಿ.
"ತಕ್ಷಣ ಕಂಡುಬಂದಿದೆ, ಬಹಿರಂಗಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ತೆಗೆದುಹಾಕಲಾಗಿದೆ". ಸಾರ್ವಜನಿಕ ನೋಂದಾವಣೆಯಿಂದ ಹೊಸ ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕವನ್ನು ತೆಗೆದುಹಾಕಲು ದಿನಗಳು ಬೇಕಾಗುತ್ತದೆ. ಒಳ್ಳೆಯದಕ್ಕಾಗಿ, ಘಟಕ ಆವೃತ್ತಿಯನ್ನು ತೆಗೆದುಹಾಕುವ ಬಗ್ಗೆ ನೋಂದಣಿಗಳು ಜಾಗರೂಕರಾಗಿರುತ್ತವೆ. ನಮ್ಮ ಅನುಭವವೆಂದರೆ, ನಮ್ಮ ಕಡೆಯಿಂದ ಒಮ್ಮೆ ವರದಿ ಮಾಡಿದ ನಂತರ, ಪೀಡಿತ ಆವೃತ್ತಿಯನ್ನು ತೆಗೆದುಹಾಕಲು ನೋಂದಾವಣೆಗೆ ಸರಾಸರಿ ಸಮಯ 39 ಗಂಟೆಗಳು, ಒಂದೂವರೆ ದಿನಗಳಿಗಿಂತ ಹೆಚ್ಚು. ತೆಗೆದುಹಾಕುವ ಮೊದಲು ನೋಂದಾವಣೆಯಲ್ಲಿ ನಮ್ಮ ಆರಂಭಿಕ ವರದಿಯ ನಂತರ ಒಂದು ವಾರದ ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳಿವೆ. ಮತ್ತು ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಬಲಿಪಶು ಅಥವಾ ಘಟನೆ ಪ್ರತಿಕ್ರಿಯೆ ಕಂಪನಿಯು ಘಟಕವನ್ನು ಒಳಗೊಂಡ ಘಟನೆಯನ್ನು ವರದಿ ಮಾಡಿದ ನಂತರವೇ ಘಟಕವನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ.
ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳ ವಿರುದ್ಧ ಯಾವುದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ
ಯಾವುದೇ ನಿರ್ದಿಷ್ಟವಲ್ಲದ ವಿಧಾನವು ಶೋಚನೀಯವಾಗಿ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ. ಇದು ಖಚಿತ, ಈ ಬೆದರಿಕೆಗೆ ಸಂಬಂಧಿಸಿದ ಅಪಾಯಕ್ಕೆ ನೀವು ಪರಿಣಾಮಕಾರಿ ಪ್ರತಿಕ್ರಮಗಳನ್ನು ಒದಗಿಸುತ್ತಿಲ್ಲ.
ಸಾಂಪ್ರದಾಯಿಕ SCA ಪರಿಕರಗಳು ತಿಳಿದಿರುವ ಮಾಲ್ವೇರ್ ಬಗ್ಗೆ ನಿಮಗೆ ತಿಳಿಸುತ್ತವೆ ಆದರೆ ದೊಡ್ಡ ಎಕ್ಸ್ಪೋಸರ್ ವಿಂಡೋವನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಅವು ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳನ್ನು ಬಲವಂತವಾಗಿ ನಿರ್ಬಂಧಿಸುವುದರೊಂದಿಗೆ ಮಾಲ್ವೇರ್ ಪತ್ತೆಯನ್ನು ಪೂರ್ವಭಾವಿಯಾಗಿ ನಿರ್ವಹಿಸದ ಹೊರತು, ಅವು ಈ ಬೆದರಿಕೆಯ ವಿರುದ್ಧ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ.
ಅನುಸ್ಥಾಪನಾ ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಸಹಾಯ ಮಾಡಬಹುದು ಆದರೆ ಘಟಕವನ್ನು ಸ್ಥಾಪಿಸಬೇಕಾದ ಎಲ್ಲೆಡೆ ಅದನ್ನು ಜಾರಿಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ. ಆವೃತ್ತಿ ಪಿನ್ನಿಂಗ್ನಂತೆಯೇ, ಏಕೆಂದರೆ ಆವೃತ್ತಿಗಳನ್ನು ಸುರಕ್ಷಿತ ಆರಂಭಿಕ ಸ್ಥಿತಿಯಿಂದ ಶಾಶ್ವತವಾಗಿ ಪಿನ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಜನಪ್ರಿಯ ಘಟಕಗಳು ಸಾಕಷ್ಟು ಗಮನ ಸೆಳೆಯುತ್ತವೆ ಎಂದು ಊಹಿಸಿಕೊಳ್ಳುವುದು, ಪೂರೈಕೆ ಸರಪಳಿ ದಾಳಿಯಲ್ಲಿ ಯಾವುದೇ ಹಾನಿಯನ್ನು ತಡೆಗಟ್ಟಲು ಬಹುತೇಕ ತಕ್ಷಣದ ಪತ್ತೆ ಇಲ್ಲದೆ ಅನಪೇಕ್ಷಿತ ನಡವಳಿಕೆಯನ್ನು ಅವುಗಳಿಗೆ ಸೇರಿಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ಭಾವಿಸುವುದು ನಿಷ್ಕಪಟ ಮತ್ತು ಅಪಾಯಕಾರಿ. ನೀವು ಅಂಚಿನಲ್ಲಿ ಬದುಕಲು ಬಯಸುವುದಿಲ್ಲ, ಅಲ್ಲವೇ?
ನೀವು ಈ ಹಂತದಲ್ಲಿ ನಿಲ್ಲಿಸಿದರೆ, ಆಗ ಅಪಾಯ ಸ್ವೀಕಾರ ನೀವು ಮಾಡಬಹುದಾದ ಏಕೈಕ ವಿಷಯ: ಇದು ಒಂದು ಡಿcisಅಪಾಯವನ್ನು ಸ್ವೀಕರಿಸುವ ತಾರ್ಕಿಕತೆ ಮತ್ತು ಅದರ ಸಂಭಾವ್ಯ ಪರಿಣಾಮಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ನಿಮ್ಮ ಬೆದರಿಕೆ ಮಾದರಿ/ಅಪಾಯದ ಮೌಲ್ಯಮಾಪನದಲ್ಲಿ ದಾಖಲಿಸಬೇಕಾದ ಅಂಶಗಳು. ನಿರ್ವಹಣೆ ಮತ್ತು ಇತರ ಸಂಬಂಧಿತ ಪಕ್ಷಗಳಿಗೆ ತಿಳಿಸುವ ಮೂಲಕ ಜಾಗೃತಿ ಮೂಡಿಸಿ. ಕೆಲವು ಆಕಸ್ಮಿಕ ನಿಮ್ಮ ಸಾಫ್ಟ್ವೇರ್ನಲ್ಲಿ ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕವನ್ನು ಸ್ಥಾಪಿಸಿದಾಗ ಅಥವಾ ಸೇರಿಸಿದಾಗ ಯೋಜಿಸಬಹುದು, ಆದರೆ ದಾಳಿಕೋರರು ಅನುಸರಿಸಲು ಹಲವು ಮಾರ್ಗಗಳಿರುವುದರಿಂದ ಇದು ಕಷ್ಟ. ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕದ ಬಳಕೆಯನ್ನು ಆಧರಿಸಿದ ಪೂರೈಕೆ ಸರಪಳಿ ದಾಳಿಯ ವಿವರಗಳು ಘಟನೆಯ ಸಾರ್ವಜನಿಕ ಬಹಿರಂಗಪಡಿಸುವಿಕೆಯನ್ನು ತೀವ್ರವಾಗಿ ಬದಲಾಯಿಸುತ್ತವೆ, ಇದು ಬಹುಶಃ ನಿಮ್ಮ ಸಂಸ್ಥೆಯ ನಿಯಂತ್ರಕ ಚೌಕಟ್ಟಿನ ಅಡಿಯಲ್ಲಿ ಕಡ್ಡಾಯವಾಗಿದೆ. ನೀವು ಸಹ ವಿಳಾಸ ನೀಡಬಹುದು ಪರಿಹಾರ ನಿಯಂತ್ರಣಗಳು or ವರ್ಗಾವಣೆ ಅಪಾಯ ಉದಾ: ವಿಮೆಯೊಂದಿಗೆ.
ಆದಾಗ್ಯೂ, ಬೆದರಿಕೆಯನ್ನು ಪರಿಹರಿಸುವ ನಿಯಂತ್ರಣಗಳಿವೆ ಮತ್ತು ನೀವು ಅಪಾಯ ಸ್ವೀಕಾರದಿಂದ ತೃಪ್ತರಾಗದಿದ್ದರೆ ಪರಿಗಣಿಸಬೇಕು. ದಯವಿಟ್ಟು ಮುಂದೆ ಓದಿ.
ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳನ್ನು ಬಳಸಿಕೊಂಡು ದಾಳಿಗಳ ವಿರುದ್ಧ ಏನು ಕೆಲಸ ಮಾಡುತ್ತದೆ
ಸಾಲಿಡ್ ಆವೃತ್ತಿ ನಿರ್ವಹಣೆ
ನಿಯಂತ್ರಿತ ಮತ್ತು ಮಾಹಿತಿಯುಕ್ತ ಆವೃತ್ತಿಯ ಉಬ್ಬುಗಳೊಂದಿಗೆ ಆವೃತ್ತಿ ಪಿನ್ ಮಾಡುವುದು ಮಾಲ್ವೇರ್ ಅನ್ನು ಸ್ವೀಕರಿಸದೆಯೇ ದುರ್ಬಲತೆಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ಅಗತ್ಯವನ್ನು ಸಮತೋಲನಗೊಳಿಸಲು ಹೋಗಬೇಕಾದ ಮಾರ್ಗವಾಗಿದೆ. ಆದರೆ ತಪ್ಪು ಕಲ್ಪನೆ #3 ಅನ್ನು ನೆನಪಿಡಿ: ಹೊಸ ಆವೃತ್ತಿಗಳಿಂದ ಬರುವ ದುರುದ್ದೇಶಪೂರಿತ ಕೋಡ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸಲು ಆವೃತ್ತಿ ಪಿನ್ ಮಾಡುವುದು ಮಾತ್ರ ಸಾಕಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಭವಿಷ್ಯದಲ್ಲಿ ನೀವು ಯಾವುದೇ ನೇರ ಅಥವಾ ಪರೋಕ್ಷ ಅವಲಂಬನೆಯಲ್ಲಿ ಆವೃತ್ತಿಗಳನ್ನು ನವೀಕರಿಸಬೇಕಾಗುತ್ತದೆ. ಆ ಕ್ಷಣದಲ್ಲಿ ಎಲ್ಲಾ ಮಾರ್ಪಡಿಸಿದ ಆವೃತ್ತಿಗಳು ಮಾಲ್ವೇರ್ ಅನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ ಎಂಬುದಕ್ಕೆ ನಿಮಗೆ ಸಾಕಷ್ಟು ಬಲವಾದ ಪುರಾವೆಗಳು ಬೇಕಾಗುತ್ತವೆ.
ಮುಂಚಿನ ಎಚ್ಚರಿಕೆ
ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳ ಸಮಸ್ಯೆಗೆ ಒಂದು ವಿಧಾನವೆಂದರೆ ಮುಂಚಿನ ಎಚ್ಚರಿಕೆ ವ್ಯವಸ್ಥೆ (ಇಲ್ಲಿ ಹೆಸರಿಸಲಾಗಿದೆ ಮಾಲ್ವೇರ್ ಮುನ್ನೆಚ್ಚರಿಕೆ ಅಥವಾ MEW), ಅಲ್ಲಿ ಪ್ರಕಟವಾದ ಹೊಸ ಆವೃತ್ತಿಗಳನ್ನು (ಹೊಸ ಅಥವಾ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಘಟಕಗಳಿಗಾಗಿ) ಪತ್ತೆ ಎಂಜಿನ್ನಿಂದ ವಿಶ್ಲೇಷಿಸಲಾಗುತ್ತದೆ, ಸಾಕಷ್ಟು ಪುರಾವೆಗಳು ಕಂಡುಬಂದಾಗ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಸಂಭಾವ್ಯವಾಗಿ ದುರುದ್ದೇಶಪೂರಿತವೆಂದು ವರ್ಗೀಕರಿಸಬಹುದು.
ಪ್ರಸ್ತುತ ಪ್ರಕಟಣೆಯ ದರದಲ್ಲಿ ಎಲ್ಲಾ ಹೊಸ ಘಟಕಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಪರಿಶೀಲಿಸುವುದು ಅಸಾಧ್ಯವಾದ್ದರಿಂದ, ಇಲ್ಲಿ ಯಾಂತ್ರೀಕರಣ ಅತ್ಯಗತ್ಯ. ಆದ್ದರಿಂದ ಪತ್ತೆ ಎಂಜಿನ್ ವಿವಿಧ ತಂತ್ರಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಅಗತ್ಯವಿದೆ, ಬಹುಶಃ ಸ್ಥಿರ, ಕ್ರಿಯಾತ್ಮಕ ಮತ್ತು ಸಾಮರ್ಥ್ಯ ವಿಶ್ಲೇಷಣೆ, ಬಳಕೆದಾರರ ಖ್ಯಾತಿ ಮತ್ತು ಘಟಕ ಮೆಟಾಡೇಟಾ ಮತ್ತು ಟಾರ್ಬಾಲ್ ವಿಷಯಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳಿಂದ ಬರುವ ಪುರಾವೆಗಳು ಅಥವಾ ಟಾರ್ಬಾಲ್ ಮತ್ತು ಘಟಕವು ಬರುತ್ತದೆ ಎಂದು ಹೇಳಲಾದ ಮೂಲ ಭಂಡಾರದ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಒಳಗೊಂಡಂತೆ.
ಒಂದು ಇಲ್ಲ ಕತ್ತಲೆ ವಲಯ ಪ್ರಕಾಶನ ಸಮಯ ಮತ್ತು ಎಂಜಿನ್ ಘಟಕ ವಿಷಯಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುವ ಸಮಯದ ನಡುವೆ, ಆದರೆ ಅದು ಕೆಲವು ನಿಮಿಷಗಳನ್ನು ಮೀರಬಾರದು. ಸ್ಕೀಮ್ ಅನ್ನು ಮಾರ್ಪಡಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ ಹೊಸ ಘಟಕಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಕಾಯುವ ಮೂಲಕ ಅವುಗಳನ್ನು ಸಾಫ್ಟ್ವೇರ್ ನಿರ್ಮಾಣದಲ್ಲಿ ಸ್ಥಾಪಿಸಲು ಮತ್ತು ಬಳಸಲು ಅನುಮತಿಸುವ ಮೊದಲು. pipelineಅಥವಾ ಅಗತ್ಯವಿದ್ದಾಗ ಬೇಡಿಕೆಯ ಮೇರೆಗೆ ಅವುಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿ. ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿಯಲ್ಲಿರುವ ಒಂದು ಘಟಕವು ಬದಲಾಗುವುದಿಲ್ಲ. [3], ಆದ್ದರಿಂದ ಇದನ್ನು ಒಮ್ಮೆ ಮಾತ್ರ ವಿಶ್ಲೇಷಿಸಬೇಕಾಗುತ್ತದೆ.
ಪೂರ್ಣ ಯಾಂತ್ರೀಕರಣ ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ಸಂಭಾವ್ಯ ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳಿಗೆ ಭದ್ರತಾ ಪರಿಶೀಲನೆಯ ಅಗತ್ಯವಿದೆ. ಡಿಜಿಟಲ್ ಸರ್ವರೋಗ ನಿವಾರಕ ಪ್ರತಿಪಾದಕರ ಬಗ್ಗೆ ಎಚ್ಚರದಿಂದಿರಿ: ಶಂಕಿತ ಘಟಕವು ಮಾಲ್ವೇರ್ ಹೊಂದಿದೆಯೇ ಎಂದು ದೃಢೀಕರಿಸುವ ವಿಷಯದಲ್ಲಿ ಕೊನೆಯ ಮಾತನ್ನು ತೆಗೆದುಕೊಳ್ಳುವಷ್ಟು AI ಮತ್ತು ಯಂತ್ರ ಕಲಿಕೆ ಅಭಿವೃದ್ಧಿ ಹೊಂದಿಲ್ಲ. ಖಚಿತವಾಗಿ, ಸೆರೆಹಿಡಿಯಲಾದ ಕಚ್ಚಾ ಪುರಾವೆಗಳಿಂದ ಇನ್ಪುಟ್ ಘಟಕವನ್ನು ವರ್ಗೀಕರಿಸುವಲ್ಲಿ ಯಂತ್ರ ಕಲಿಕೆಯು ಪತ್ತೆ ಎಂಜಿನ್ನಲ್ಲಿ ಪ್ರಮುಖ ಪಾತ್ರ ವಹಿಸುತ್ತದೆ, ಆದರೆ ಘಟಕವನ್ನು "ನಿರ್ಬಂಧಿಸಿದ" ನಂತರ ಅಂತಿಮ ಪದವು ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳಲ್ಲಿ ಅನುಭವ ಹೊಂದಿರುವ ಭದ್ರತಾ ತಂಡದಿಂದ ಹಸ್ತಚಾಲಿತ ವಿಮರ್ಶೆಯ ಮೇಲೆ ಇರುತ್ತದೆ. ಇದು ಯಾವುದೇ ಸಂಭಾವ್ಯ ಮಾಲ್ವೇರ್ ಅನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ ಅಥವಾ ಅದನ್ನು ಸುರಕ್ಷಿತವೆಂದು ಮರು-ವರ್ಗೀಕರಿಸುತ್ತದೆ. ಮತ್ತು ಸಮಯದ ಅವಧಿಯು ಗಂಟೆಗಳ ವ್ಯಾಪ್ತಿಯಲ್ಲಿರುತ್ತದೆ.
ದುರುದ್ದೇಶಪೂರಿತ ಆವೃತ್ತಿ/ಘಟಕದ ಬಗ್ಗೆ ನೋಂದಾವಣೆ ವರದಿ ಮಾಡುತ್ತದೆ; ನಂತರ ನೋಂದಾವಣೆ ದೃಢೀಕರಿಸಲು ತನ್ನ ಪರಿಶೀಲನೆಯನ್ನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಸಾರ್ವಜನಿಕ ಬಹಿರಂಗಪಡಿಸುವಿಕೆ ಮತ್ತು ನೋಂದಾವಣೆಯಿಂದ ತೆಗೆದುಹಾಕಲು ಮುಂದುವರಿಯುತ್ತದೆ. ಕೆಲವು ನೋಂದಾವಣೆಗಳು ಭದ್ರತಾ ಹೋಲ್ಡಿಂಗ್ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತವೆ. ಇಲ್ಲಿ ಸಮಯದ ವ್ಯಾಪ್ತಿಯು ಪ್ರಕಟಣೆಯ ನಂತರದ ದಿನಗಳು ಅಥವಾ ವಾರಗಳು, ಅದು 'ಸಮಯ ವಾಸ'ಅಥವಾ'ಎಕ್ಸ್ಪೋಸರ್ ವಿಂಡೋ' ಹೆಚ್ಚಿನ ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳಿಗೆ.
ಒಂದು ಘಟಕ ಆವೃತ್ತಿಯು ದುರುದ್ದೇಶಪೂರಿತವಾಗಿದೆಯೇ ಎಂದು ತಿಳಿಯಲು ಸಾಧ್ಯವೇ?
ಆದ್ದರಿಂದ ಮುಂಚಿನ ಎಚ್ಚರಿಕೆಗಾಗಿ, ನಾವು ಈ ಪ್ರಶ್ನೆಗೆ ತೃಪ್ತಿದಾಯಕ ಉತ್ತರವನ್ನು ನೀಡಬೇಕಾಗಿದೆ: ಗ್ರಂಥಾಲಯ ಅಥವಾ ಪ್ಯಾಕೇಜ್ ದುರುದ್ದೇಶಪೂರಿತವಾಗಿದೆ (ಅಲ್ಲ) ಎಂದು ನಾನು ಹೇಗೆ ತಿಳಿಯಬಹುದು? ದುರುದ್ದೇಶಪೂರಿತ ನಡವಳಿಕೆಯ ಸಾಕಷ್ಟು ಪುರಾವೆಗಳನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸುವುದು? ಸಾಧ್ಯ, ಆದರೆ ಕಷ್ಟಕರ, ಏಕೆಂದರೆ ವಿರೋಧಿಗಳು ಪತ್ತೆಹಚ್ಚುವಿಕೆಯನ್ನು ತಪ್ಪಿಸಲು ಹೆಚ್ಚಿನ ಜಾಣ್ಮೆಯನ್ನು ಬಳಸುತ್ತಾರೆ. ವಿಭಿನ್ನ ವಿಧಾನಗಳಿವೆ, ಪ್ರತಿಯೊಂದೂ ಸಾಧಕ-ಬಾಧಕಗಳನ್ನು ಹೊಂದಿದೆ.
ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆ ಘಟಕವನ್ನು ಚಲಾಯಿಸದೆಯೇ ದಾಳಿಕೋರರು ಬಳಸುವ ತಂತ್ರಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಎಲ್ಲಾ ಮರಣದಂಡನೆ ಮಾರ್ಗಗಳನ್ನು ಪರಿಶೀಲಿಸಬಹುದು ಮತ್ತು ಡಿ-ಆಬ್ಫಸ್ಕೇಶನ್ ಅಥವಾ ಡಿಕ್ರಿಪಿಂಗ್ನಂತಹ ಪೂರ್ವ-ಸಂಸ್ಕರಣಾ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಬಹುದು. ದಾಳಿಕೋರರು ತಮ್ಮ ದುಷ್ಕೃತ್ಯವನ್ನು ಮರೆಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಮಬ್ಬುಗೊಳಿಸುವ ಪ್ರಯತ್ನಗಳು ನಿಜಕ್ಕೂ ಮಾಲ್ವೇರ್ನ ಪುರಾವೆಗಳಾಗಿವೆ (ಆದರೆ ಕಾನೂನುಬದ್ಧ ಘಟಕಗಳು ಬೌದ್ಧಿಕ ಆಸ್ತಿಯನ್ನು ಸಂರಕ್ಷಿಸಲು ಕೋಡ್ ಅನ್ನು ಅಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ, "ಮುಕ್ತ ಸಂಪನ್ಮೂಲ”). ಬಲವಾದ ಅಸ್ಪಷ್ಟತೆಯೊಂದಿಗೆ ಅತಿ ಹೆಚ್ಚು ಅತ್ಯಾಧುನಿಕ ದಾಳಿಗಳಲ್ಲಿ ಅಲ್ಪಸಂಖ್ಯಾತರಿಗೆ ಮಾತ್ರ ಸ್ಯಾಂಡ್ಬಾಕ್ಸಿಂಗ್ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದರೆ ಅಂತಹ ಬಲವಾದ ಅಸ್ಪಷ್ಟತೆಯು ದುರುದ್ದೇಶಪೂರಿತತೆಯ ಸಂಕೇತವಾಗಿದೆ. ದಯವಿಟ್ಟು ಸಾಂಪ್ರದಾಯಿಕ SAST ಉಪಕರಣಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಲ್ಲದ ದುರ್ಬಲತೆಗಳಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಹಿಂಬಾಗಿಲಿನಂತಹ ದುರುದ್ದೇಶಪೂರಿತ ಉದ್ದೇಶಕ್ಕಾಗಿ ಅಲ್ಲ.
ಡೈನಾಮಿಕ್ ವಿಶ್ಲೇಷಣೆ ಘಟಕವನ್ನು ರನ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ರನ್ಟೈಮ್ ಅನ್ನು ಉಪಕರಣಗೊಳಿಸುವ ಮೂಲಕ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ಡ್ ಪರಿಸರವನ್ನು ಒದಗಿಸುವ ಮೂಲಕ. ಕೆಲವು ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಪ್ರಚೋದಿಸಲಾದ ದುರುದ್ದೇಶಪೂರಿತ ನಡವಳಿಕೆಯು ಪತ್ತೆಯಾಗದೆ ಹಾದುಹೋಗಬಹುದು: ಮಾಲ್ವೇರ್ ತಪ್ಪಿಸಿಕೊಳ್ಳುವ ತಂತ್ರಗಳನ್ನು ಬಳಸಬಹುದು ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ ವರ್ಚುವಲೈಸೇಶನ್/ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ ತಪ್ಪಿಸಿಕೊಳ್ಳುವಿಕೆ ಪರಿಶೀಲನೆಗೆ ಒಳಪಡದಿದ್ದಾಗ ಮಾತ್ರ ಸಕ್ರಿಯಗೊಳಿಸಲು ಮತ್ತು ಯಾವುದೇ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣಾ ಎಂಜಿನ್ಗೆ ದುರುದ್ದೇಶಪೂರಿತ ಚಟುವಟಿಕೆಯ ಸಂಕೇತವಾಗಿದೆ.
ಸಾಮರ್ಥ್ಯಗಳ ವಿಶ್ಲೇಷಣೆ ಘಟಕವು ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಗಣಿಸುತ್ತದೆ: ಅದು ಎಲ್ಲಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಯಾವ ಫೈಲ್ಗಳನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ, ಯಾವ ಆಜ್ಞೆಗಳು ಅಥವಾ ಪ್ರೋಗ್ರಾಂಗಳನ್ನು ಚಲಾಯಿಸಲಾಗುತ್ತದೆ, ಟರ್ಮಿನಲ್ ಅಥವಾ ಸಾಧನ I/O ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ, ಅಥವಾ ಯಾವ ಸಿಸ್ಟಮ್ ಕರೆಗಳನ್ನು ಆಹ್ವಾನಿಸಲಾಗುತ್ತದೆ. ನಡವಳಿಕೆಯ ಈ ಫಿಂಗರ್ಪ್ರಿಂಟಿಂಗ್ ಅನ್ನು ಆವೃತ್ತಿಗಳಲ್ಲಿ (ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಘಟಕಕ್ಕೆ) ಹೋಲಿಸಬಹುದು, ಆದ್ದರಿಂದ ಅನಿರೀಕ್ಷಿತ ನಡವಳಿಕೆ ಪತ್ತೆಯಾದಾಗ, ಆ ಪುರಾವೆಗಳು ಹೊಸ ಆವೃತ್ತಿಯಲ್ಲಿ ಇಂಜೆಕ್ಟ್ ಮಾಡಲಾದ ಸಂಭಾವ್ಯ ದುರುದ್ದೇಶಪೂರಿತ ಚಟುವಟಿಕೆಯ ಅನುಮಾನವನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಸಂಭಾವ್ಯ ಮಾಲ್ವೇರ್ ಅನ್ನು ಎದುರಿಸುವಾಗ ಭದ್ರತಾ ವಿಶ್ಲೇಷಕರು ಅನುಸರಿಸುವ ಚಿಕಿತ್ಸೆಯ ಸರದಿ ನಿರ್ಧಾರ ಹಂತಗಳನ್ನು ಈ ವಿಧಾನವು ಅನುಸರಿಸುತ್ತದೆ: ತಂತಿಗಳು ಅಥವಾ ಅಂತಹುದೇ ಪರಿಕರಗಳು. ಈ ವಿಧಾನವು ಪ್ರಚೋದಕ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಲೆಕ್ಕಿಸದೆ ದುರುದ್ದೇಶಪೂರಿತ ನಡವಳಿಕೆಯನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಮೂಲ ಕೋಡ್ ಲಭ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಸಂದರ್ಭ ವಿಶ್ಲೇಷಣೆ ಘಟಕವನ್ನು ಹೇಗೆ ಮತ್ತು ಯಾರಿಂದ ಪ್ರಕಟಿಸಲಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಕೆಟ್ಟ ನಟರ ಅಭಿಯಾನಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಯಾವುದೇ ಕಟ್ಟುನಿಟ್ಟಾದ ಪರಿಶೀಲನಾ ಪ್ರಕ್ರಿಯೆಗೆ ಒಳಪಡದ ಹೊಸ ಬಳಕೆದಾರ ಖಾತೆ(ಗಳನ್ನು) ಬಳಸುತ್ತವೆ. ಹಿಂದಿನ ಚಟುವಟಿಕೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದರಿಂದ ಆಧಾರವಾಗಿರುವ ಬಳಕೆದಾರರ ಒಳನೋಟಗಳನ್ನು ನೀಡಬಹುದು, ಹೆಚ್ಚಾಗಿ ಸಂಭಾವ್ಯ ರಾಜಿಯ ಸುಳಿವು ನೀಡಬಹುದಾದ ವೈಪರೀತ್ಯಗಳಿಗೆ. ಖ್ಯಾತಿಯನ್ನು ಗಳಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ ಮತ್ತು ಕಳೆದುಕೊಳ್ಳುವುದು ತುಂಬಾ ಸುಲಭ! ಹಿಂದಿನ ಚಟುವಟಿಕೆಯಿಲ್ಲದ ಬಳಕೆದಾರರು ತಟಸ್ಥರು, ಆದರೆ ಕರ್ಮವು ದುರುದ್ದೇಶಪೂರಿತರನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಹ್ಯಾಕ್ಟಿವಿಸ್ಟ್ಗಳು ಅಥವಾ ತಮ್ಮ ಪ್ರಕಟಣೆಯ ರುಜುವಾತುಗಳನ್ನು ಕದ್ದ ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಕು.
ಮತ್ತೊಂದು ಸಂದರ್ಭೋಚಿತ ಮಾಹಿತಿಯೆಂದರೆ, ಕಾಂಪೊನೆಂಟ್ ಟಾರ್ಬಾಲ್ ಅನ್ನು ರಚಿಸಲು ಬಳಸಲಾಗುತ್ತಿದ್ದ ಮೂಲ ರೆಪೊಸಿಟರಿ ಮತ್ತು ಟಾರ್ಬಾಲ್ನ ವಿಷಯಗಳ ನಡುವಿನ ಯಾವುದೇ ವ್ಯತ್ಯಾಸ. ಮತ್ತು ಸಾರ್ವಜನಿಕ ನೋಂದಾವಣೆಯಲ್ಲಿ ಪ್ರಕಟವಾದ ಘಟಕದ ಆವೃತ್ತಿಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಮೂಲ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಟ್ಯಾಗ್ಗಳು ಅಥವಾ ಬಿಡುಗಡೆಗಳನ್ನು ರಚಿಸುವಂತಹ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಅನುಸರಿಸುವುದು. ನಿರ್ದಿಷ್ಟ ಸ್ಥಳದಲ್ಲಿ ಮೂಲ ರೆಪೊಸಿಟರಿಯನ್ನು ಮಾಡಿದಾಗ commit ಬಿಡುಗಡೆಯೊಂದಿಗೆ ಟ್ಯಾಗ್ ಮಾಡಲಾಗಿದೆ, ಮತ್ತು ನಂತರ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಒಂದು ಆವೃತ್ತಿ ಅದನ್ನು ಅನುಸರಿಸಲು ವಿಫಲವಾದರೆ, ಆ ಘಟಕವು ಕಳಂಕಿತವಾಗಿರಬಹುದು ಎಂಬುದಕ್ಕೆ ಅದೇ ಬಲವಾದ ಪುರಾವೆಯಾಗಿದೆ: ಕೆಟ್ಟ ನಟ ಘಟಕವನ್ನು ಪ್ರಕಟಿಸಲು ಬಳಸಿದ ಖಾತೆಯನ್ನು ರಾಜಿ ಮಾಡಿರಬಹುದು, ಆದರೆ ಮೂಲ ಕೋಡ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಯಾವುದೇ ಬರೆಯುವ ಅನುಮತಿಗಳನ್ನು ಹೊಂದಿಲ್ಲ). ಈ ನಿಯಮಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅನೇಕ ದಾಳಿಗಳನ್ನು ನಿಯಮಿತವಾಗಿ ಪತ್ತೆಹಚ್ಚಲಾಗುತ್ತದೆ: ಉದಾಹರಣೆಗೆ, ಲೆಡ್ಜರ್ ದಾಳಿ ಈ ಮಾರ್ಗಗಳಲ್ಲಿ ಸುಲಭವಾಗಿ ಪತ್ತೆಹಚ್ಚಬಹುದು. ಆದ್ದರಿಂದ ಸಂದರ್ಭ ವಿಶ್ಲೇಷಣೆಯು ಪ್ರಕಟಣೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅಂತಹ ವೈಪರೀತ್ಯಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ.
ಅವಲಂಬನೆ ಫೈರ್ವಾಲ್ಲಿಂಗ್
ನಿಮ್ಮ ಸಾಫ್ಟ್ವೇರ್ನಲ್ಲಿ ಬಳಸಲಾದ ಎಲ್ಲಾ ಅವಲಂಬನೆ ಗ್ರಾಫ್ಗಳಿಗೆ ಘಟಕಗಳ ಸಮಗ್ರ ಶ್ವೇತಪಟ್ಟಿಯನ್ನು ಹೊಂದಿರುವುದು ವಿಭಿನ್ನ ವಿಧಾನವಾಗಿದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ನಿರ್ಮಾಣದಲ್ಲಿ pipeline ನಿಮ್ಮ ಸಂಸ್ಥೆಯಲ್ಲಿ ಚಲಾಯಿಸಿ ಅನುಮೋದಿತ ಘಟಕ ಆವೃತ್ತಿಗಳನ್ನು ಮಾತ್ರ ಸ್ಥಾಪಿಸಬಹುದು ಮತ್ತು ಬಳಸಬಹುದು. “ಫೈರ್ವಾಲ್” ಅನ್ನು ಆಂತರಿಕ ನೋಂದಾವಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಜಾರಿಗೊಳಿಸಲಾಗುತ್ತದೆ, ಅಲ್ಲಿ ಅನುಮತಿಸಲಾದ ಘಟಕ ಆವೃತ್ತಿಗಳಿಗೆ ಟಾರ್ಬಾಲ್ಗಳನ್ನು ನೀಡಲಾಗುತ್ತದೆ (ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಅಥವಾ ಪ್ರಾಕ್ಸಿ ಮಾಡಲಾಗಿದೆ). ಯಾವುದೇ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಸಮಂಜಸವಾಗಿ ಸುರಕ್ಷಿತವೆಂದು ವರ್ಗೀಕರಿಸುವ ತಂತ್ರಜ್ಞಾನವನ್ನು ನೀವು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ ಯಾವುದೇ ಶ್ವೇತಪಟ್ಟಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ ಆದ್ದರಿಂದ ಅದನ್ನು ಶ್ವೇತಪಟ್ಟಿಗೆ ಸೇರಿಸಬಹುದು.
ದಯವಿಟ್ಟು ಗಮನಿಸಿ, ಮುಂಚಿನ ಎಚ್ಚರಿಕೆ (ಹೊಸ ಆವೃತ್ತಿಯ ಪ್ರಕಟಣೆಯ ನಂತರ ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ತ್ವರಿತ ಪತ್ತೆ) ಆ ಮಾಹಿತಿಯನ್ನು ಪೂರ್ವಭಾವಿಯಾಗಿ ಬಳಸುವ ವಿಧಾನದೊಂದಿಗೆ ಸಂಯೋಜಿಸುವ ಅಗತ್ಯವಿದೆ, ಇದರಿಂದಾಗಿ ನಿರ್ಮಾಣದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಘಟಕವನ್ನು ನಿರ್ಬಂಧಿಸಬಹುದು. pipelineಗಳು ಅಥವಾ ಡೆವಲಪರ್ಗಳ ಯಂತ್ರಗಳು [4]. ನಾವು ಇದನ್ನು "ಅವಲಂಬನೆ ಫೈರ್ವಾಲ್ ಮಾಡುವುದು”: ದುರುದ್ದೇಶಪೂರಿತ ಪ್ಯಾಕೇಜ್ಗಳಿಂದ ಸ್ವಯಂಚಾಲಿತ ನಿರ್ಮಾಣಗಳನ್ನು ರಕ್ಷಿಸುವ ಕ್ವಾರಂಟೈನ್ ಕಾರ್ಯವಿಧಾನ. ಆಂತರಿಕ ಪ್ಯಾಕೇಜ್ಗಳು ಮತ್ತು ಇಮೇಜ್ ರಿಜಿಸ್ಟ್ರಿಗಳು ಸಂಸ್ಥೆಗಳನ್ನು ಬಾಹ್ಯ ದುಷ್ಟತನದಿಂದ ಪ್ರತ್ಯೇಕಿಸಲು ಒಳ್ಳೆಯದು, ಆದರೆ ಕ್ವಾರಂಟೈನ್ ಅನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿಸಲು ಸಾಕಷ್ಟು ಬಲವಾದ ಪುರಾವೆಗಳು ಅವಶ್ಯಕ.
ರನ್ಟೈಮ್ ಸ್ಯಾಂಡ್ಬಾಕ್ಸಿಂಗ್
ಪ್ರಕಟಣೆಯ ಸಮಯದಲ್ಲಿ ಪತ್ತೆಹಚ್ಚುವಿಕೆಗೆ ಪರ್ಯಾಯ ವಿಧಾನವೆಂದರೆ ರನ್ಟೈಮ್ನಲ್ಲಿ ನಡವಳಿಕೆಯನ್ನು ವಿಶ್ಲೇಷಿಸುವುದು. ಸಾಫ್ಟ್ವೇರ್ನಿಂದ ನಿರೀಕ್ಷಿತ ನಡವಳಿಕೆಯನ್ನು ಸೆರೆಹಿಡಿಯುವುದು ಮತ್ತು ಕಂಡುಬರುವ ಯಾವುದೇ ವೈಪರೀತ್ಯಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು (ಅಥವಾ ನಿರ್ಬಂಧಿಸುವುದು) ಇದರ ಉದ್ದೇಶವಾಗಿದೆ. ಈ ಕ್ರಮವು ಮೇಲ್ವಿಚಾರಣೆ ಅಥವಾ ನಿರ್ಬಂಧಿಸುವಿಕೆಗಾಗಿ ರನ್ಟೈಮ್ ಅನ್ನು ಉಪಕರಣಗೊಳಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಇದು ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕ ಕೀಟದ ವಿರುದ್ಧ ರಕ್ಷಣಾ ಕಾರ್ಯವಿಧಾನಗಳ ಶಸ್ತ್ರಾಗಾರಕ್ಕೆ ಸೇರಿಸಲಾಗುವ ಭರವಸೆಯ ಕಲ್ಪನೆಯಾಗಿದೆ.
ಸಮಗ್ರ ಕಾರ್ಯತಂತ್ರವನ್ನು ಹೊಂದಿಸುವುದು
ಶಿಫಾರಸು ಮಾಡಲಾದ ಕಾರ್ಯತಂತ್ರವು ಸಾಫ್ಟ್ವೇರ್ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ವಿಭಿನ್ನ ತಂತ್ರಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಅಗತ್ಯವಿದೆ, ಒಳಬರುವ ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳನ್ನು ನಿರ್ಬಂಧಿಸಲು ಆವೃತ್ತಿ ನವೀಕರಣಗಳ ನಿಯಂತ್ರಣವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು. ಆವೃತ್ತಿಗಳನ್ನು ನವೀಕರಿಸುವಾಗ ಸ್ವಯಂಚಾಲಿತ ಸೋಂಕನ್ನು ತಪ್ಪಿಸಲು ನಾವು ಆವೃತ್ತಿ ಪಿನ್ನಿಂಗ್ ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಬೇಕು, ಇದರಿಂದಾಗಿ ಮುಖ್ಯವಾದ ದುರ್ಬಲತೆಗಳಿಗೆ ಪರಿಹಾರಗಳನ್ನು ಪಡೆಯಬಹುದು; ಆವೃತ್ತಿ ನವೀಕರಣಗಳ ಸಮಯದಲ್ಲಿ ನೇರ ಮತ್ತು ಪರೋಕ್ಷ ಅವಲಂಬನೆಗಳ ತ್ವರಿತ ಮತ್ತು ಪರಿಣಾಮಕಾರಿ ಮೌಲ್ಯಮಾಪನವು ಅವು ಮಾಲ್ವೇರ್ನಿಂದ ತುಂಬಿಲ್ಲ ಎಂಬುದಕ್ಕೆ ಸಾಕಷ್ಟು ಪುರಾವೆಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ತಿಳಿದಿರುವ ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳನ್ನು ಅವಲಂಬಿಸಿರುವ ಸಾಫ್ಟ್ವೇರ್ನ ಬಿಲ್ಡ್ಗಳನ್ನು ನಿರ್ಬಂಧಿಸಬೇಕು. ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಜಾರಿಗೊಳಿಸಬೇಕು.
ಸಾಧ್ಯವಾದಾಗಲೆಲ್ಲಾ ಆವೃತ್ತಿ ಪಿನ್ನಿಂಗ್ ಬಳಸಿ, ಏಕೆಂದರೆ ಇದು ನಿರ್ಮಾಣಗಳನ್ನು ಹೆಚ್ಚು ಪುನರುತ್ಪಾದಿಸುವಂತೆ ಮಾಡುತ್ತದೆ. ನಿಯಂತ್ರಿತ, ಹಸ್ತಚಾಲಿತವಾಗಿ ಅನುಮೋದಿಸಲಾದ ಆವೃತ್ತಿ ಉಬ್ಬುಗಳೊಂದಿಗೆ ಆವೃತ್ತಿ ಪಿನ್ನಿಂಗ್, ಮತ್ತು ಸಹಾಯಕ ತಂತ್ರಜ್ಞಾನದಿಂದ ಸಹಾಯ ಮಾಡಲಾಗಿದೆ, ನವೀಕರಣವು ಮಾಲ್ವೇರ್ ಅನ್ನು ತರುತ್ತದೆಯೇ ಅಥವಾ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಮುರಿಯುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಣಯಿಸಬೇಕು ಮತ್ತು ಮಾಲ್ವೇರ್ ಸೋಂಕನ್ನು ತಪ್ಪಿಸುವುದರೊಂದಿಗೆ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಲು ನವೀಕರಣವನ್ನು ಸಮನ್ವಯಗೊಳಿಸಬೇಕು. (1) ಯಾವ ದುರ್ಬಲತೆಗಳು ನಿಜವಾಗಿಯೂ ಮುಖ್ಯವೆಂದು ಆದ್ಯತೆ ನೀಡುವ ಮೂಲಕ (ತಲುಪಬಹುದಾದ ಮತ್ತು ಶೋಷಣೆಗೆ ಒಳಪಡುವ, ದಾಳಿಕೋರರಿಂದ ಗುರಿಯಾಗುವ ಹೆಚ್ಚಿನ ಅಪಾಯದೊಂದಿಗೆ), (2) ಪ್ರಸ್ತುತ ಘಟಕ ಬಳಕೆಗಳೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಮತ್ತು ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಮುರಿಯದ ಗುರಿ ಆವೃತ್ತಿಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೂಲಕ, (3) ದುರುದ್ದೇಶಪೂರಿತ ನಡವಳಿಕೆಯನ್ನು ಹೊಂದಿರದ ಗುರಿ ಆವೃತ್ತಿಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೂಲಕ ಮತ್ತು (4) ತ್ವರಿತವಾಗಿ ಅನುಮೋದಿಸಬಹುದಾದ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಫೈಲ್ಗಳಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಸೂಚಿಸುವ ಮೂಲಕ ನೇರ ಮತ್ತು ಪರೋಕ್ಷ ಅವಲಂಬನೆಗಳಿಗಾಗಿ ಆವೃತ್ತಿ ನವೀಕರಣವನ್ನು ತ್ವರಿತವಾಗಿ ಮಾಡುವ ಮೂಲಕ ಪರಿಕರವು ಇಲ್ಲಿ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಹಂತ (3) ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳ ಬಗ್ಗೆ ಅವುಗಳ ಪ್ರಕಟಣೆಯ ಸಮಯಕ್ಕೆ ಸಾಧ್ಯವಾದಷ್ಟು ಹತ್ತಿರವಿರುವ ನಿರ್ದಿಷ್ಟ ಮಾಹಿತಿಯ ಅಗತ್ಯವಿದೆ.
ಅವಲಂಬನೆಗಳನ್ನು ನವೀಕರಿಸುವ ಈ ಪ್ರಕ್ರಿಯೆಯು ಇರಬೇಕು ಜಾರಿಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಪರಿಶೀಲಿಸಲಾಗಿದೆ ಎಲ್ಲಾ ಸ್ಥಳಗಳಲ್ಲಿ. ಪ್ರಕ್ರಿಯೆಯನ್ನು ದಾಖಲಿಸಬೇಕು ಮತ್ತು ಒಳಗೊಂಡಿರುವ ಎಲ್ಲಾ ಪಕ್ಷಗಳಿಗೆ ತರಬೇತಿ ನೀಡಬೇಕು, ಏಕೆಂದರೆ ಆಗಾಗ್ಗೆ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಸಾಫ್ಟ್ವೇರ್ ನಿರ್ಮಾಣ/ನಿಯೋಜನೆಯನ್ನು ಬಾಹ್ಯೀಕರಿಸಲಾಗುತ್ತದೆ. ದಿ CI/CD pipelineದುರುದ್ದೇಶಪೂರಿತ ಪರೋಕ್ಷ ಅವಲಂಬನೆಯು ನಿರ್ಮಾಣದೊಳಗೆ ಜಾರಿಕೊಳ್ಳುವುದನ್ನು ಯಾಂತ್ರೀಕೃತಗೊಳಿಸುವಿಕೆಯು ಅನುಮತಿಸದಂತೆ s ಅನ್ನು ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಮಾರ್ಪಡಿಸಬೇಕು: guardrails ಒಂದು ಅವಲಂಬನೆಯಲ್ಲಿ ಸಂಭಾವ್ಯ ಮಾಲ್ವೇರ್ಗೆ ಸಾಕಷ್ಟು ಪುರಾವೆಗಳಿದ್ದರೆ ಬಿಲ್ಡ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸುವುದು ಶಿಫಾರಸು ಮಾಡಲಾದ ಮಾರ್ಗವಾಗಿದೆ.
ನಿಮ್ಮ ಸಂಸ್ಥೆಯು ಅನುಮತಿಸಲಾದ ಘಟಕ ಆವೃತ್ತಿಗಳನ್ನು ಹಿಡಿದಿಡಲು ಭದ್ರತಾ ಪ್ರಾಕ್ಸಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಆಂತರಿಕ ನೋಂದಾವಣೆಯನ್ನು ಹೊಂದಿದ್ದರೆ, ವಿನಂತಿಸಿದ ಘಟಕವನ್ನು ಭತ್ಯೆ ಪಟ್ಟಿಗೆ ಸೇರಿಸುವ ಮೊದಲು ಅದನ್ನು ಪರಿಶೀಲಿಸಲು ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳ ಕುರಿತು (ಇತರ ಮಾನದಂಡಗಳ ಜೊತೆಗೆ) ನೀವು ಗುಪ್ತಚರ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಬೇಕು.
ಓಪನ್ ಸೋರ್ಸ್ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಬಳಸುವುದು ಸುಲಭವಲ್ಲ, ಮತ್ತು ಮಾಲ್ವೇರ್ ಅಂಶವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು, ದುರ್ಬಲತೆಯನ್ನು ನಿಭಾಯಿಸುವಲ್ಲಿಯೂ ಅದೇ ರೀತಿಯ ಪ್ರಯತ್ನವನ್ನು ಮಾಡಬೇಕು.
ಒಂದು ಅಂತಿಮ ಟಿಪ್ಪಣಿ: ಮೂಲದ ಮೂಲ, ಸಾಫ್ಟ್ವೇರ್ ದೃಢೀಕರಣಗಳ ರೂಪದಲ್ಲಿ, ಘಟಕದ ನಿರ್ಮಾಣದ ಸಮಯದಲ್ಲಿ ಉತ್ಪತ್ತಿಯಾಗುತ್ತದೆ, ಇದು ಕಲಾಕೃತಿಯನ್ನು (ಘಟಕ ಟಾರ್ಬಾಲ್) ಮೂಲಗಳು ಮತ್ತು ಅದನ್ನು ಉತ್ಪಾದಿಸಿದ ನಿರ್ಮಾಣ ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ಪತ್ತೆಹಚ್ಚುವ ಪ್ರಯತ್ನದಲ್ಲಿ ಮತ್ತೊಂದು ಪ್ರಮುಖ ಭಾಗವಾಗಿದೆ. ಮೂಲ ಸ್ನ್ಯಾಪ್ಶಾಟ್ + ನಿರ್ಮಾಣ ಪರಿಸರ ಮತ್ತು ಸಂಬಂಧಿತ ಸಾಫ್ಟ್ವೇರ್ ಕಲಾಕೃತಿ (ವಿಶ್ವಾಸಾರ್ಹ ನಿರ್ಮಾಣ ವ್ಯವಸ್ಥೆಯಿಂದ ಸಹಿ ಮಾಡಲಾಗಿದೆ) ನಡುವಿನ ಈ ಲಿಂಕ್ ಘಟಕವು ದುರುದ್ದೇಶಪೂರಿತ ನಡವಳಿಕೆಯನ್ನು ಹೊಂದಿಲ್ಲ ಎಂದು ತಡೆಯುವುದಿಲ್ಲ, ಆದರೆ ಕೆಟ್ಟ ವ್ಯಕ್ತಿಗಳಿಗೆ ಮಾಲ್ವೇರ್ ಅನ್ನು ಇಂಜೆಕ್ಟ್ ಮಾಡಲು ಕಷ್ಟವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಮತ್ತು ಮುಕ್ತ ಮೂಲ ಘಟಕಗಳನ್ನು ಸೇವಿಸಲು ಮೂಲ ಮೌಲ್ಯೀಕರಣವನ್ನು ಸಾಮಾನ್ಯ ಅವಶ್ಯಕತೆಯನ್ನಾಗಿ ಮಾಡುವುದು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಕೇವಲ ಇತ್ತೀಚೆಗೆ NPM ಗೆ ಸೇರಿಸಲಾಗಿದೆ. ಆ ವಿಶ್ವಾಸಾರ್ಹ ನಿರ್ಮಾಣ ಮತ್ತು ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಟ್ಯಾಂಪರ್-ಪ್ರೂಫ್ ಮಾಡುವುದು ಅಥವಾ ಬಿಲ್ಡ್ನಲ್ಲಿ ಯಾವುದೇ ಟ್ಯಾಂಪರಿಂಗ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಈ ಪೋಸ್ಟ್ನ ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗಿದೆ.
ಹೆಚ್ಚಿನ ಓದಿಗಾಗಿ
ಮುಂದಿನ ಕಂತು ಮುಕ್ತ ಮೂಲ ದುರುದ್ದೇಶಪೂರಿತ ಪ್ಯಾಕೇಜುಗಳು: ಕ್ಸಿಜೆನಿ ವಿಧಾನ ನಮ್ಮ ಕ್ಸಿಜೆನಿಯಲ್ಲಿ ನಾವು ಅನುಸರಿಸುವ ತಂತ್ರವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತೇವೆ ಮಾಲ್ವೇರ್ ಮುನ್ನೆಚ್ಚರಿಕೆ (MEW) ವ್ಯವಸ್ಥೆ. ಸಾರ್ವಜನಿಕ ಪ್ಯಾಕೇಜ್ ಮತ್ತು ಇಮೇಜ್ ರಿಜಿಸ್ಟ್ರಿಗಳಲ್ಲಿನ ಹೊಸ ಪ್ಯಾಕೇಜ್ ಆವೃತ್ತಿಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಸ್ಥಿರ, ಕ್ರಿಯಾತ್ಮಕ, ಸಾಮರ್ಥ್ಯಗಳು ಮತ್ತು ಸಂದರ್ಭೋಚಿತ ವಿಶ್ಲೇಷಣೆಯ ಸಂಯೋಜನೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಪುರಾವೆಗಳನ್ನು ಪಡೆಯಲಾಗುತ್ತದೆ. ಬಳಕೆದಾರರ ಖ್ಯಾತಿ ಮತ್ತು ಮೂಲ ಕೋಡ್ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ಇತಿಹಾಸದೊಂದಿಗೆ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟ ಪುರಾವೆಗಳು, ಒಂದು ಘಟಕದ ಸಂಪೂರ್ಣ ಸ್ವಯಂಚಾಲಿತ ವರ್ಗೀಕರಣವನ್ನು ಹೆಚ್ಚಿನ ಅಪಾಯ ಮತ್ತು ಬಹುಶಃ ದುರುದ್ದೇಶಪೂರಿತ ವರ್ಗಗಳಾಗಿ ಅನುಮತಿಸುತ್ತದೆ. ತಪ್ಪು ಧನಾತ್ಮಕತೆಯನ್ನು ಕನಿಷ್ಠಕ್ಕೆ ತಗ್ಗಿಸಲು ಪ್ಯಾಕೇಜ್ಗಳಿಂದ ಸಂಗ್ರಹಿಸಲಾದ ಹಿಂದಿನ ಪುರಾವೆಗಳಿಂದ ವ್ಯವಸ್ಥೆಯು ಕಲಿಯುತ್ತದೆ.
ದುರುದ್ದೇಶಪೂರಿತ ಆವೃತ್ತಿಯನ್ನು ವರ್ಗೀಕರಿಸಿದಾಗ, ಚಂದಾದಾರರಾಗಿರುವ ಸಂಸ್ಥೆಗಳು ನೇರವಾಗಿ ಅಥವಾ ಪರೋಕ್ಷವಾಗಿ ಅವರು ಬಳಸುತ್ತಿರುವ ಘಟಕಗಳಿಗೆ ಎಚ್ಚರಿಕೆ ಅಧಿಸೂಚನೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ. ನಂತರ ನಮ್ಮ ವಿಶ್ಲೇಷಕರು ಹಸ್ತಚಾಲಿತ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಮಾಡುತ್ತಾರೆ, ಇದು ವರ್ಗೀಕರಣವನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ ಅಥವಾ ತಿರಸ್ಕರಿಸುತ್ತದೆ. ದೃಢಪಡಿಸಿದ ಮಾಲ್ವೇರ್ಗಾಗಿ, ಸಾರ್ವಜನಿಕ ನೋಂದಾವಣೆಗೆ ಸೂಚಿಸಲಾಗುತ್ತದೆ ಇದರಿಂದ ಅದು ತನ್ನದೇ ಆದ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಮಾಡಬಹುದು ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ದುರುದ್ದೇಶಪೂರಿತ ಆವೃತ್ತಿಯನ್ನು ತೆಗೆದುಹಾಕಬಹುದು ಅಥವಾ ಪ್ರಶ್ನಾರ್ಹ ಬಳಕೆದಾರ ಖಾತೆಯನ್ನು ನಿರ್ಬಂಧಿಸುವುದು ಅಥವಾ ತೆಗೆದುಹಾಕುವಂತಹ ಹೆಚ್ಚುವರಿ ಕ್ರಮವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು.
ಹೊಸ ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕವು ಮಾಲ್ವೇರ್ ದೃಢೀಕರಿಸಲ್ಪಟ್ಟು ನೋಂದಾವಣೆಯಿಂದ ತೆಗೆದುಹಾಕಲ್ಪಡುವವರೆಗೆ ಸಕ್ರಿಯವಾಗಿ ಉಳಿಯುವ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾವು NPM, PyPI, GitHub ಮತ್ತು ಓಪನ್ ಸೋರ್ಸ್ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಇತರ ಪ್ರಮುಖ ಮೂಲಸೌಕರ್ಯಗಳಿಗೆ ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನಾವು ವಿವರಿಸುತ್ತೇವೆ. ಮತ್ತು ಓಪನ್ ಸೋರ್ಸ್ ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡ ಸಾಫ್ಟ್ವೇರ್ ಪೂರೈಕೆ ಸರಪಳಿ ದಾಳಿಯ ವಿರುದ್ಧ ಉತ್ತಮ ರಕ್ಷಣೆಯನ್ನು ಹೊಂದಲು ಸಂಸ್ಥೆಗಳು MEW ವ್ಯವಸ್ಥೆಯಿಂದ ಹೇಗೆ ಪ್ರಯೋಜನ ಪಡೆಯಬಹುದು.
- [1] ಹೇಗಾದರೂ, ಘಟಕದ ಬಳಕೆದಾರರು ಘಟಕ ಟಾರ್ಬಾಲ್ ಅನ್ನು ಎಲ್ಲೋ ಸಂಗ್ರಹಿಸಲಾಗಿದೆಯೇ ಅಥವಾ ನೋಂದಾಯಿಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಬೇಕು, ಉದಾಹರಣೆಗೆ ಆಂತರಿಕ ನೋಂದಾವಣೆಯಲ್ಲಿ, ರೋಗವನ್ನು ನಿರ್ಮೂಲನೆ ಮಾಡಲು.
- [2] ಪ್ಯಾಕೇಜ್ ಮಾಡಲಾದ ಘಟಕವು ಅದರ ವಿಷಯಗಳು ಮತ್ತು ಮೆಟಾಡೇಟಾ, ಮೂಲ ಅಥವಾ ಸಂಕಲಿಸಿದ ಕೋಡ್, ಅನುಸ್ಥಾಪನಾ ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ಮತ್ತು ಪರೀಕ್ಷಾ ಸೂಟ್ಗಳಂತಹ ಹೆಚ್ಚುವರಿ ಐಟಂಗಳನ್ನು ಪ್ಯಾಕೇಜಿಂಗ್ ಸ್ವರೂಪದ ಪ್ರಕಾರ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಸಂಕುಚಿತ ರೂಪದಲ್ಲಿ ಘೋಷಿಸುವ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ. ಇದನ್ನು "ಘಟಕ ಟಾರ್ಬಾಲ್" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.
- [3] ನೋಂದಾವಣೆಯಲ್ಲಿನ ಉಲ್ಲಂಘನೆಯಿಂದಾಗಿ ದುರುದ್ದೇಶಪೂರಿತ ನಟನು ಪ್ರಕಟಿತ ಘಟಕವನ್ನು ಮಾರ್ಪಡಿಸಬಹುದಾದರೂ, ವಿಶ್ಲೇಷಣೆ ಮಾಡಿದ ನಂತರ ಸರಳವಾದ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಡೈಜೆಸ್ಟ್ ಟಾರ್ಬಾಲ್ನಲ್ಲಿನ ಯಾವುದೇ ಬದಲಾವಣೆಯನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆ.
- [4] ಕೆಲವು ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕಗಳು ಅನುಸ್ಥಾಪನೆಯ ಸಮಯದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ, ಆದ್ದರಿಂದ ಇದು "npm install X" ಅನ್ನು X ಒಂದು ದುರುದ್ದೇಶಪೂರಿತ ಘಟಕದೊಂದಿಗೆ ತಿಳಿಯದೆಯೇ ರನ್ ಮಾಡುವ ಡೆವಲಪರ್ ನೋಡ್ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದು.
