হাই, হ্যাকারনুন! আমার নাম সোফিয়া, এবং আমি একজন DevOps/ক্লাউড ইঞ্জিনিয়ার। আমি HackerNoon এবং Aptible এর প্রতিযোগিতায় অংশগ্রহণ করার সিদ্ধান্ত নিয়েছি।
এই নিবন্ধে, আমি DevSecOps পাইপলাইনের বৈশিষ্ট্য এবং বাম শিফটের ধারণা সম্পর্কে কথা বলব। আপনি DevSecOps পাইপলাইনের প্রধান পর্যায়, সফ্টওয়্যার বিকাশে স্বয়ংক্রিয় নিরাপত্তা পরীক্ষা এবং বিনামূল্যে এবং ওপেন-সোর্স টুল সম্পর্কে শিখবেন। আপনি আগে দুর্বলতা সনাক্ত করতে এবং অ্যাপ্লিকেশন নিরাপত্তা উন্নত করতে সাহায্য করার জন্য টিপসও পাবেন।
এই নিবন্ধটি আপনাকে আপনার DevSecOps পাইপলাইনের পরিপক্কতা মূল্যায়ন করতে, এর বিকাশের জন্য একটি রোডম্যাপ তৈরি করতে, প্রতিটি কাজের জন্য সঠিক সরঞ্জামগুলি বেছে নিতে এবং DevSecOps দর্শন অনুসরণ করে কীভাবে প্রকল্পগুলি পরিচালনা করতে হয় তা আরও ভালভাবে বুঝতে সাহায্য করবে৷
DevSecOps পদ্ধতির প্রধান লক্ষ্য হল DevOps পাইপলাইনগুলিতে, অর্থাৎ, সফ্টওয়্যার বিকাশ প্রক্রিয়ার মধ্যেই স্বয়ংক্রিয় নিরাপত্তা পরীক্ষা প্রবর্তন করা।
এতদিন আগে, তথ্য নিরাপত্তা বিশেষজ্ঞরা উন্নয়ন প্রক্রিয়া সম্পন্ন করার পর পরীক্ষা পরিচালনা করেছিলেন। এই পদ্ধতিটি অকার্যকর - যদি নিরাপত্তা পরীক্ষার সময় ত্রুটিগুলি আবিষ্কৃত হয়, পুরো উন্নয়ন চক্রটি পুনরায় চালু করতে হবে। এটি সময়সাপেক্ষ এবং ব্যয়বহুল।
নিচের ছবিটি দেখে নিন। আপনি দেখতে পাচ্ছেন যে প্রতিটি ধাপে ত্রুটি সংশোধনের খরচ বৃদ্ধি পায়।
ডেভেলপমেন্ট এবং কার্যকরী পরীক্ষার সময় আবিষ্কৃত নিরাপত্তা সমস্যাগুলি ঠিক করতে প্রায় কিছুই খরচ হয় না। সমস্ত প্রয়োজনীয় পরিবর্তনগুলি অবিলম্বে সোর্স কোডে করা যেতে পারে এবং পুনরায় পরীক্ষা করার জন্য পাঠানো যেতে পারে।
আর্টিফ্যাক্ট নির্মাণ পর্যায়ে সমস্যা সমাধান করা অন্তত দ্বিগুণ ব্যয়বহুল। আপনাকে বিল্ড প্রক্রিয়াতে পরিবর্তন করতে হবে, উদাহরণস্বরূপ, ডকারফাইল সম্পাদনা করুন, যার অর্থ আপনার DevOps প্রকৌশলীদের সাহায্যের প্রয়োজন হবে।
যদি ইন্টিগ্রেশন পরীক্ষার সময় একটি ত্রুটি সনাক্ত করা হয়, এটি ঠিক করা 10 গুণ বেশি ব্যয়বহুল হবে। এই ক্ষেত্রে, আপনাকে অবশ্যই বিকাশ চক্র পুনরায় চালু করতে হবে এবং বিকাশকারী, DevOps প্রকৌশলী এবং পরীক্ষকদের জড়িত করতে হবে।
স্থাপনা পর্যায়ে সনাক্ত করা নিরাপত্তা সমস্যা ব্যবহারকারীর ডেটা লিক হতে পারে। কোম্পানী মিলিয়ন মিলিয়ন ডলার জরিমানা পেতে পারে এবং এর খ্যাতির ক্ষতি করতে পারে, যার মানে ভুলের খরচ শতগুণ বেড়ে যায়।
অতএব, প্রধান উপসংহার হল যে যত তাড়াতাড়ি সম্ভব নিরাপত্তা পরীক্ষা করা উচিত। আপনি যদি এটি কল্পনা করেন, তাহলে সেগুলিকে পাইপলাইনের বাম দিকে নিয়ে যান। এটি শিফট বাম ধারণা, যা নিরাপত্তা বিশেষজ্ঞরা এত কথা বলতে পছন্দ করেন।
DevSecOps পাইপলাইনগুলি প্রক্রিয়া এবং সরঞ্জামগুলির একটি স্বয়ংক্রিয় চেইন যা উত্পাদন পরিবেশে অ্যাপ্লিকেশনগুলি তৈরি, পরীক্ষা এবং সরবরাহ করে এবং প্রতিটি পর্যায়ে সেগুলিকে সুরক্ষিত করে।
উপরের ছবিটি নিরাপত্তা চেকের সমস্ত প্রধান পর্যায় সহ DevSecOps পাইপলাইন কাঠামো দেখায়। এখানে তাদের প্রতিটি সম্পর্কে কয়েকটি শব্দ রয়েছে:
এর পরে, আসুন এই চেকগুলি কী এবং সেগুলি সম্পাদন করার জন্য কী সরঞ্জামগুলি ব্যবহার করা হয় তা ঘনিষ্ঠভাবে দেখে নেওয়া যাক।
প্রি-কমিট চেক আপনাকে রিপোজিটরির স্থানীয় কপিতে পরিবর্তন করার আগে ডেভেলপারের মেশিনে সোর্স কোড বিশ্লেষণ করার অনুমতি দেয়। যদি কোনো বিবৃতি একটি ত্রুটি প্রদান করে, কমিট সঞ্চালিত হয় না. এই ক্ষেত্রে, বিকাশকারীকে অবশ্যই ভুলটি সংশোধন করতে হবে এবং আবার কমিট করতে হবে।
এই চেকটি পরিস্থিতি এড়ায় যখন অচেক করা কোড, উদাহরণস্বরূপ, এনক্রিপ্ট করা গোপনীয়তা সহ, সংগ্রহস্থলে প্রবেশ করে।
প্রি-কমিট সোর্স কোড চেক করার জন্য, ডেভেলপারদের স্থানীয় মেশিনে টুল ইনস্টল করা প্রয়োজন। এই পদ্ধতির কেবল সুবিধাই নয়, অসুবিধাও রয়েছে। উদাহরণস্বরূপ, পরিবেশগত পার্থক্য: যন্ত্রের বিভিন্ন সংস্করণ, বিভিন্ন অপারেটিং সিস্টেম এবং এমনকি প্রসেসর আর্কিটেকচার।
ডেভেলপাররা যদি প্রি-কমিট টুলের বিভিন্ন সংস্করণ ব্যবহার করে, তাহলে পরীক্ষা করার ফলাফল ভিন্ন হবে এবং এটি একসাথে কাজ করা চ্যালেঞ্জিং করে তুলতে পারে। একটি দলের মধ্যে বা কোম্পানি জুড়ে প্রি-কমিট চেক বাস্তবায়ন করার সময় এটি বিবেচনা করুন।
প্রি-কমিট চেক সেট আপ করতে অনেক ওপেন সোর্স টুল ব্যবহার করা যেতে পারে:
এগুলি প্রি-কমিট চেকের জন্য দুর্দান্ত সরঞ্জাম।
প্রাক-নির্মাণ পর্যায়ে, হোয়াইট বক্স পরীক্ষা করা হয়। এই চেকগুলি আগের ধাপের মতো সোর্স কোড বিশ্লেষণ করতে ব্যবহৃত হয়। এই ক্ষেত্রে, অ্যাপ্লিকেশনটি একটি "সাদা বাক্স" কারণ আমরা এর স্থাপত্য এবং অভ্যন্তরীণ কাঠামো জানি এবং বুঝতে পারি।
প্রি-বিল্ড চেক বিভিন্ন ধরনের আছে:
এখন, তাদের বিস্তারিত আলোচনা করা যাক.
সিক্রেট ডিটেকশন হল একটি স্বয়ংক্রিয় চেক যা এনক্রিপ্ট না করা সংবেদনশীল তথ্য শনাক্ত করে: সোর্স কোডে এনক্রিপ্ট করা গোপনীয়তা যা একটি সংস্করণ নিয়ন্ত্রণ ব্যবস্থায় প্রবেশ করেছে।
ভার্সন কন্ট্রোল সিস্টেমের রিপোজিটরিতে সোর্স কোড প্রবেশ করার পর প্রি-বিল্ড চেক করা হয়। অতএব, স্টোরেজের সমস্ত এনক্রিপ্ট না করা সংবেদনশীল ডেটা আক্রমণকারীদের দ্বারা সম্ভাব্যভাবে অ্যাক্সেস করা যেতে পারে, উদাহরণস্বরূপ, যদি সংগ্রহস্থলের বিষয়বস্তু ফাঁস হয়।
উপরন্তু, গোপন-সনাক্তকরণ চেক বাস্তবায়নের প্রক্রিয়া স্ক্র্যাচ থেকে নয় কিন্তু একটি বিকশিত প্রকল্পে ঘটতে পারে। এই ক্ষেত্রে, পুরানো কমিট এবং বিভিন্ন সংগ্রহস্থল শাখায় এনক্রিপ্ট করা গোপনীয়তাগুলি পাওয়া যেতে পারে।
এই সমস্যাগুলি সমাধান করার জন্য, আমাদের বিভিন্ন জিনিস করতে হবে। উদাহরণস্বরূপ, আমাদের অবশ্যই এনক্রিপ্ট না করা গোপন তথ্যের সংগ্রহস্থলগুলি পরিষ্কার করতে হবে বা হ্যাশিকর্প ভল্টের মতো বিভিন্ন গোপন ব্যবস্থাপনার সরঞ্জামগুলি প্রয়োগ করতে হবে।
সিক্রেট ডিটেকশন ব্যবহার করে কনফিগার করা যায়
স্ট্যাটিক অ্যাপ্লিকেশান সিকিউরিটি টেস্টিং (SAST) হল একটি পরীক্ষা যখন বিশ্লেষকরা শুধুমাত্র সিনট্যাটিক সঠিকতা পরীক্ষা করে না বরং অনন্য মেট্রিক্সের সাহায্যে কোডের গুণমানও পরিমাপ করে। SAST স্ক্যানারগুলির প্রধান কাজ হল নিরাপত্তা পরীক্ষা।
বিশেষ করে, SAST-বিশ্লেষক সাধারণ দুর্বলতার জন্য সোর্স কোড ধারণ করে, উদাহরণস্বরূপ, কিছু
SAST বিশ্লেষণকে হোয়াইট বক্স টেস্টিং বলা হয় কারণ বিশ্লেষক অ্যাপ্লিকেশনটির অভ্যন্তরীণ কাঠামো অ্যাক্সেস করতে পারে। এটি লক্ষ্য করা গুরুত্বপূর্ণ যে বিশ্লেষকরা এটি না চালিয়ে সোর্স কোডটি পরীক্ষা করে, তাই তারা মিথ্যা ইতিবাচক উৎপন্ন করতে পারে এবং কিছু দুর্বলতা সনাক্ত করতে ব্যর্থ হতে পারে।
এই কারণে, আপনি শুধুমাত্র SAST বিশ্লেষণে নিজেকে সীমাবদ্ধ করবেন না। সমস্যাটির বিস্তৃতভাবে যোগাযোগ করা এবং বিভিন্ন ধরণের বিশ্লেষণ ব্যবহার করা ভাল: SCA, DAST, IAST এবং OAST।
মালিকানা সমাধান:
বিনামূল্যের সমাধান হল GitLab SAST।
সফ্টওয়্যার কম্পোজিশন অ্যানালাইসিস (SCA) একটি পদ্ধতি যা তাদের ওপেন সোর্স উপাদান বিশ্লেষণ করে অ্যাপ্লিকেশনগুলিকে সুরক্ষিত করে।
SCA স্ক্যানারগুলি পুরানো নির্ভরতাগুলির সন্ধান করে যাতে পরিচিত দুর্বলতা এবং শোষণ থাকে। উপরন্তু, কিছু SCA সরঞ্জাম উপাদানগুলির লাইসেন্সের সামঞ্জস্যতা এবং লাইসেন্স লঙ্ঘনের ঝুঁকি নির্ধারণ করতে পারে।
সোর্স SCA সোর্স কোড বিশ্লেষণ করে এবং আরও নির্দিষ্টভাবে, সোর্স কোডে সংজ্ঞায়িত অ্যাপ্লিকেশন নির্ভরতা। এই বিশ্লেষণটিকে প্রায়শই নির্ভরতা স্ক্যানিং হিসাবে উল্লেখ করা হয়।
SCA আপনাকে এমন একটি সমস্যা সনাক্ত করতে দেয় যেখানে একটি উপাদানের একটি দুর্বলতা সমস্ত অ্যাপ্লিকেশনে নিরাপত্তা সমস্যা সৃষ্টি করতে পারে।
একটি ভাল উদাহরণ
বিনামূল্যে মূল্য পরিকল্পনা সহ বাণিজ্যিক সমাধান:
গিটল্যাবের অংশ হিসাবে (কেবলমাত্র আলটিমেট-সংস্করণে উপলব্ধ), আপনি ব্যবহার করতে পারেন
CI পাইপলাইনে সোর্স কোড থেকে আর্টিফ্যাক্ট তৈরি করার পরে নির্মাণ-পরবর্তী পর্বটি আসে: একটি ডকার ইমেজ, একটি RPM প্যাকেজ, বা একটি JAR আর্কাইভ। পোস্ট-বিল্ড চেকের মাধ্যমে, আপনি এই বাইনারি শিল্পকর্মের নির্ভরতা বিশ্লেষণ করতে পারেন।
বাইনারি SCA বিশ্লেষণে ডকার ইমেজ, RPM প্যাকেজ এবং JAR/WAR/EAR আর্কাইভের মতো বাইনারি আর্টিফ্যাক্টগুলি পরিদর্শন করা জড়িত। এটি প্রায়শই কন্টেইনার স্ক্যানিং হিসাবেও উল্লেখ করা হয়। যখন বাইনারি আর্টিফ্যাক্টগুলি তৈরি করা হয়, অর্থাৎ, নির্মাণ-পরবর্তী পর্যায়ের আগে নয় তখন এটি চালানোর অর্থ বোঝায়।
ডকার চিত্রগুলির সাথে কাজ করার সময় কিছু উত্তেজনাপূর্ণ বৈশিষ্ট্য রয়েছে। বাইনারি এসসিএ বিশ্লেষকরা ডকার ইমেজগুলির স্তরগুলি পরীক্ষা করে এবং সেগুলিকে সর্বজনীন দুর্বলতার ডেটাবেসে হ্যাশ সমষ্টি হিসাবে সন্ধান করে যেমন
কিছু বিশ্লেষক শুধুমাত্র দুর্বল উপাদানগুলি খুঁজে পেতে পারে না বরং একটি সমাধানের পরামর্শও দেয়, উদাহরণস্বরূপ, ইতিমধ্যেই নির্দিষ্ট দুর্বলতা সহ একটি উপাদানের ন্যূনতম প্রয়োজনীয় সংস্করণ নির্দিষ্ট করে৷
বিনামূল্যে সমাধান হয়
ওপেন সোর্স সমাধান:
বিল্ট-ইন বিশ্লেষক সহ ডকার রেজিস্ট্রি -
এই পর্যায়ে, গতিশীল গ্রে বক্স টেস্টিং এবং ব্ল্যাক বক্স পরীক্ষা করা হয়। যখন অ্যাপ্লিকেশনটির অভ্যন্তরীণ কাঠামো আংশিক বা সম্পূর্ণ অজানা থাকে, তখন এই নিরাপত্তা পরীক্ষাগুলি আক্রমণকারীর ক্রিয়াগুলি অনুকরণ করে সঞ্চালিত হয় যে দুর্বলতাগুলি খুঁজে পায় এবং তাদের শোষণ করে অ্যাপ্লিকেশনটিকে "ব্রেক" করার চেষ্টা করে৷ আসুন সংক্ষিপ্তভাবে তাদের প্রতিটি নিয়ে আলোচনা করা যাক: DAST, IAST এবং OAST।
DAST স্ক্যানারগুলি বিভিন্ন দুর্বলতার মাধ্যমে বহিরাগত আক্রমণ অনুকরণ করে স্বয়ংক্রিয়ভাবে অ্যাপ্লিকেশন পরীক্ষা করে। অ্যাপ্লিকেশনটি বিশ্লেষকের জন্য একটি কালো বাক্স; এটা সম্পর্কে কিছুই জানা যায় না।
DAST চেকের জন্য, স্ক্যানারের জন্য উপলব্ধ অ্যাপ্লিকেশনটির একটি চলমান উদাহরণ থাকা প্রয়োজন। অধিকন্তু, অ্যাপ্লিকেশনটির পরীক্ষার উদাহরণের পরামিতিগুলি উত্পাদন ইনস্টলেশনের যত কাছাকাছি হবে, তত কম মিথ্যা ইতিবাচক হবে৷
উদাহরণস্বরূপ, ধরুন আপনি শুধুমাত্র HTTP প্রোটোকলের মাধ্যমে অ্যাক্সেসযোগ্য একটি পরীক্ষা অ্যাপ্লিকেশন উদাহরণ স্থাপন করেছেন, কিন্তু উৎপাদনে, অ্যাপ্লিকেশনটি শুধুমাত্র HTTP প্রোটোকলের মাধ্যমে অ্যাক্সেসযোগ্য।
সেই ক্ষেত্রে, DAST স্ক্যানার ক্লায়েন্ট (বিশ্লেষক) এবং সার্ভারের (অ্যাপ্লিকেশন উদাহরণ) মধ্যে ট্রাফিক এনক্রিপশনের অভাব সম্পর্কিত কিছু ত্রুটি তৈরি করবে।
যে সরঞ্জামগুলি আপনার মনোযোগের যোগ্য:
দুর্দান্ত, এগিয়ে যান।
IAST (ইন্টারেক্টিভ অ্যাপ্লিকেশন সিকিউরিটি টেস্টিং) হল একটি গ্রে বক্স টেস্টিং যা হোয়াইট বক্স টেস্টিং SAST এবং ব্ল্যাক বক্স টেস্টিং DAST-এর সুবিধা এবং শক্তিকে একত্রিত করে।
সমস্ত সুবিধা সংগ্রহ করতে এবং SAST এবং DAST পদ্ধতির অসুবিধাগুলি দূর করতে, বিকাশকারীরা IAST আবিষ্কার করেছেন - এই পদ্ধতিগুলিকে একত্রিত করে একটি হাইব্রিড প্রক্রিয়া৷ এটি গতিশীল পরীক্ষার নির্ভুলতা বাড়ায় কারণ এটি কোড বিশ্লেষণের মাধ্যমে অ্যাপ্লিকেশন অপারেশন সম্পর্কে আরও তথ্য দেয়।
এটা মনে রাখা উচিত যে এর সুবিধার পাশাপাশি, IAST-এর সীমাবদ্ধতা রয়েছে। সবচেয়ে মৌলিক হল পরীক্ষার অধীনে আবেদনটি যে ভাষায় লেখা হয় তার উপর নির্ভরতা। IAST সমাধানগুলি অ্যাপ্লিকেশন স্তরে কাজ করে এবং এর আচরণ বিশ্লেষণ করার জন্য এক্সিকিউটেবল কোডে অ্যাক্সেসের প্রয়োজন।
এর মানে হল যে IAST সমাধানগুলিকে অবশ্যই প্রোগ্রামিং ভাষা বুঝতে সক্ষম হতে হবে যেখানে অ্যাপ্লিকেশনটি লেখা হয়েছে। এটি লক্ষ করা উচিত যে একটি নির্দিষ্ট IAST সমাধানের জন্য সমর্থন অন্যদের তুলনায় কিছু ভাষার জন্য আরও ভালভাবে প্রয়োগ করা যেতে পারে।
IAST বিশ্লেষণেও অনেক সময় লাগে। এটি অনেক কারণের উপর নির্ভর করে, যেমন অ্যাপ্লিকেশনের আকার এবং জটিলতা, বাহ্যিক নির্ভরতার সংখ্যা এবং ব্যবহৃত IAST টুলের কর্মক্ষমতা।
এছাড়াও, বিশ্লেষণ প্রক্রিয়াটি নিজেই কোডটি স্ক্যান করে না তবে কেবলমাত্র সেই অংশগুলি পরীক্ষা করে যা সরাসরি কার্যকর করা হয়। অতএব, IAST বিশ্লেষণটি কার্যকরী পরীক্ষার সাথে সর্বোত্তমভাবে মিলিত হয় যখন আপনি যতটা সম্ভব অ্যাপ্লিকেশন পরিস্থিতি পরীক্ষা করতে পারেন।
এখানে আপনার জন্য দুর্দান্ত সরঞ্জাম রয়েছে:
দুর্দান্ত, এগিয়ে যান।
OAST (আউট-অফ-ব্যান্ড অ্যাপ্লিকেশন সিকিউরিটি টেস্টিং) একটি কৌশল যা তৈরি করেছে
আমি আপনাকে সুপারিশ করছি:
চলো এগোই.
এটি অ্যাপ্লিকেশন নিরাপত্তা এবং অপারেবিলিটি নিশ্চিত করার একটি অপরিহার্য পর্যায়। প্রি-কমিট চেকগুলির বিপরীতে, যা উন্নয়ন পর্যায়ে সম্পাদিত হয়, পোস্ট-ডিপ্লোয় চেকগুলি আপনাকে প্রাকৃতিক পরিবেশে অ্যাপ্লিকেশন অপারেশন চলাকালীন ইতিমধ্যে সম্ভাব্য সমস্যাগুলি সনাক্ত করতে দেয়।
সময়মতো নতুন দুর্বলতা সনাক্ত করার জন্য, একটি অ্যাপ্লিকেশন মোতায়েন করার পরে সহ নিয়মিত আর্টিফ্যাক্ট পরীক্ষা করা প্রয়োজন।
এটি বিশেষ সংগ্রহস্থল বা সরঞ্জাম ব্যবহার করে করা যেতে পারে, যেমন
নিরাপত্তা নিশ্চিত করার আরেকটি উপায় হল অ্যাপ্লিকেশন নিজেই নিরীক্ষণ করা। এই উদ্দেশ্যে উপলব্ধ বিভিন্ন প্রযুক্তি আছে:
WAF এর উপর RASP এর প্রধান সুবিধা হল যে এটি অ্যাপ্লিকেশনটি কীভাবে কাজ করে তা বুঝতে পারে এবং আক্রমণ এবং অবৈধ ট্র্যাফিক সনাক্ত করে। RASP শুধুমাত্র স্বাক্ষর ম্যাচিং ব্যবহার করে সাধারণ আক্রমণই দেখতে পারে না বরং অসামঞ্জস্যের প্রতি প্রতিক্রিয়া করে শূন্য-দিনের দুর্বলতাগুলিকে কাজে লাগানোর চেষ্টা করে।
WAF এর বিপরীতে, RASP অ্যাপ্লিকেশনের মধ্যে এবং সাথে কাজ করে। WAF বোকা হতে পারে. যদি একজন আক্রমণকারী অ্যাপ্লিকেশন কোড পরিবর্তন করে, WAF এটি সনাক্ত করতে পারে না কারণ এটি মৃত্যুদন্ডের প্রসঙ্গ বুঝতে পারে না।
RASP অ্যাপ্লিকেশন সম্পর্কে ডায়াগনস্টিক তথ্য অ্যাক্সেস করতে পারে, এটি বিশ্লেষণ করতে পারে, অসঙ্গতি সনাক্ত করতে পারে এবং আক্রমণগুলিকে ব্লক করতে পারে।
RASP প্রযুক্তির একটি বিশেষত্ব রয়েছে যা পূর্বনির্ধারিতভাবে আক্রমণ প্রতিরোধে ফোকাস করে। সিস্টেমের সোর্স কোড অ্যাক্সেসের প্রয়োজন নেই।
আমি আপনাকে সুপারিশ করছি:
দুর্দান্ত, এগিয়ে যান।
পাইপলাইনের বিভিন্ন পর্যায়ে, আমি অনেক অ্যাপ্লিকেশন নিরাপত্তা পরীক্ষা/DevSecOps বিশ্লেষক ব্যবহার করি। তাদের প্রত্যেকটি তার নিজস্ব বিন্যাসে একটি প্রতিবেদন তৈরি করে, এবং তাদের মধ্যে কিছু তথাকথিত মিথ্যা ইতিবাচক উৎপন্ন করে। এই কারণে, সামগ্রিকভাবে একটি অ্যাপ্লিকেশনের নিরাপত্তা বিশ্লেষণ করা সহজ নয়।
দুর্বলতাগুলিকে কার্যকরভাবে বিশ্লেষণ করতে এবং প্রতিকার প্রক্রিয়া পরিচালনা করতে, বিশেষ দুর্বলতা ব্যবস্থাপনার সরঞ্জামগুলিকে প্রায়শই সিকিউরিটি ড্যাশবোর্ড হিসাবে উল্লেখ করা হয়।
নিরাপত্তা ড্যাশবোর্ডগুলি একীভূত এবং সহজে-বিশ্লেষণ ফর্মে DevSecOps বিশ্লেষণের ফলাফল প্রদান করে সমস্যার সমাধান করে। এইভাবে, নিরাপত্তা প্রকৌশলীরা দেখতে পারেন কোন সমস্যাগুলি বিদ্যমান, কোনটি সবচেয়ে জটিল এবং কোনটি প্রথমে সমাধান করা দরকার।
বিস্তৃত সরঞ্জামগুলি সাধারণত নিরাপত্তা ড্যাশবোর্ড হিসাবে ব্যবহৃত হয়: উদাহরণস্বরূপ, ক্লাসিক SOAR/SIEM সিস্টেম এবং সোর্ডফিশ সিকিউরিটি থেকে বিশেষায়িত DevSecOps অর্কেস্ট্রেটর AppSec.Hub বা ওপেন-সোর্স দুর্বলতা ব্যবস্থাপনা টুলকিট DefectDojo।
DefectDojo একটি ব্যাপক টুল। এমনকি এন্টারপ্রাইজ কোম্পানিতেও এটি ব্যাপকভাবে ব্যবহৃত হয়। যাইহোক, এর জনপ্রিয়তা এবং দৃঢ় বয়স সত্ত্বেও, এই টুলের মাঝে মাঝে কিছু প্রাথমিক-স্তরের ত্রুটি থাকে যখন অবদানকারীরা প্রতিশ্রুতিতে মৌলিক কার্যকারিতা ভঙ্গ করে।
যাইহোক, কি চমৎকার যে DefectDojo বিকাশকারী এবং রক্ষণাবেক্ষণকারীরা জটিলতাগুলি সমাধান করতে সাহায্য করে। DefectDojo বিকাশকারীরা খুব প্রতিক্রিয়াশীল মানুষ - আমরা তাদের সাথে সরাসরি যোগাযোগ করার পরামর্শ দিই GitHub-এর ইস্যুগুলির মাধ্যমে।
আবার, নিবন্ধে যা ছিল তার একটি দ্রুত সংক্ষিপ্ত বিবরণ এখানে।
আমি ব্যাখ্যা করেছি যে Shift Left ধারণাটি কী এবং এটি কীভাবে বাগ ফিক্স এবং ডেভেলপমেন্ট টাইম খরচ কমাতে সাহায্য করে: ডেভেলপমেন্ট প্রক্রিয়ায় যত আগে আপনি নিরাপত্তা পরীক্ষা শুরু করবেন ততই ভালো।
তারপরে, আমি DevSecOps পাইপলাইন কাঠামোটি বিনির্মাণ করেছি এবং পাইপলাইনের প্রতিটি পর্যায়ে কী সুরক্ষা পরীক্ষা করা হয় তা দেখেছি:
এখন, আপনি বুঝতে পেরেছেন কিভাবে DevSecOps পাইপলাইন কাজ করে। এখন, আপনি আপনার DevSecOps পাইপলাইনগুলির পরিপক্কতা মূল্যায়ন করতে পারেন, এর বিকাশের জন্য একটি রোডম্যাপ তৈরি করতে পারেন এবং প্রতিটি কাজের জন্য সঠিক সরঞ্জামগুলি বেছে নিতে পারেন৷