DevSecOps ನ ಭಯ ಮತ್ತು ಅಸಹ್ಯ

ನಾವು 2 ಕೋಡ್ ವಿಶ್ಲೇಷಕರು, 4 ಡೈನಾಮಿಕ್ ಪರೀಕ್ಷಾ ಪರಿಕರಗಳು, ನಮ್ಮದೇ ಕರಕುಶಲ ವಸ್ತುಗಳು ಮತ್ತು 250 ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಪ್ರಸ್ತುತ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಇದೆಲ್ಲವೂ ಅಗತ್ಯವಿದೆ ಎಂದು ಅಲ್ಲ, ಆದರೆ ಒಮ್ಮೆ ನೀವು DevSecOps ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ನೀವು ಅಂತ್ಯಕ್ಕೆ ಹೋಗಬೇಕಾಗುತ್ತದೆ.

ಮೂಲ. ಪಾತ್ರದ ಸೃಷ್ಟಿಕರ್ತರು: ಜಸ್ಟಿನ್ ರೋಯ್ಲ್ಯಾಂಡ್ ಮತ್ತು ಡಾನ್ ಹಾರ್ಮನ್.

SecDevOps ಎಂದರೇನು? DevSecOps ಬಗ್ಗೆ ಏನು? ವ್ಯತ್ಯಾಸಗಳೇನು? ಅಪ್ಲಿಕೇಶನ್ ಭದ್ರತೆ - ಅದರ ಬಗ್ಗೆ ಏನು? ಕ್ಲಾಸಿಕ್ ವಿಧಾನವು ಇನ್ನು ಮುಂದೆ ಏಕೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ? ಈ ಎಲ್ಲಾ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರ ತಿಳಿದಿದೆ ಯೂರಿ ಶಬಾಲಿನ್ ನಿಂದ ಕತ್ತಿಮೀನು ಭದ್ರತೆ. ಯೂರಿ ಎಲ್ಲದಕ್ಕೂ ವಿವರವಾಗಿ ಉತ್ತರಿಸುತ್ತಾರೆ ಮತ್ತು ಶಾಸ್ತ್ರೀಯ ಅಪ್ಲಿಕೇಶನ್ ಭದ್ರತಾ ಮಾದರಿಯಿಂದ DevSecOps ಪ್ರಕ್ರಿಯೆಗೆ ಪರಿವರ್ತನೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತಾರೆ: DevOps ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಸುರಕ್ಷಿತ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯ ಏಕೀಕರಣವನ್ನು ಸರಿಯಾಗಿ ಸಮೀಪಿಸುವುದು ಮತ್ತು ಯಾವುದನ್ನೂ ಮುರಿಯಬಾರದು, ಮುಖ್ಯ ಹಂತಗಳ ಮೂಲಕ ಹೇಗೆ ಹೋಗುವುದು ಸುರಕ್ಷತಾ ಪರೀಕ್ಷೆ, ಯಾವ ಪರಿಕರಗಳನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಅವುಗಳು ಭಿನ್ನವಾಗಿರುವುದನ್ನು ಮತ್ತು ಮೋಸಗಳನ್ನು ತಪ್ಪಿಸಲು ಅವುಗಳನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಹೇಗೆ.

ಸ್ಪೀಕರ್ ಬಗ್ಗೆ: ಯೂರಿ ಶಬಾಲಿನ್ - ಕಂಪನಿಯಲ್ಲಿ ಮುಖ್ಯ ಭದ್ರತಾ ವಾಸ್ತುಶಿಲ್ಪಿ ಕತ್ತಿಮೀನು ಭದ್ರತೆ. ಏಕೀಕೃತ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷಾ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳ ಒಟ್ಟಾರೆ ಏಕೀಕರಣಕ್ಕಾಗಿ SSDL ಅನುಷ್ಠಾನಕ್ಕೆ ಜವಾಬ್ದಾರರು. ಮಾಹಿತಿ ಭದ್ರತೆಯಲ್ಲಿ 7 ವರ್ಷಗಳ ಅನುಭವ. ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಮತ್ತು ಸೇವೆಗಳನ್ನು ಒದಗಿಸುವ ಆಲ್ಫಾ-ಬ್ಯಾಂಕ್, ಸ್ಬರ್‌ಬ್ಯಾಂಕ್ ಮತ್ತು ಪಾಸಿಟಿವ್ ಟೆಕ್ನಾಲಜೀಸ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದೆ. ZerONights, PHDays, RISSPA, OWASP ಅಂತರಾಷ್ಟ್ರೀಯ ಸಮ್ಮೇಳನಗಳಲ್ಲಿ ಸ್ಪೀಕರ್.

ಅಪ್ಲಿಕೇಶನ್ ಭದ್ರತೆ: ಅದರ ಬಗ್ಗೆ ಏನು?

ಅಪ್ಲಿಕೇಶನ್ ಭದ್ರತೆ - ಇದು ಅಪ್ಲಿಕೇಶನ್ ಭದ್ರತೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಭದ್ರತಾ ವಿಭಾಗವಾಗಿದೆ. ಇದು ಮೂಲಸೌಕರ್ಯ ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಭದ್ರತೆಗೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ, ಬದಲಿಗೆ ನಾವು ಏನು ಬರೆಯುತ್ತೇವೆ ಮತ್ತು ಡೆವಲಪರ್‌ಗಳು ಏನು ಕೆಲಸ ಮಾಡುತ್ತಾರೆ - ಇವುಗಳು ಅಪ್ಲಿಕೇಶನ್‌ನ ನ್ಯೂನತೆಗಳು ಮತ್ತು ದುರ್ಬಲತೆಗಳಾಗಿವೆ.

ನಿರ್ದೇಶನ SDL ಅಥವಾ SDLC - ಭದ್ರತಾ ಅಭಿವೃದ್ಧಿ ಜೀವನಚಕ್ರ - ಮೈಕ್ರೋಸಾಫ್ಟ್ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದೆ. ರೇಖಾಚಿತ್ರವು ಅಂಗೀಕೃತ ಎಸ್‌ಡಿಎಲ್‌ಸಿ ಮಾದರಿಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಇದರ ಮುಖ್ಯ ಕಾರ್ಯವೆಂದರೆ ಅಭಿವೃದ್ಧಿಯ ಪ್ರತಿಯೊಂದು ಹಂತದಲ್ಲೂ ಸುರಕ್ಷತೆಯ ಭಾಗವಹಿಸುವಿಕೆ, ಅವಶ್ಯಕತೆಗಳಿಂದ ಬಿಡುಗಡೆ ಮತ್ತು ಉತ್ಪಾದನೆಯವರೆಗೆ. ಉದ್ಯಮದಲ್ಲಿ ಹಲವಾರು ದೋಷಗಳಿವೆ ಎಂದು ಮೈಕ್ರೋಸಾಫ್ಟ್ ಅರಿತುಕೊಂಡಿತು, ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವುಗಳಿವೆ ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಏನಾದರೂ ಮಾಡಬೇಕಾಗಿದೆ, ಮತ್ತು ಅವರು ಈ ವಿಧಾನವನ್ನು ಪ್ರಸ್ತಾಪಿಸಿದರು, ಅದು ಅಂಗೀಕೃತವಾಗಿದೆ.

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

ಅಂಗೀಕೃತ SDLC ಅನ್ನು ವಿವಿಧ ವಿಧಾನಗಳಲ್ಲಿ ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ - OpenSAMM, BSIMM, OWASP. ವಿಧಾನಗಳು ವಿಭಿನ್ನವಾಗಿವೆ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಹೋಲುತ್ತವೆ.

ಮೆಚುರಿಟಿ ಮಾದರಿಯಲ್ಲಿ ಭದ್ರತೆಯನ್ನು ನಿರ್ಮಿಸುವುದು

ನಾನು ಅದನ್ನು ಹೆಚ್ಚು ಇಷ್ಟಪಡುತ್ತೇನೆ BSIMM - ಮೆಚುರಿಟಿ ಮಾದರಿಯಲ್ಲಿ ಭದ್ರತೆಯನ್ನು ನಿರ್ಮಿಸುವುದು. ವಿಧಾನದ ಆಧಾರವು ಅಪ್ಲಿಕೇಶನ್ ಭದ್ರತಾ ಪ್ರಕ್ರಿಯೆಯನ್ನು 4 ಡೊಮೇನ್‌ಗಳಾಗಿ ವಿಭಾಗಿಸುತ್ತದೆ: ಆಡಳಿತ, ಗುಪ್ತಚರ, SSDL ಟಚ್‌ಪಾಯಿಂಟ್‌ಗಳು ಮತ್ತು ನಿಯೋಜನೆ. ಪ್ರತಿ ಡೊಮೇನ್ 12 ಅಭ್ಯಾಸಗಳನ್ನು ಹೊಂದಿದೆ, ಇವುಗಳನ್ನು 112 ಚಟುವಟಿಕೆಗಳಾಗಿ ಪ್ರತಿನಿಧಿಸಲಾಗುತ್ತದೆ.

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

ಏಕೆ DevSecOps

DevOps ಒಂದು ಸಾಮಾನ್ಯ, ದೊಡ್ಡ ಪ್ರಕ್ರಿಯೆಯಾಗಿದ್ದು ಇದರಲ್ಲಿ ಸುರಕ್ಷತೆಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು.

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

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

ನಮ್ಮ ಕಂಪನಿಯ ಕೆಲಸದ ಸಂದರ್ಭದಲ್ಲಿ, ಎಲ್ಲಾ ಕ್ಷೇತ್ರಗಳು ಮತ್ತು ಉದ್ಯಮಗಳಲ್ಲಿನ ಭದ್ರತೆಯು ಒಂದೇ ಚಕ್ರದಲ್ಲಿ ಅಭಿವೃದ್ಧಿಯನ್ನು ಹಿಡಿಯಲು ಮತ್ತು ತಿರುಗಲು ಸಮಯವಾಗಿದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ. ಅಗೈಲ್. DevSecOps ಮಾದರಿಯು ಚುರುಕಾದ ಅಭಿವೃದ್ಧಿ ವಿಧಾನ, ಅನುಷ್ಠಾನ, ಬೆಂಬಲ ಮತ್ತು ಪ್ರತಿ ಬಿಡುಗಡೆ ಮತ್ತು ಪುನರಾವರ್ತನೆಯಲ್ಲಿ ಭಾಗವಹಿಸುವಿಕೆಯೊಂದಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ.

DevSecOps ಗೆ ಪರಿವರ್ತನೆ

ಸೆಕ್ಯುರಿಟಿ ಡೆವಲಪ್‌ಮೆಂಟ್ ಲೈಫ್‌ಸೈಕಲ್‌ನಲ್ಲಿನ ಪ್ರಮುಖ ಪದ "ಪ್ರಕ್ರಿಯೆ". ಉಪಕರಣಗಳನ್ನು ಖರೀದಿಸುವ ಬಗ್ಗೆ ಯೋಚಿಸುವ ಮೊದಲು ನೀವು ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.

DevOps ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಪರಿಕರಗಳನ್ನು ಸರಳವಾಗಿ ಅಳವಡಿಸುವುದು ಸಾಕಾಗುವುದಿಲ್ಲ - ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಭಾಗವಹಿಸುವವರ ನಡುವೆ ಸಂವಹನ ಮತ್ತು ತಿಳುವಳಿಕೆ ಮುಖ್ಯವಾಗಿದೆ.

ಜನರು ಹೆಚ್ಚು ಮುಖ್ಯ, ಸಾಧನಗಳಲ್ಲ.

ಸಾಮಾನ್ಯವಾಗಿ, ಸುರಕ್ಷಿತ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯ ಯೋಜನೆಯು ಉಪಕರಣವನ್ನು ಆಯ್ಕೆಮಾಡುವುದರೊಂದಿಗೆ ಮತ್ತು ಖರೀದಿಸುವುದರೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರಸ್ತುತ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಉಪಕರಣವನ್ನು ಸಂಯೋಜಿಸುವ ಪ್ರಯತ್ನಗಳೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಅದು ಪ್ರಯತ್ನಗಳಾಗಿ ಉಳಿಯುತ್ತದೆ. ಇದು ದುರದೃಷ್ಟಕರ ಪರಿಣಾಮಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಎಲ್ಲಾ ಉಪಕರಣಗಳು ತಮ್ಮದೇ ಆದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಮತ್ತು ಮಿತಿಗಳನ್ನು ಹೊಂದಿವೆ.

ಭದ್ರತಾ ವಿಭಾಗವು ವಿಶಾಲ ಸಾಮರ್ಥ್ಯಗಳೊಂದಿಗೆ ಉತ್ತಮ, ದುಬಾರಿ ಸಾಧನವನ್ನು ಆಯ್ಕೆಮಾಡಿದಾಗ ಮತ್ತು ಅದನ್ನು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಸಂಯೋಜಿಸಲು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಬಂದಾಗ ಸಾಮಾನ್ಯ ಪ್ರಕರಣವಾಗಿದೆ. ಆದರೆ ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ - ಈಗಾಗಲೇ ಖರೀದಿಸಿದ ಉಪಕರಣದ ಮಿತಿಗಳು ಪ್ರಸ್ತುತ ಮಾದರಿಗೆ ಹೊಂದಿಕೆಯಾಗದ ರೀತಿಯಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ರಚಿಸಲಾಗಿದೆ.

ಮೊದಲಿಗೆ, ನೀವು ಯಾವ ಫಲಿತಾಂಶವನ್ನು ಬಯಸುತ್ತೀರಿ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯು ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಿ. ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಉಪಕರಣ ಮತ್ತು ಸುರಕ್ಷತೆಯ ಪಾತ್ರಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇದು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಈಗಾಗಲೇ ಬಳಕೆಯಲ್ಲಿರುವುದನ್ನು ಪ್ರಾರಂಭಿಸಿ

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

ಸಾಮಾನ್ಯವಾಗಿ ಅವಶ್ಯಕತೆಗಳು ಕಾಗದದ ಟಾಲ್ಮಡ್ ಆಗಿದ್ದು ಅದು ಕಪಾಟಿನಲ್ಲಿ ಇರುತ್ತದೆ. ನಾವು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನೋಡಲು ಕಂಪನಿಯೊಂದಕ್ಕೆ ಬಂದಾಗ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ಭದ್ರತಾ ಅವಶ್ಯಕತೆಗಳನ್ನು ನೋಡಲು ಕೇಳಿದಾಗ ಒಂದು ಪ್ರಕರಣವಿತ್ತು. ಇದರೊಂದಿಗೆ ವ್ಯವಹರಿಸಿದ ತಜ್ಞರು ದೀರ್ಘಕಾಲ ಹುಡುಕುತ್ತಿದ್ದರು:

- ಈಗ, ಎಲ್ಲೋ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಈ ಡಾಕ್ಯುಮೆಂಟ್ ಇರುವ ಮಾರ್ಗವಿದೆ.

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಒಂದು ವಾರದ ನಂತರ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ.

ಅವಶ್ಯಕತೆಗಳು, ಪರಿಶೀಲನೆಗಳು ಮತ್ತು ಇತರ ವಿಷಯಗಳಿಗಾಗಿ, ಪುಟವನ್ನು ರಚಿಸಿ ಉದಾ. ಸಂಗಮ - ಇದು ಎಲ್ಲರಿಗೂ ಅನುಕೂಲಕರವಾಗಿದೆ.

ನೀವು ಈಗಾಗಲೇ ಹೊಂದಿರುವುದನ್ನು ಮರುಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಲು ಮತ್ತು ಪ್ರಾರಂಭಿಸಲು ಅದನ್ನು ಬಳಸಲು ಸುಲಭವಾಗಿದೆ.

ಸೆಕ್ಯುರಿಟಿ ಚಾಂಪಿಯನ್‌ಗಳನ್ನು ಬಳಸಿ

ವಿಶಿಷ್ಟವಾಗಿ, 100-200 ಡೆವಲಪರ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಸರಾಸರಿ ಕಂಪನಿಯಲ್ಲಿ, ಒಬ್ಬ ಭದ್ರತಾ ತಜ್ಞರು ಹಲವಾರು ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತಾರೆ ಮತ್ತು ಭೌತಿಕವಾಗಿ ಎಲ್ಲವನ್ನೂ ಪರಿಶೀಲಿಸಲು ಸಮಯ ಹೊಂದಿಲ್ಲ. ಅವನು ತನ್ನ ಕೈಲಾದಷ್ಟು ಪ್ರಯತ್ನಿಸಿದರೂ, ಅಭಿವೃದ್ಧಿಯು ಉತ್ಪಾದಿಸುವ ಎಲ್ಲಾ ಕೋಡ್ ಅನ್ನು ಅವನು ಮಾತ್ರ ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ. ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಒಂದು ಪರಿಕಲ್ಪನೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ - ಭದ್ರತಾ ಚಾಂಪಿಯನ್ಸ್.

ಭದ್ರತಾ ಚಾಂಪಿಯನ್‌ಗಳು ನಿಮ್ಮ ಉತ್ಪನ್ನದ ಸುರಕ್ಷತೆಯಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿರುವ ಅಭಿವೃದ್ಧಿ ತಂಡದೊಳಗಿನ ಜನರು.

ಸೆಕ್ಯುರಿಟಿ ಚಾಂಪಿಯನ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಟೀಮ್‌ಗೆ ಎಂಟ್ರಿ ಪಾಯಿಂಟ್ ಆಗಿದ್ದು, ಒಬ್ಬ ಸೆಕ್ಯುರಿಟಿ ಇವಾಂಜೆಲಿಸ್ಟ್ ಒಂದಾಗಿ ಸೇರಿಕೊಂಡಿದ್ದಾರೆ.

ಸಾಮಾನ್ಯವಾಗಿ, ಭದ್ರತಾ ತಜ್ಞರು ಅಭಿವೃದ್ಧಿ ತಂಡಕ್ಕೆ ಬಂದಾಗ ಮತ್ತು ಕೋಡ್‌ನಲ್ಲಿ ದೋಷವನ್ನು ತೋರಿಸಿದಾಗ, ಅವರು ಆಶ್ಚರ್ಯಕರ ಉತ್ತರವನ್ನು ಪಡೆಯುತ್ತಾರೆ:

- ಮತ್ತೆ ನೀವು ಯಾರು? ನಾನು ನಿನ್ನನ್ನು ಮೊದಲ ಬಾರಿಗೆ ನೋಡುತ್ತಿದ್ದೇನೆ. ನನ್ನೊಂದಿಗೆ ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿದೆ - ನನ್ನ ಹಿರಿಯ ಸ್ನೇಹಿತ ನನಗೆ ಕೋಡ್ ವಿಮರ್ಶೆಯಲ್ಲಿ "ಅನ್ವಯಿಸು" ನೀಡಿದರು, ನಾವು ಮುಂದುವರಿಯುತ್ತೇವೆ!

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

ಅಲ್ಲದೆ, ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮ ಕೋಡ್ ಅನ್ನು ಯಾವುದೇ ಭದ್ರತಾ ತಜ್ಞರಿಗಿಂತ ಚೆನ್ನಾಗಿ ತಿಳಿದಿದ್ದಾರೆ. ಸ್ಥಿರ ವಿಶ್ಲೇಷಣಾ ಸಾಧನದಲ್ಲಿ ಕನಿಷ್ಠ 5 ಯೋಜನೆಗಳನ್ನು ಹೊಂದಿರುವ ವ್ಯಕ್ತಿಗೆ, ಎಲ್ಲಾ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಕಷ್ಟ. ಸೆಕ್ಯುರಿಟಿ ಚಾಂಪಿಯನ್‌ಗಳು ತಮ್ಮ ಉತ್ಪನ್ನವನ್ನು ತಿಳಿದಿದ್ದಾರೆ: ಯಾವುದರೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ ಮತ್ತು ಯಾವುದನ್ನು ಮೊದಲು ನೋಡಬೇಕು - ಅವು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ.

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

ಪರೀಕ್ಷೆಯ ಹಂತಗಳು

ಮಾದರಿ 20 ರಿಂದ 80 20% ಪ್ರಯತ್ನವು 80% ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತಾರೆ. ಈ 20% ಅಪ್ಲಿಕೇಶನ್ ವಿಶ್ಲೇಷಣಾ ಅಭ್ಯಾಸಗಳು ಮತ್ತು ಅದು ಸ್ವಯಂಚಾಲಿತವಾಗಿರಬಹುದು. ಅಂತಹ ಚಟುವಟಿಕೆಗಳ ಉದಾಹರಣೆಗಳು ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆ - SAST, ಡೈನಾಮಿಕ್ ವಿಶ್ಲೇಷಣೆ - DAST и ಮುಕ್ತ ಮೂಲ ನಿಯಂತ್ರಣ. ಚಟುವಟಿಕೆಗಳ ಬಗ್ಗೆ, ಹಾಗೆಯೇ ಪರಿಕರಗಳ ಬಗ್ಗೆ, ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅವುಗಳನ್ನು ಪರಿಚಯಿಸುವಾಗ ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಯಾವ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಎದುರಿಸುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಸರಿಯಾಗಿ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಹೇಳುತ್ತೇನೆ.

ಉಪಕರಣಗಳ ಮುಖ್ಯ ಸಮಸ್ಯೆಗಳು

ಎಲ್ಲಾ ಉಪಕರಣಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಮತ್ತು ಗಮನ ಅಗತ್ಯವಿರುವ ಸಮಸ್ಯೆಗಳನ್ನು ನಾನು ಹೈಲೈಟ್ ಮಾಡುತ್ತೇನೆ. ಮುಂದೆ ಪುನರಾವರ್ತಿಸದಂತೆ ನಾನು ಅವುಗಳನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿಶ್ಲೇಷಿಸುತ್ತೇನೆ.

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

ಉನ್ನತ ಮಟ್ಟದ ತಪ್ಪು ಋಣಾತ್ಮಕ ಅಥವಾ ತಪ್ಪು ಧನಾತ್ಮಕ. ಎಲ್ಲಾ ಉತ್ಪನ್ನಗಳು ವಿಭಿನ್ನವಾಗಿವೆ, ಎಲ್ಲಾ ವಿಭಿನ್ನ ಚೌಕಟ್ಟುಗಳು ಮತ್ತು ತಮ್ಮದೇ ಆದ ಕೋಡಿಂಗ್ ಶೈಲಿಯನ್ನು ಬಳಸುತ್ತವೆ. ವಿಭಿನ್ನ ಕೋಡ್‌ಬೇಸ್‌ಗಳು ಮತ್ತು ತಂತ್ರಜ್ಞಾನಗಳಲ್ಲಿ, ಉಪಕರಣಗಳು ವಿವಿಧ ಹಂತದ ತಪ್ಪು ಋಣಾತ್ಮಕ ಮತ್ತು ತಪ್ಪು ಧನಾತ್ಮಕತೆಯನ್ನು ತೋರಿಸಬಹುದು. ಆದ್ದರಿಂದ ನಿಖರವಾಗಿ ಏನಿದೆ ಎಂಬುದನ್ನು ನೋಡಿ ನಿಮ್ಮ ಕಂಪನಿಗಳು ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಉತ್ತಮ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ಫಲಿತಾಂಶಗಳನ್ನು ತೋರಿಸುತ್ತವೆ.

ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪರಿಕರಗಳೊಂದಿಗೆ ಯಾವುದೇ ಸಂಯೋಜನೆಗಳಿಲ್ಲ. ನೀವು ಈಗಾಗಲೇ ಬಳಸುವುದರೊಂದಿಗೆ ಏಕೀಕರಣದ ವಿಷಯದಲ್ಲಿ ಪರಿಕರಗಳನ್ನು ನೋಡಿ. ಉದಾಹರಣೆಗೆ, ನೀವು ಜೆಂಕಿನ್ಸ್ ಅಥವಾ ಟೀಮ್‌ಸಿಟಿಯನ್ನು ಹೊಂದಿದ್ದರೆ, ಈ ಸಾಫ್ಟ್‌ವೇರ್‌ನೊಂದಿಗೆ ಪರಿಕರಗಳ ಏಕೀಕರಣವನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ನೀವು ಬಳಸದ GitLab CI ಜೊತೆಗೆ ಅಲ್ಲ.

ಗ್ರಾಹಕೀಕರಣದ ಕೊರತೆ ಅಥವಾ ಅತಿಯಾದ ಸಂಕೀರ್ಣತೆ. ಉಪಕರಣವು API ಅನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಅದು ಏಕೆ ಬೇಕು? ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಮಾಡಬಹುದಾದ ಎಲ್ಲವೂ API ಮೂಲಕ ಲಭ್ಯವಿರಬೇಕು. ತಾತ್ತ್ವಿಕವಾಗಿ, ಪರಿಕರವು ತಪಾಸಣೆಗಳನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರಬೇಕು.

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

ಪ್ರಕ್ರಿಯೆಯ ವೈಶಿಷ್ಟ್ಯಗಳು

ಉಪಕರಣಗಳ ವೈಶಿಷ್ಟ್ಯಗಳ ಜೊತೆಗೆ, ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಿ. ಉದಾಹರಣೆಗೆ, ಅಭಿವೃದ್ಧಿಯನ್ನು ತಡೆಯುವುದು ಸಾಮಾನ್ಯ ತಪ್ಪು. ಯಾವ ಇತರ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು ಮತ್ತು ಭದ್ರತಾ ತಂಡವು ಯಾವುದಕ್ಕೆ ಗಮನ ಕೊಡಬೇಕು ಎಂಬುದನ್ನು ನೋಡೋಣ.

ಅಭಿವೃದ್ಧಿಯನ್ನು ಕಳೆದುಕೊಳ್ಳದಿರಲು ಮತ್ತು ಗಡುವನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು, ರಚಿಸಿ ವಿವಿಧ ನಿಯಮಗಳು ಮತ್ತು ವಿಭಿನ್ನ ಪ್ರದರ್ಶನ ನಿಲುಗಡೆಗಳು - ದುರ್ಬಲತೆಗಳ ಉಪಸ್ಥಿತಿಯಲ್ಲಿ ನಿರ್ಮಾಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಲ್ಲಿಸುವ ಮಾನದಂಡಗಳು - ವಿವಿಧ ಪರಿಸರಗಳಿಗೆ. ಉದಾಹರಣೆಗೆ, ಪ್ರಸ್ತುತ ಶಾಖೆಯು ಅಭಿವೃದ್ಧಿ ಸ್ಟ್ಯಾಂಡ್ ಅಥವಾ UAT ಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ, ಅಂದರೆ ನಾವು ನಿಲ್ಲಿಸುವುದಿಲ್ಲ ಮತ್ತು ಹೇಳುವುದಿಲ್ಲ:

"ನೀವು ಇಲ್ಲಿ ದುರ್ಬಲತೆಯನ್ನು ಹೊಂದಿದ್ದೀರಿ, ನೀವು ಮುಂದೆ ಎಲ್ಲಿಯೂ ಹೋಗುವುದಿಲ್ಲ!"

ಈ ಹಂತದಲ್ಲಿ, ಗಮನ ಅಗತ್ಯವಿರುವ ಭದ್ರತಾ ಸಮಸ್ಯೆಗಳಿವೆ ಎಂದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಹೇಳುವುದು ಮುಖ್ಯವಾಗಿದೆ.

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

- ಹುಡುಗರೇ, ನಿಮಗೆ ಸಮಸ್ಯೆಗಳಿವೆ, ದಯವಿಟ್ಟು ಅವರಿಗೆ ಗಮನ ಕೊಡಿ.

UAT ಹಂತದಲ್ಲಿ ನಾವು ಮತ್ತೊಮ್ಮೆ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಎಚ್ಚರಿಕೆಗಳನ್ನು ತೋರಿಸುತ್ತೇವೆ ಮತ್ತು ಬಿಡುಗಡೆಯ ಹಂತದಲ್ಲಿ ನಾವು ಹೇಳುತ್ತೇವೆ:

- ಹುಡುಗರೇ, ನಾವು ನಿಮಗೆ ಹಲವಾರು ಬಾರಿ ಎಚ್ಚರಿಕೆ ನೀಡಿದ್ದೇವೆ, ನೀವು ಏನನ್ನೂ ಮಾಡಿಲ್ಲ - ನಾವು ಇದನ್ನು ನಿಮಗೆ ಬಿಡುವುದಿಲ್ಲ.

ನಾವು ಕೋಡ್ ಮತ್ತು ಡೈನಾಮಿಕ್ಸ್ ಬಗ್ಗೆ ಮಾತನಾಡಿದರೆ, ಈ ವೈಶಿಷ್ಟ್ಯದಲ್ಲಿ ಈಗಷ್ಟೇ ಬರೆಯಲಾದ ವೈಶಿಷ್ಟ್ಯಗಳು ಮತ್ತು ಕೋಡ್‌ಗಳ ದುರ್ಬಲತೆಗಳನ್ನು ಮಾತ್ರ ತೋರಿಸುವುದು ಮತ್ತು ಎಚ್ಚರಿಸುವುದು ಅವಶ್ಯಕ. ಡೆವಲಪರ್ 3 ಪಿಕ್ಸೆಲ್‌ಗಳಷ್ಟು ಬಟನ್ ಅನ್ನು ಚಲಿಸಿದರೆ ಮತ್ತು ಅವರು ಅಲ್ಲಿ SQL ಇಂಜೆಕ್ಷನ್ ಅನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಆದ್ದರಿಂದ ತುರ್ತಾಗಿ ಸರಿಪಡಿಸಬೇಕಾಗಿದೆ ಎಂದು ನಾವು ಅವನಿಗೆ ಹೇಳಿದರೆ, ಇದು ತಪ್ಪು. ಈಗ ಬರೆದಿರುವುದನ್ನು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಬರುವ ಬದಲಾವಣೆಯನ್ನು ಮಾತ್ರ ನೋಡಿ.

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

ಎಲ್ಲಾ ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟದ ಸಮಸ್ಯೆಗಳು ಭದ್ರತಾ ಸಮಸ್ಯೆಗಳಲ್ಲ. ಆದರೆ ಎಲ್ಲಾ ಭದ್ರತಾ ಸಮಸ್ಯೆಗಳು ಸಾಫ್ಟ್‌ವೇರ್ ಗುಣಮಟ್ಟಕ್ಕೆ ಸಂಬಂಧಿಸಿವೆ. ಶೆರಿಫ್ ಮನ್ಸೂರ್, ಎಕ್ಸ್‌ಪೀಡಿಯಾ.

ಎಲ್ಲಾ ದುರ್ಬಲತೆಗಳು ಒಂದೇ ದೋಷಗಳಾಗಿರುವುದರಿಂದ, ಎಲ್ಲಾ ಅಭಿವೃದ್ಧಿ ದೋಷಗಳಂತೆಯೇ ಅವು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿರಬೇಕು. ಆದ್ದರಿಂದ ಯಾರೂ ಓದದ ವರದಿಗಳು ಮತ್ತು ಭಯಾನಕ PDF ಗಳನ್ನು ಮರೆತುಬಿಡಿ.

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

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

ಸ್ಥಾಯೀ ವಿಶ್ಲೇಷಣೆ - SAST

ಇದು ದುರ್ಬಲತೆಗಳ ಕೋಡ್ ವಿಶ್ಲೇಷಣೆಯಾಗಿದೆ., ಆದರೆ ಇದು SonarQube ನಂತೆಯೇ ಅಲ್ಲ. ನಾವು ಕೇವಲ ಮಾದರಿಗಳು ಅಥವಾ ಶೈಲಿಯನ್ನು ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ. ವಿಶ್ಲೇಷಣೆಯಲ್ಲಿ ಹಲವಾರು ವಿಧಾನಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ: ದುರ್ಬಲತೆಯ ಮರದ ಪ್ರಕಾರ, ಪ್ರಕಾರ ದತ್ತಾಂಶ ಹರಿವು, ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುವ ಮೂಲಕ. ಇದು ಕೋಡ್‌ಗೆ ಸಂಬಂಧಿಸಿದೆ.

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

ಮಿನುಸು - ಇದು ಅಗತ್ಯ ಭಾಷೆಗಳಿಗೆ ಬೆಂಬಲದ ಕೊರತೆ.

ಅಗತ್ಯ ಸಂಯೋಜನೆಗಳು, ನನ್ನ ವ್ಯಕ್ತಿನಿಷ್ಠ ಅಭಿಪ್ರಾಯದಲ್ಲಿ ಇದು ಉಪಕರಣಗಳಲ್ಲಿ ಇರಬೇಕು:

• ಏಕೀಕರಣ ಸಾಧನ: ಜೆಂಕಿನ್ಸ್, ಟೀಮ್‌ಸಿಟಿ ಮತ್ತು ಗಿಟ್ಲಾಬ್ CI.
• ಅಭಿವೃದ್ಧಿ ಪರಿಸರ: Intellij IDEA, ವಿಷುಯಲ್ ಸ್ಟುಡಿಯೋ. ಡೆವಲಪರ್‌ಗೆ ಇನ್ನೂ ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬೇಕಾದ ಗ್ರಹಿಸಲಾಗದ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನ್ಯಾವಿಗೇಟ್ ಮಾಡದಿರುವುದು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿದೆ, ಆದರೆ ತನ್ನ ಸ್ವಂತ ಅಭಿವೃದ್ಧಿ ಪರಿಸರದಲ್ಲಿ ಕೆಲಸದ ಸ್ಥಳದಲ್ಲಿ ಅವನು ಕಂಡುಕೊಂಡ ಎಲ್ಲಾ ಅಗತ್ಯ ಸಂಯೋಜನೆಗಳು ಮತ್ತು ದುರ್ಬಲತೆಗಳನ್ನು ನೋಡಲು.
• ಕೋಡ್ ವಿಮರ್ಶೆ: SonarQube ಮತ್ತು ಹಸ್ತಚಾಲಿತ ವಿಮರ್ಶೆ.
• ದೋಷ ಟ್ರ್ಯಾಕರ್‌ಗಳು: ಜಿರಾ ಮತ್ತು ಬಗ್ಜಿಲ್ಲಾ.

ಚಿತ್ರವು ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯ ಕೆಲವು ಅತ್ಯುತ್ತಮ ಪ್ರತಿನಿಧಿಗಳನ್ನು ತೋರಿಸುತ್ತದೆ.

ಇದು ಮುಖ್ಯವಾದ ಸಾಧನಗಳಲ್ಲ, ಆದರೆ ಪ್ರಕ್ರಿಯೆ, ಆದ್ದರಿಂದ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಉತ್ತಮವಾದ ಓಪನ್ ಸೋರ್ಸ್ ಪರಿಹಾರಗಳಿವೆ.

SAST ಮುಕ್ತ ಮೂಲವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ದುರ್ಬಲತೆಗಳು ಅಥವಾ ಸಂಕೀರ್ಣ ಡೇಟಾಫ್ಲೋಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದಿಲ್ಲ, ಆದರೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿರ್ಮಿಸುವಾಗ ಅವುಗಳನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಬಳಸಬೇಕು. ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಲಾಗುವುದು, ಯಾರು ದೋಷಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಾರೆ, ಯಾರು ವರದಿ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಯಾರು ವರದಿ ಮಾಡುತ್ತಾರೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಅವರು ಸಹಾಯ ಮಾಡುತ್ತಾರೆ. ನಿಮ್ಮ ಕೋಡ್‌ನ ಭದ್ರತೆಯನ್ನು ನಿರ್ಮಿಸುವ ಆರಂಭಿಕ ಹಂತವನ್ನು ಕೈಗೊಳ್ಳಲು ನೀವು ಬಯಸಿದರೆ, ಓಪನ್ ಸೋರ್ಸ್ ಪರಿಹಾರಗಳನ್ನು ಬಳಸಿ.

ನೀವು ನಿಮ್ಮ ಪ್ರಯಾಣದ ಆರಂಭದಲ್ಲಿ ಮತ್ತು ಏನೂ ಹೊಂದಿಲ್ಲದಿದ್ದರೆ ಇದನ್ನು ಹೇಗೆ ಸಂಯೋಜಿಸಬಹುದು: CI ಇಲ್ಲ, ಜೆಂಕಿನ್ಸ್ ಇಲ್ಲ, ಟೀಮ್‌ಸಿಟಿ ಇಲ್ಲ? ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಏಕೀಕರಣವನ್ನು ಪರಿಗಣಿಸೋಣ.

CVS ಮಟ್ಟದ ಏಕೀಕರಣ

ನೀವು Bitbucket ಅಥವಾ GitLab ಹೊಂದಿದ್ದರೆ, ನೀವು ಮಟ್ಟದಲ್ಲಿ ಸಂಯೋಜಿಸಬಹುದು ಏಕಕಾಲಿಕ ಆವೃತ್ತಿಗಳ ವ್ಯವಸ್ಥೆ.

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

ಪ್ರತಿಕ್ರಿಯೆ ಸಹಜವಾಗಿ, ಪ್ರತಿಕ್ರಿಯೆ ಯಾವಾಗಲೂ ಅಗತ್ಯವಿದೆ. ನೀವು ಬದಿಯಲ್ಲಿ ಭದ್ರತೆಯನ್ನು ಮಾಡಿದರೆ, ಅದನ್ನು ಪೆಟ್ಟಿಗೆಯಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಯಾರಿಗೂ ಏನನ್ನೂ ಹೇಳದಿದ್ದರೆ, ಮತ್ತು ತಿಂಗಳ ಕೊನೆಯಲ್ಲಿ ದೋಷಗಳ ಗುಂಪನ್ನು ಎಸೆದರು - ಇದು ಸರಿಯಾಗಿಲ್ಲ ಮತ್ತು ಒಳ್ಳೆಯದಲ್ಲ.

ಕೋಡ್ ವಿಮರ್ಶೆ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಏಕೀಕರಣ

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

SonarQube ಜೊತೆ ಏಕೀಕರಣ

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

CI ಮಟ್ಟದಲ್ಲಿ ಏಕೀಕರಣ

ಇಲ್ಲಿ ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿದೆ:

• ಆಟೋಟೆಸ್ಟ್‌ಗಳಿಗೆ ಸಮಾನವಾಗಿ, ಘಟಕ ಪರೀಕ್ಷೆಗಳು.
• ಅಭಿವೃದ್ಧಿ ಹಂತಗಳ ಮೂಲಕ ವಿಭಾಗ: ದೇವ್, ಪರೀಕ್ಷೆ, ಉತ್ಪನ್ನ. ವಿಭಿನ್ನ ನಿಯಮಗಳ ಸೆಟ್ ಅಥವಾ ವಿಭಿನ್ನ ವಿಫಲ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಸೇರಿಸಿಕೊಳ್ಳಬಹುದು: ಅಸೆಂಬ್ಲಿಯನ್ನು ನಿಲ್ಲಿಸಿ, ಅಸೆಂಬ್ಲಿಯನ್ನು ನಿಲ್ಲಿಸಬೇಡಿ.
• ಸಿಂಕ್ರೊನಸ್/ಅಸಿಂಕ್ರೊನಸ್ ಲಾಂಚ್. ಭದ್ರತಾ ಪರೀಕ್ಷೆಗಳ ಅಂತ್ಯಕ್ಕಾಗಿ ನಾವು ಕಾಯುತ್ತಿದ್ದೇವೆ ಅಥವಾ ಇಲ್ಲ. ಅಂದರೆ, ನಾವು ಅವುಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು ಮುಂದುವರಿಯುತ್ತೇವೆ ಮತ್ತು ನಂತರ ನಾವು ಎಲ್ಲವೂ ಒಳ್ಳೆಯದು ಅಥವಾ ಕೆಟ್ಟದು ಎಂಬ ಸ್ಥಿತಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ.

ಇದು ಎಲ್ಲಾ ಪರಿಪೂರ್ಣ ಗುಲಾಬಿ ಜಗತ್ತಿನಲ್ಲಿ. ನಿಜ ಜೀವನದಲ್ಲಿ ಅಂತಹ ವಿಷಯಗಳಿಲ್ಲ, ಆದರೆ ನಾವು ಶ್ರಮಿಸುತ್ತೇವೆ. ಚಾಲನೆಯಲ್ಲಿರುವ ಭದ್ರತಾ ತಪಾಸಣೆಯ ಫಲಿತಾಂಶವು ಘಟಕ ಪರೀಕ್ಷೆಗಳ ಫಲಿತಾಂಶಗಳಂತೆಯೇ ಇರಬೇಕು.

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

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

ಭದ್ರತಾ ಗೇಟ್‌ನ ಉದಾಹರಣೆಯೆಂದರೆ ಕೋಡ್‌ನಲ್ಲಿನ ದೋಷಗಳ ಉಪಸ್ಥಿತಿ ಮತ್ತು ಸಂಖ್ಯೆಯ ದೃಷ್ಟಿಯಿಂದ ಗುಣಮಟ್ಟದ ಗೇಟ್‌ನ ಅನಲಾಗ್.

ನಾವು SonarQube ನೊಂದಿಗೆ ಸಂಯೋಜಿಸುತ್ತೇವೆ - ಪ್ಲಗಿನ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಎಲ್ಲವೂ ತುಂಬಾ ಅನುಕೂಲಕರ ಮತ್ತು ತಂಪಾಗಿದೆ.

ಅಭಿವೃದ್ಧಿ ಪರಿಸರದೊಂದಿಗೆ ಏಕೀಕರಣ

ಏಕೀಕರಣ ಆಯ್ಕೆಗಳು:

• ಬದ್ಧತೆಯ ಮೊದಲು ಅಭಿವೃದ್ಧಿ ಪರಿಸರದಿಂದ ಸ್ಕ್ಯಾನ್ ಅನ್ನು ರನ್ ಮಾಡುವುದು.
• ಫಲಿತಾಂಶಗಳನ್ನು ವೀಕ್ಷಿಸಿ.
• ಫಲಿತಾಂಶಗಳ ವಿಶ್ಲೇಷಣೆ.
• ಸರ್ವರ್ನೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸೇಶನ್.

ಸರ್ವರ್‌ನಿಂದ ಫಲಿತಾಂಶಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಇದು ತೋರುತ್ತಿದೆ.

ನಮ್ಮ ಅಭಿವೃದ್ಧಿ ಪರಿಸರದಲ್ಲಿ ಇಂಟೆಲ್ಲಿಜ್ ಐಡಿಇಎ ಸ್ಕ್ಯಾನ್ ಸಮಯದಲ್ಲಿ ಅಂತಹ ದೋಷಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲಾಗಿದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿಸುವ ಹೆಚ್ಚುವರಿ ಐಟಂ ಸರಳವಾಗಿ ಗೋಚರಿಸುತ್ತದೆ. ನೀವು ತಕ್ಷಣ ಕೋಡ್ ಅನ್ನು ಸಂಪಾದಿಸಬಹುದು, ಶಿಫಾರಸುಗಳನ್ನು ನೋಡಬಹುದು ಮತ್ತು ಫ್ಲೋ ಗ್ರಾಫ್. ಇದೆಲ್ಲವೂ ಡೆವಲಪರ್‌ನ ಕೆಲಸದ ಸ್ಥಳದಲ್ಲಿದೆ, ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ - ಇತರ ಲಿಂಕ್‌ಗಳನ್ನು ಅನುಸರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಹೆಚ್ಚುವರಿ ಏನನ್ನಾದರೂ ನೋಡುವ ಅಗತ್ಯವಿಲ್ಲ.

ಓಪನ್ ಸೋರ್ಸ್

ಇದು ನನ್ನ ನೆಚ್ಚಿನ ವಿಷಯವಾಗಿದೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಓಪನ್ ಸೋರ್ಸ್ ಲೈಬ್ರರಿಗಳನ್ನು ಬಳಸುತ್ತಾರೆ - ನೀವು ಈಗಾಗಲೇ ಎಲ್ಲವನ್ನೂ ಅಳವಡಿಸಲಾಗಿರುವ ರೆಡಿಮೇಡ್ ಲೈಬ್ರರಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದಾದಾಗ ಊರುಗೋಲು ಮತ್ತು ಬೈಸಿಕಲ್ಗಳ ಗುಂಪನ್ನು ಏಕೆ ಬರೆಯಬೇಕು?

ಸಹಜವಾಗಿ, ಇದು ನಿಜ, ಆದರೆ ಗ್ರಂಥಾಲಯಗಳು ಸಹ ಜನರಿಂದ ಬರೆಯಲ್ಪಟ್ಟಿವೆ, ಅವುಗಳು ಕೆಲವು ಅಪಾಯಗಳನ್ನು ಸಹ ಒಳಗೊಂಡಿರುತ್ತವೆ ಮತ್ತು ನಿಯತಕಾಲಿಕವಾಗಿ ಅಥವಾ ನಿರಂತರವಾಗಿ ವರದಿಯಾಗುವ ದುರ್ಬಲತೆಗಳೂ ಇವೆ. ಆದ್ದರಿಂದ, ಅಪ್ಲಿಕೇಶನ್ ಭದ್ರತೆಯಲ್ಲಿ ಮುಂದಿನ ಹಂತವಿದೆ - ಇದು ಓಪನ್ ಸೋರ್ಸ್ ಘಟಕಗಳ ವಿಶ್ಲೇಷಣೆಯಾಗಿದೆ.

ತೆರೆದ ಮೂಲ ವಿಶ್ಲೇಷಣೆ - OSA

ಉಪಕರಣವು ಮೂರು ದೊಡ್ಡ ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

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

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

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

ಅವಕಾಶಗಳು:

• ಅಭಿವೃದ್ಧಿಯ ವಿವಿಧ ಹಂತಗಳಿಗೆ ವಿಭಿನ್ನ ನೀತಿಗಳು.
• ಕೈಗಾರಿಕಾ ಪರಿಸರದಲ್ಲಿ ಘಟಕಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು.
• ಸಂಸ್ಥೆಯೊಳಗೆ ಗ್ರಂಥಾಲಯಗಳ ನಿಯಂತ್ರಣ.
• ವಿವಿಧ ನಿರ್ಮಾಣ ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು ಭಾಷೆಗಳಿಗೆ ಬೆಂಬಲ.
• ಡಾಕರ್ ಚಿತ್ರಗಳ ವಿಶ್ಲೇಷಣೆ.

ಓಪನ್ ಸೋರ್ಸ್ ವಿಶ್ಲೇಷಣೆಯಲ್ಲಿ ತೊಡಗಿರುವ ಉದ್ಯಮದ ಪ್ರಮುಖರ ಕೆಲವು ಉದಾಹರಣೆಗಳು.

ಇದೊಂದೇ ಉಚಿತ ಅವಲಂಬನೆ-ಪರಿಶೀಲನೆ OWASP ನಿಂದ. ನೀವು ಅದನ್ನು ಮೊದಲ ಹಂತಗಳಲ್ಲಿ ಆನ್ ಮಾಡಬಹುದು, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅದು ಏನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಿ. ಮೂಲಭೂತವಾಗಿ, ಇವುಗಳು ಎಲ್ಲಾ ಕ್ಲೌಡ್ ಉತ್ಪನ್ನಗಳು, ಅಥವಾ ಆನ್-ಪ್ರೇಮಿಸ್, ಆದರೆ ಅವುಗಳ ಆಧಾರದ ಹಿಂದೆ ಅವುಗಳನ್ನು ಇನ್ನೂ ಇಂಟರ್ನೆಟ್ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಅವರು ನಿಮ್ಮ ಲೈಬ್ರರಿಗಳನ್ನು ಕಳುಹಿಸುವುದಿಲ್ಲ, ಆದರೆ ಹ್ಯಾಶ್‌ಗಳು ಅಥವಾ ತಮ್ಮದೇ ಆದ ಮೌಲ್ಯಗಳನ್ನು ಅವರು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ದೋಷಗಳ ಉಪಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಸ್ವೀಕರಿಸಲು ಫಿಂಗರ್‌ಪ್ರಿಂಟ್‌ಗಳನ್ನು ತಮ್ಮ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸುತ್ತಾರೆ.

ಪ್ರಕ್ರಿಯೆ ಏಕೀಕರಣ

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

CI ಗೆ ಏಕೀಕರಣ. ಆಟೋಟೆಸ್ಟ್‌ಗಳೊಂದಿಗೆ ಅದೇ ಮಟ್ಟದಲ್ಲಿ, ಘಟಕ ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಹಂತಗಳಾಗಿ ವಿಭಜನೆ: dev, test, prod. ಪ್ರತಿ ಹಂತದಲ್ಲಿ, ನೀವು ಯಾವುದೇ ಲೈಬ್ರರಿಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬಹುದು, ಯಾವುದನ್ನಾದರೂ ಬಳಸಬಹುದು, ಆದರೆ “ನಿರ್ಣಾಯಕ” ಸ್ಥಿತಿಯೊಂದಿಗೆ ಏನಾದರೂ ಕಠಿಣವಾಗಿದ್ದರೆ, ಬಹುಶಃ ಉತ್ಪಾದನೆಗೆ ಬಿಡುಗಡೆಯ ಹಂತದಲ್ಲಿ ಡೆವಲಪರ್‌ಗಳ ಗಮನವನ್ನು ಸೆಳೆಯುವುದು ಯೋಗ್ಯವಾಗಿದೆ.

ಕಲಾಕೃತಿಗಳೊಂದಿಗೆ ಏಕೀಕರಣ: ನೆಕ್ಸಸ್ ಮತ್ತು ಜೆಫ್ರಾಗ್.

ಅಭಿವೃದ್ಧಿ ಪರಿಸರಕ್ಕೆ ಏಕೀಕರಣ. ನೀವು ಆಯ್ಕೆ ಮಾಡುವ ಉಪಕರಣಗಳು ಅಭಿವೃದ್ಧಿ ಪರಿಸರಗಳೊಂದಿಗೆ ಏಕೀಕರಣವನ್ನು ಹೊಂದಿರಬೇಕು. ಡೆವಲಪರ್ ತನ್ನ ಕೆಲಸದ ಸ್ಥಳದಿಂದ ಸ್ಕ್ಯಾನಿಂಗ್ ಫಲಿತಾಂಶಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರಬೇಕು ಅಥವಾ CVS ಗೆ ಒಪ್ಪಿಸುವ ಮೊದಲು ದೋಷಗಳಿಗಾಗಿ ಕೋಡ್ ಅನ್ನು ಸ್ವತಃ ಸ್ಕ್ಯಾನ್ ಮಾಡುವ ಮತ್ತು ಪರಿಶೀಲಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರಬೇಕು.

ಸಿಡಿ ಏಕೀಕರಣ. ಇದು ನಾನು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಡುವ ತಂಪಾದ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ ಮತ್ತು ನಾನು ಈಗಾಗಲೇ ಮಾತನಾಡಿದ್ದೇನೆ - ಕೈಗಾರಿಕಾ ಪರಿಸರದಲ್ಲಿ ಹೊಸ ದುರ್ಬಲತೆಗಳ ಹೊರಹೊಮ್ಮುವಿಕೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು. ಇದು ಈ ರೀತಿಯ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

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

• ನಿರ್ಮಿಸುವಾಗ, ಯಾರೂ ಕೆಟ್ಟದ್ದನ್ನು ಸ್ಲಿಪ್ ಮಾಡಿಲ್ಲ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ, ಎಲ್ಲಾ ಘಟಕಗಳು ಸುರಕ್ಷಿತವಾಗಿವೆ ಮತ್ತು ಯಾರೂ ಫ್ಲಾಶ್ ಡ್ರೈವಿನಲ್ಲಿ ಅಪಾಯಕಾರಿ ಏನನ್ನೂ ತಂದಿಲ್ಲ.
• ನಾವು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ವಿಶ್ವಾಸಾರ್ಹ ಘಟಕಗಳನ್ನು ಮಾತ್ರ ಹೊಂದಿದ್ದೇವೆ.
• ನಿಯೋಜಿಸುವಾಗ, ನಾವು ಮತ್ತೊಮ್ಮೆ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ: ಯುದ್ಧ, ಜಾರ್, DL ಅಥವಾ ಡಾಕರ್ ಚಿತ್ರವು ನೀತಿಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು.
• ಉದ್ಯಮಕ್ಕೆ ಪ್ರವೇಶಿಸುವಾಗ, ಕೈಗಾರಿಕಾ ಪರಿಸರದಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ನಾವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ: ನಿರ್ಣಾಯಕ ದುರ್ಬಲತೆಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ಅಥವಾ ಕಾಣಿಸುವುದಿಲ್ಲ.

ಡೈನಾಮಿಕ್ ಅನಾಲಿಸಿಸ್ - DAST

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

ಅದೇ ವ್ಯವಸ್ಥೆಯು ಓಪನ್ ಸೋರ್ಸ್‌ನಲ್ಲಿ ಟೆಂಪ್ಲೇಟ್ ದೋಷಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನಾವು ಯಾವ ಓಪನ್ ಸೋರ್ಸ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ ಎಂದು DAST ಗೆ ತಿಳಿದಿಲ್ಲವಾದ್ದರಿಂದ, ಅದು "ದುರುದ್ದೇಶಪೂರಿತ" ಮಾದರಿಗಳನ್ನು ಎಸೆಯುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್‌ನ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತದೆ:

- ಹೌದು, ಇಲ್ಲಿ ಡಿಸೈಲೈಸೇಶನ್ ಸಮಸ್ಯೆ ಇದೆ, ಆದರೆ ಇಲ್ಲಿ ಅಲ್ಲ.

ಇದರಲ್ಲಿ ದೊಡ್ಡ ಅಪಾಯಗಳಿವೆ, ಏಕೆಂದರೆ ಪರೀಕ್ಷಕರು ಕೆಲಸ ಮಾಡುವ ಅದೇ ಬೆಂಚ್ನಲ್ಲಿ ನೀವು ಈ ಭದ್ರತಾ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿದರೆ, ಅಹಿತಕರ ಸಂಗತಿಗಳು ಸಂಭವಿಸಬಹುದು.

• ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಲೋಡ್.
• ಯಾವುದೇ ಸಂಯೋಜನೆಗಳಿಲ್ಲ.
• ವಿಶ್ಲೇಷಿಸಿದ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುವ ಸಾಮರ್ಥ್ಯ.
• ಅಗತ್ಯ ತಂತ್ರಜ್ಞಾನಗಳಿಗೆ ಯಾವುದೇ ಬೆಂಬಲವಿಲ್ಲ.
• ಹೊಂದಿಸುವಲ್ಲಿ ತೊಂದರೆ.

ನಾವು ಅಂತಿಮವಾಗಿ AppScan ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ ನಾವು ಪರಿಸ್ಥಿತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ: ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆಯಲು ನಾವು ಬಹಳ ಸಮಯ ಕಳೆದಿದ್ದೇವೆ, 3 ಖಾತೆಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಸಂತೋಷಪಟ್ಟಿದ್ದೇವೆ - ನಾವು ಅಂತಿಮವಾಗಿ ಎಲ್ಲವನ್ನೂ ಪರಿಶೀಲಿಸುತ್ತೇವೆ! ನಾವು ಸ್ಕ್ಯಾನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು AppScan ಮಾಡಿದ ಮೊದಲ ಕೆಲಸವೆಂದರೆ ನಿರ್ವಾಹಕ ಫಲಕಕ್ಕೆ ಹೋಗಿ, ಎಲ್ಲಾ ಬಟನ್‌ಗಳನ್ನು ಚುಚ್ಚಿ, ಅರ್ಧದಷ್ಟು ಡೇಟಾವನ್ನು ಬದಲಾಯಿಸಿ ಮತ್ತು ನಂತರ ಅದರೊಂದಿಗೆ ಸರ್ವರ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕೊಲ್ಲುತ್ತದೆ. ಅಂಚೆ ರೂಪ- ವಿನಂತಿಗಳು. ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ಅಭಿವೃದ್ಧಿ ಹೇಳಿದರು:

- ಹುಡುಗರೇ, ನೀವು ನನ್ನನ್ನು ತಮಾಷೆ ಮಾಡುತ್ತಿದ್ದೀರಾ?! ನಾವು ನಿಮಗೆ ಖಾತೆಗಳನ್ನು ನೀಡಿದ್ದೇವೆ ಮತ್ತು ನೀವು ಸ್ಟ್ಯಾಂಡ್ ಅನ್ನು ಹೊಂದಿಸಿ!

ಸಂಭವನೀಯ ಅಪಾಯಗಳನ್ನು ಪರಿಗಣಿಸಿ. ತಾತ್ತ್ವಿಕವಾಗಿ, ಮಾಹಿತಿ ಸುರಕ್ಷತೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಪ್ರತ್ಯೇಕ ಸ್ಟ್ಯಾಂಡ್ ಅನ್ನು ತಯಾರಿಸಿ, ಅದು ಕನಿಷ್ಠ ಹೇಗಾದರೂ ಉಳಿದ ಪರಿಸರದಿಂದ ಪ್ರತ್ಯೇಕಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ನಿರ್ವಾಹಕ ಫಲಕವನ್ನು ಷರತ್ತುಬದ್ಧವಾಗಿ ಪರಿಶೀಲಿಸಿ, ಮೇಲಾಗಿ ಹಸ್ತಚಾಲಿತ ಕ್ರಮದಲ್ಲಿ. ಇದು ಪೆಂಟೆಸ್ಟ್ - ನಾವು ಈಗ ಪರಿಗಣಿಸದಿರುವ ಪ್ರಯತ್ನದ ಉಳಿದ ಶೇಕಡಾವಾರು.

ನೀವು ಇದನ್ನು ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಅನಲಾಗ್ ಆಗಿ ಬಳಸಬಹುದು ಎಂದು ಪರಿಗಣಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಮೊದಲ ಹಂತದಲ್ಲಿ, ನೀವು 10-15 ಥ್ರೆಡ್‌ಗಳೊಂದಿಗೆ ಡೈನಾಮಿಕ್ ಸ್ಕ್ಯಾನರ್ ಅನ್ನು ಆನ್ ಮಾಡಬಹುದು ಮತ್ತು ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಬಹುದು, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ, ಅಭ್ಯಾಸವು ತೋರಿಸಿದಂತೆ, ಏನೂ ಉತ್ತಮವಾಗಿಲ್ಲ.

ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸುವ ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳು.

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

ಪ್ರಕ್ರಿಯೆ ಏಕೀಕರಣ

ಏಕೀಕರಣವು ಚೆನ್ನಾಗಿ ಮತ್ತು ಸರಳವಾಗಿ ನಡೆಯುತ್ತದೆ: ಯಶಸ್ವಿ ಅನುಸ್ಥಾಪನೆಯ ನಂತರ ಸ್ಕ್ಯಾನಿಂಗ್ ಪ್ರಾರಂಭಿಸಿ ಸ್ಟ್ಯಾಂಡ್ಗಾಗಿ ಅರ್ಜಿಗಳು ಮತ್ತು ಯಶಸ್ವಿ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಯ ನಂತರ ಸ್ಕ್ಯಾನಿಂಗ್.

ಏಕೀಕರಣಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸದಿದ್ದರೆ ಅಥವಾ ಸ್ಟಬ್‌ಗಳು ಮತ್ತು ಮೋಕ್ ಫಂಕ್ಷನ್‌ಗಳಿದ್ದರೆ, ಅದು ಅರ್ಥಹೀನ ಮತ್ತು ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿದೆ - ನಾವು ಯಾವ ಮಾದರಿಯನ್ನು ಕಳುಹಿಸಿದರೂ, ಸರ್ವರ್ ಅದೇ ರೀತಿಯಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ.

• ತಾತ್ತ್ವಿಕವಾಗಿ, ಪ್ರತ್ಯೇಕ ಪರೀಕ್ಷಾ ನಿಲುವು.
• ಪರೀಕ್ಷಿಸುವ ಮೊದಲು, ಲಾಗಿನ್ ಅನುಕ್ರಮವನ್ನು ಬರೆಯಿರಿ.
• ಆಡಳಿತ ವ್ಯವಸ್ಥೆಯ ಪರೀಕ್ಷೆಯು ಕೈಯಿಂದ ಮಾತ್ರ.

ಪ್ರಕ್ರಿಯೆ

ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಕ್ರಿಯೆಯ ಬಗ್ಗೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ ಪ್ರತಿ ಉಪಕರಣದ ಕೆಲಸದ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಸಾಮಾನ್ಯೀಕರಿಸಲಾಗಿದೆ. ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ವಿಭಿನ್ನವಾಗಿವೆ - ಒಂದು ಡೈನಾಮಿಕ್ ವಿಶ್ಲೇಷಣೆಯೊಂದಿಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇನ್ನೊಂದು ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯೊಂದಿಗೆ, ಮೂರನೆಯದು ಓಪನ್‌ಸೋರ್ಸ್ ವಿಶ್ಲೇಷಣೆ, ಪೆಂಟೆಸ್ಟ್‌ಗಳು ಅಥವಾ ಒಟ್ಟಾರೆಯಾಗಿ ಬೇರೆ ಯಾವುದನ್ನಾದರೂ, ಉದಾಹರಣೆಗೆ, ಇದರೊಂದಿಗೆ ಈವೆಂಟ್‌ಗಳು Waf.

ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಗೆ ನಿಯಂತ್ರಣದ ಅಗತ್ಯವಿದೆ.

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

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

ಎಲ್ಲಾ ಸ್ಥಿರ ಮತ್ತು ಡೈನಾಮಿಕ್ ವಿಶ್ಲೇಷಕರು ತಮ್ಮದೇ ಆದ API ಗಳನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ತಮ್ಮದೇ ಆದ ಉಡಾವಣಾ ವಿಧಾನಗಳು, ತತ್ವಗಳು, ಕೆಲವು ಶೆಡ್ಯೂಲರ್‌ಗಳನ್ನು ಹೊಂದಿವೆ, ಇತರರು ಹೊಂದಿಲ್ಲ - ನಾವು ಉಪಕರಣವನ್ನು ಬರೆಯುತ್ತಿದ್ದೇವೆ AppSec ಆರ್ಕೆಸ್ಟ್ರೇಟರ್, ಇದು ಉತ್ಪನ್ನದಿಂದ ಸಂಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆಗೆ ಒಂದೇ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ರಚಿಸಲು ಮತ್ತು ಅದನ್ನು ಒಂದು ಹಂತದಿಂದ ನಿರ್ವಹಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

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

ಕೀ ಟೇಕ್ಅವೇಸ್

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

ಉತ್ಪನ್ನ ಗುಣಮಟ್ಟ - ಸಾಮಾನ್ಯ ಗುರಿ ಭದ್ರತೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಎರಡೂ. ನಾವು ಒಂದು ಕೆಲಸವನ್ನು ಮಾಡುತ್ತೇವೆ, ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಖ್ಯಾತಿಯ ಅಪಾಯಗಳು ಅಥವಾ ಹಣಕಾಸಿನ ನಷ್ಟಗಳಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಅದಕ್ಕಾಗಿಯೇ ನಾವು ಸಂವಹನವನ್ನು ಸುಧಾರಿಸಲು ಮತ್ತು ಉತ್ಪನ್ನದ ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸಲು DevSecOps, SecDevOps ವಿಧಾನವನ್ನು ಪ್ರಚಾರ ಮಾಡುತ್ತೇವೆ.

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

ಮಾಹಿತಿ ಭದ್ರತಾ ದೋಷಗಳು ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕ ದೋಷಗಳ ನಡುವೆ ಸಮಾನ ಚಿಹ್ನೆ ಇದೆ.

ಎಲ್ಲವನ್ನೂ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿಅದು ಚಲಿಸುತ್ತದೆ. ಯಾವುದಾದರೂ ಚಲಿಸುವುದಿಲ್ಲ, ಅದನ್ನು ಸರಿಸಿ ಮತ್ತು ಅದನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿ. ಕೈಯಿಂದ ಏನನ್ನಾದರೂ ಮಾಡಿದರೆ, ಅದು ಪ್ರಕ್ರಿಯೆಯ ಉತ್ತಮ ಭಾಗವಲ್ಲ. ಬಹುಶಃ ಅದನ್ನು ಪರಿಶೀಲಿಸುವುದು ಮತ್ತು ಅದನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ.

IS ತಂಡದ ಗಾತ್ರ ಚಿಕ್ಕದಾಗಿದ್ದರೆ - ಭದ್ರತಾ ಚಾಂಪಿಯನ್‌ಗಳನ್ನು ಬಳಸಿ.

ಬಹುಶಃ ನಾನು ಮಾತನಾಡಿದ್ದು ನಿಮಗೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ ಮತ್ತು ನೀವು ನಿಮ್ಮದೇ ಆದದನ್ನು ತರುತ್ತೀರಿ - ಮತ್ತು ಅದು ಒಳ್ಳೆಯದು. ಆದರೆ ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆಯ ಅವಶ್ಯಕತೆಗಳ ಆಧಾರದ ಮೇಲೆ ಪರಿಕರಗಳನ್ನು ಆಯ್ಕೆಮಾಡಿ. ಈ ಉಪಕರಣವು ಕೆಟ್ಟದು ಮತ್ತು ಇದು ಒಳ್ಳೆಯದು ಎಂದು ಸಮುದಾಯವು ಹೇಳುವುದನ್ನು ನೋಡಬೇಡಿ. ಬಹುಶಃ ನಿಮ್ಮ ಉತ್ಪನ್ನಕ್ಕೆ ವಿರುದ್ಧವಾಗಿರಬಹುದು.

ಉಪಕರಣಗಳಿಗೆ ಅಗತ್ಯತೆಗಳು.

• ಕಡಿಮೆ ಮಟ್ಟದ ತಪ್ಪು ಧನಾತ್ಮಕ.
• ಸಾಕಷ್ಟು ವಿಶ್ಲೇಷಣೆ ಸಮಯ.
• ಸುಲಭವಾದ ಬಳಕೆ.
• ಏಕೀಕರಣಗಳ ಲಭ್ಯತೆ.
• ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿ ಮಾರ್ಗಸೂಚಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು.
• ಪರಿಕರಗಳನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡುವ ಸಾಧ್ಯತೆ.

ಯೂರಿಯ ವರದಿಯನ್ನು DevOpsConf 2018 ರಲ್ಲಿ ಅತ್ಯುತ್ತಮವಾಗಿ ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ. ಇನ್ನಷ್ಟು ಆಸಕ್ತಿದಾಯಕ ವಿಚಾರಗಳು ಮತ್ತು ಪ್ರಾಯೋಗಿಕ ಪ್ರಕರಣಗಳೊಂದಿಗೆ ಪರಿಚಯ ಮಾಡಿಕೊಳ್ಳಲು, ಮೇ 27 ಮತ್ತು 28 ರಂದು Skolkovo ಗೆ ಬನ್ನಿ DevOpsConf ಒಳಗೆ ಹಬ್ಬ RIT++. ಇನ್ನೂ ಉತ್ತಮ, ನಿಮ್ಮ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನೀವು ಸಿದ್ಧರಾಗಿದ್ದರೆ, ಆಗ ಅನ್ವಯಿಸು ಏಪ್ರಿಲ್ 21 ರವರೆಗೆ ವರದಿಗಾಗಿ.

ಮೂಲ: www.habr.com