paint-brush
কীভাবে একটি DevOps পাইপলাইনকে একটি DevSecOps পাইপলাইনে পরিণত করবেন: একটি শিফট বাম ধারণা ওভারভিউদ্বারা@goal23
11,212 পড়া
11,212 পড়া

কীভাবে একটি DevOps পাইপলাইনকে একটি DevSecOps পাইপলাইনে পরিণত করবেন: একটি শিফট বাম ধারণা ওভারভিউ

দ্বারা Sofia Konobievska12m2023/09/08
Read on Terminal Reader
Read this story w/o Javascript

অতিদীর্ঘ; পড়তে

আমি ব্যাখ্যা করেছি শিফট বাম ধারণাটি কী এবং এটি কীভাবে বাগ ফিক্স এবং ডেভেলপমেন্ট টাইম খরচ কমাতে সাহায্য করে: ডেভেলপমেন্ট প্রক্রিয়ায় যত আগে আপনি নিরাপত্তা পরীক্ষা শুরু করবেন তত ভালো। তারপরে, আমি DevSecOps পাইপলাইন কাঠামোটি বিনির্মাণ করেছি এবং পাইপলাইনের প্রতিটি পর্যায়ে কী সুরক্ষা পরীক্ষা করা হয় তা দেখেছি।
featured image - কীভাবে একটি DevOps পাইপলাইনকে একটি DevSecOps পাইপলাইনে পরিণত করবেন: একটি শিফট বাম ধারণা ওভারভিউ
Sofia Konobievska HackerNoon profile picture

হাই, হ্যাকারনুন! আমার নাম সোফিয়া, এবং আমি একজন DevOps/ক্লাউড ইঞ্জিনিয়ার। আমি HackerNoon এবং Aptible এর প্রতিযোগিতায় অংশগ্রহণ করার সিদ্ধান্ত নিয়েছি।


এই নিবন্ধে, আমি DevSecOps পাইপলাইনের বৈশিষ্ট্য এবং বাম শিফটের ধারণা সম্পর্কে কথা বলব। আপনি DevSecOps পাইপলাইনের প্রধান পর্যায়, সফ্টওয়্যার বিকাশে স্বয়ংক্রিয় নিরাপত্তা পরীক্ষা এবং বিনামূল্যে এবং ওপেন-সোর্স টুল সম্পর্কে শিখবেন। আপনি আগে দুর্বলতা সনাক্ত করতে এবং অ্যাপ্লিকেশন নিরাপত্তা উন্নত করতে সাহায্য করার জন্য টিপসও পাবেন।


এই নিবন্ধটি আপনাকে আপনার DevSecOps পাইপলাইনের পরিপক্কতা মূল্যায়ন করতে, এর বিকাশের জন্য একটি রোডম্যাপ তৈরি করতে, প্রতিটি কাজের জন্য সঠিক সরঞ্জামগুলি বেছে নিতে এবং DevSecOps দর্শন অনুসরণ করে কীভাবে প্রকল্পগুলি পরিচালনা করতে হয় তা আরও ভালভাবে বুঝতে সাহায্য করবে৷

বাম ধারণা পরিবর্তন করুন

DevSecOps পদ্ধতির প্রধান লক্ষ্য হল DevOps পাইপলাইনগুলিতে, অর্থাৎ, সফ্টওয়্যার বিকাশ প্রক্রিয়ার মধ্যেই স্বয়ংক্রিয় নিরাপত্তা পরীক্ষা প্রবর্তন করা।


এতদিন আগে, তথ্য নিরাপত্তা বিশেষজ্ঞরা উন্নয়ন প্রক্রিয়া সম্পন্ন করার পর পরীক্ষা পরিচালনা করেছিলেন। এই পদ্ধতিটি অকার্যকর - যদি নিরাপত্তা পরীক্ষার সময় ত্রুটিগুলি আবিষ্কৃত হয়, পুরো উন্নয়ন চক্রটি পুনরায় চালু করতে হবে। এটি সময়সাপেক্ষ এবং ব্যয়বহুল।


নিচের ছবিটি দেখে নিন। আপনি দেখতে পাচ্ছেন যে প্রতিটি ধাপে ত্রুটি সংশোধনের খরচ বৃদ্ধি পায়।



ডেভেলপমেন্ট এবং কার্যকরী পরীক্ষার সময় আবিষ্কৃত নিরাপত্তা সমস্যাগুলি ঠিক করতে প্রায় কিছুই খরচ হয় না। সমস্ত প্রয়োজনীয় পরিবর্তনগুলি অবিলম্বে সোর্স কোডে করা যেতে পারে এবং পুনরায় পরীক্ষা করার জন্য পাঠানো যেতে পারে।


আর্টিফ্যাক্ট নির্মাণ পর্যায়ে সমস্যা সমাধান করা অন্তত দ্বিগুণ ব্যয়বহুল। আপনাকে বিল্ড প্রক্রিয়াতে পরিবর্তন করতে হবে, উদাহরণস্বরূপ, ডকারফাইল সম্পাদনা করুন, যার অর্থ আপনার DevOps প্রকৌশলীদের সাহায্যের প্রয়োজন হবে।


যদি ইন্টিগ্রেশন পরীক্ষার সময় একটি ত্রুটি সনাক্ত করা হয়, এটি ঠিক করা 10 গুণ বেশি ব্যয়বহুল হবে। এই ক্ষেত্রে, আপনাকে অবশ্যই বিকাশ চক্র পুনরায় চালু করতে হবে এবং বিকাশকারী, DevOps প্রকৌশলী এবং পরীক্ষকদের জড়িত করতে হবে।


স্থাপনা পর্যায়ে সনাক্ত করা নিরাপত্তা সমস্যা ব্যবহারকারীর ডেটা লিক হতে পারে। কোম্পানী মিলিয়ন মিলিয়ন ডলার জরিমানা পেতে পারে এবং এর খ্যাতির ক্ষতি করতে পারে, যার মানে ভুলের খরচ শতগুণ বেড়ে যায়।


অতএব, প্রধান উপসংহার হল যে যত তাড়াতাড়ি সম্ভব নিরাপত্তা পরীক্ষা করা উচিত। আপনি যদি এটি কল্পনা করেন, তাহলে সেগুলিকে পাইপলাইনের বাম দিকে নিয়ে যান। এটি শিফট বাম ধারণা, যা নিরাপত্তা বিশেষজ্ঞরা এত কথা বলতে পছন্দ করেন।


DevSecOps পাইপলাইন কাঠামো

DevSecOps পাইপলাইনগুলি প্রক্রিয়া এবং সরঞ্জামগুলির একটি স্বয়ংক্রিয় চেইন যা উত্পাদন পরিবেশে অ্যাপ্লিকেশনগুলি তৈরি, পরীক্ষা এবং সরবরাহ করে এবং প্রতিটি পর্যায়ে সেগুলিকে সুরক্ষিত করে।



উপরের ছবিটি নিরাপত্তা চেকের সমস্ত প্রধান পর্যায় সহ DevSecOps পাইপলাইন কাঠামো দেখায়। এখানে তাদের প্রতিটি সম্পর্কে কয়েকটি শব্দ রয়েছে:


  • প্রি-কমিট। এটি বিকাশকারী সংস্করণ নিয়ন্ত্রণ সিস্টেমে কোডটি কমিট করার আগে সোর্স কোডের নিরাপত্তা পরীক্ষা করা বোঝায়। এই চেকটি আপনাকে পাসওয়ার্ড বা API কীগুলির মতো এনক্রিপ্ট করা গোপনীয় তথ্য সনাক্ত করতে দেয়।


  • প্রি-বিল্ড। এটি ভার্সন কন্ট্রোল সিস্টেমে প্রবেশ করার পরে সোর্স কোডের নিরাপত্তা পরীক্ষা করা বোঝায়। সরঞ্জামগুলি সাধারণ দুর্বলতাগুলি সনাক্ত করতে উত্স কোড এবং এর নির্ভরতাগুলির স্ট্যাটিক বিশ্লেষণ করে, যেমন অনেকগুলি OWASP শীর্ষ দশ তালিকা


  • পোস্ট-বিল্ড। এটি একটি ডকার ফাইল, RPM প্যাকেজ বা JAR আর্কাইভের মতো সোর্স কোড থেকে তৈরি একটি আর্টিফ্যাক্টের নিরাপত্তা পরীক্ষা। সরঞ্জামগুলি অ্যাপ্লিকেশন পরিবেশ এবং নির্ভরতা বিশ্লেষণ করে, প্যাকেজ এবং লাইব্রেরিগুলির পুরানো সংস্করণগুলি খুঁজে বের করে যা ইতিমধ্যেই নতুন সংস্করণগুলিতে প্যাচ রয়েছে৷


  • পরীক্ষার সময়। এটি একটি সংগৃহীত শিল্পকর্ম থেকে চলমান একটি অ্যাপ্লিকেশনের নিরাপত্তা পরীক্ষা বোঝায়। এই পর্যায়ের সরঞ্জামগুলি আক্রমণকারীদের ক্রিয়াগুলি অনুকরণ করে অ্যাপ্লিকেশনটিকে "ব্রেক" করার চেষ্টা করে৷


  • পোস্ট-ডিপ্লয়মেন্ট। এটি একটি উত্পাদন পরিবেশে স্থাপন করার পরে একটি অ্যাপ্লিকেশনের নিরাপত্তা পরীক্ষা করা বোঝায়। সরঞ্জামগুলি রিয়েল টাইমে পরিচিত দুর্বলতার খোলা রেজিস্ট্রিগুলি নিরীক্ষণ করে এবং যখন অ্যাপ্লিকেশনটির জন্য হুমকি সনাক্ত করা হয় তখন বিজ্ঞপ্তি দেয়।


এর পরে, আসুন এই চেকগুলি কী এবং সেগুলি সম্পাদন করার জন্য কী সরঞ্জামগুলি ব্যবহার করা হয় তা ঘনিষ্ঠভাবে দেখে নেওয়া যাক।

প্রি-কমিট চেক

প্রি-কমিট চেক আপনাকে রিপোজিটরির স্থানীয় কপিতে পরিবর্তন করার আগে ডেভেলপারের মেশিনে সোর্স কোড বিশ্লেষণ করার অনুমতি দেয়। যদি কোনো বিবৃতি একটি ত্রুটি প্রদান করে, কমিট সঞ্চালিত হয় না. এই ক্ষেত্রে, বিকাশকারীকে অবশ্যই ভুলটি সংশোধন করতে হবে এবং আবার কমিট করতে হবে।


এই চেকটি পরিস্থিতি এড়ায় যখন অচেক করা কোড, উদাহরণস্বরূপ, এনক্রিপ্ট করা গোপনীয়তা সহ, সংগ্রহস্থলে প্রবেশ করে।



প্রি-কমিট সোর্স কোড চেক করার জন্য, ডেভেলপারদের স্থানীয় মেশিনে টুল ইনস্টল করা প্রয়োজন। এই পদ্ধতির কেবল সুবিধাই নয়, অসুবিধাও রয়েছে। উদাহরণস্বরূপ, পরিবেশগত পার্থক্য: যন্ত্রের বিভিন্ন সংস্করণ, বিভিন্ন অপারেটিং সিস্টেম এবং এমনকি প্রসেসর আর্কিটেকচার।


ডেভেলপাররা যদি প্রি-কমিট টুলের বিভিন্ন সংস্করণ ব্যবহার করে, তাহলে পরীক্ষা করার ফলাফল ভিন্ন হবে এবং এটি একসাথে কাজ করা চ্যালেঞ্জিং করে তুলতে পারে। একটি দলের মধ্যে বা কোম্পানি জুড়ে প্রি-কমিট চেক বাস্তবায়ন করার সময় এটি বিবেচনা করুন।

প্রি-কমিট চেকের জন্য টুল

প্রি-কমিট চেক সেট আপ করতে অনেক ওপেন সোর্স টুল ব্যবহার করা যেতে পারে:


  1. গিটলেক্স
  2. গিট-সিক্রেটস
  3. ট্রিভি সিক্রেট স্ক্যানিং
  4. ফিসফিস করে
  5. git-সব-সিক্রেটস
  6. ডিটেক্ট-সিক্রেটস
  7. gitty ফুটো


এগুলি প্রি-কমিট চেকের জন্য দুর্দান্ত সরঞ্জাম।

প্রি-বিল্ড চেক

প্রাক-নির্মাণ পর্যায়ে, হোয়াইট বক্স পরীক্ষা করা হয়। এই চেকগুলি আগের ধাপের মতো সোর্স কোড বিশ্লেষণ করতে ব্যবহৃত হয়। এই ক্ষেত্রে, অ্যাপ্লিকেশনটি একটি "সাদা বাক্স" কারণ আমরা এর স্থাপত্য এবং অভ্যন্তরীণ কাঠামো জানি এবং বুঝতে পারি।


প্রি-বিল্ড চেক বিভিন্ন ধরনের আছে:


  • সিক্রেট ডিটেকশন
  • স্ট্যাটিক অ্যাপ্লিকেশন সিকিউরিটি টেস্টিং (SAST)
  • সফ্টওয়্যার রচনা বিশ্লেষণ (SCA)


এখন, তাদের বিস্তারিত আলোচনা করা যাক.

প্রি-বিল্ড সিক্রেট ডিটেকশন চেক

সিক্রেট ডিটেকশন হল একটি স্বয়ংক্রিয় চেক যা এনক্রিপ্ট না করা সংবেদনশীল তথ্য শনাক্ত করে: সোর্স কোডে এনক্রিপ্ট করা গোপনীয়তা যা একটি সংস্করণ নিয়ন্ত্রণ ব্যবস্থায় প্রবেশ করেছে।


ভার্সন কন্ট্রোল সিস্টেমের রিপোজিটরিতে সোর্স কোড প্রবেশ করার পর প্রি-বিল্ড চেক করা হয়। অতএব, স্টোরেজের সমস্ত এনক্রিপ্ট না করা সংবেদনশীল ডেটা আক্রমণকারীদের দ্বারা সম্ভাব্যভাবে অ্যাক্সেস করা যেতে পারে, উদাহরণস্বরূপ, যদি সংগ্রহস্থলের বিষয়বস্তু ফাঁস হয়।


উপরন্তু, গোপন-সনাক্তকরণ চেক বাস্তবায়নের প্রক্রিয়া স্ক্র্যাচ থেকে নয় কিন্তু একটি বিকশিত প্রকল্পে ঘটতে পারে। এই ক্ষেত্রে, পুরানো কমিট এবং বিভিন্ন সংগ্রহস্থল শাখায় এনক্রিপ্ট করা গোপনীয়তাগুলি পাওয়া যেতে পারে।


এই সমস্যাগুলি সমাধান করার জন্য, আমাদের বিভিন্ন জিনিস করতে হবে। উদাহরণস্বরূপ, আমাদের অবশ্যই এনক্রিপ্ট না করা গোপন তথ্যের সংগ্রহস্থলগুলি পরিষ্কার করতে হবে বা হ্যাশিকর্প ভল্টের মতো বিভিন্ন গোপন ব্যবস্থাপনার সরঞ্জামগুলি প্রয়োগ করতে হবে।

গোপন সনাক্তকরণের জন্য সরঞ্জাম

সিক্রেট ডিটেকশন ব্যবহার করে কনফিগার করা যায় গিটলেক্স , গিট-সিক্রেটস , বা ডিটেক্ট-সিক্রেটস . যাইহোক, সুপরিচিত CI/CD প্ল্যাটফর্ম দ্বারা প্রদত্ত পরিষেবাগুলি ব্যবহার করা ভাল, উদাহরণস্বরূপ, গিটল্যাব সিক্রেট ডিটেকশন .

প্রি-বিল্ড SAST চেক

স্ট্যাটিক অ্যাপ্লিকেশান সিকিউরিটি টেস্টিং (SAST) হল একটি পরীক্ষা যখন বিশ্লেষকরা শুধুমাত্র সিনট্যাটিক সঠিকতা পরীক্ষা করে না বরং অনন্য মেট্রিক্সের সাহায্যে কোডের গুণমানও পরিমাপ করে। SAST স্ক্যানারগুলির প্রধান কাজ হল নিরাপত্তা পরীক্ষা।


বিশেষ করে, SAST-বিশ্লেষক সাধারণ দুর্বলতার জন্য সোর্স কোড ধারণ করে, উদাহরণস্বরূপ, কিছু OWASP শীর্ষ দশ তালিকা এটা বলা অপরিহার্য যে SAST স্ক্যানারগুলি শুধুমাত্র দুর্বলতাকেই খুঁজে পায় না বরং কোডের খণ্ডটিও খুঁজে পায় যা এটি ঘটায়।


SAST বিশ্লেষণকে হোয়াইট বক্স টেস্টিং বলা হয় কারণ বিশ্লেষক অ্যাপ্লিকেশনটির অভ্যন্তরীণ কাঠামো অ্যাক্সেস করতে পারে। এটি লক্ষ্য করা গুরুত্বপূর্ণ যে বিশ্লেষকরা এটি না চালিয়ে সোর্স কোডটি পরীক্ষা করে, তাই তারা মিথ্যা ইতিবাচক উৎপন্ন করতে পারে এবং কিছু দুর্বলতা সনাক্ত করতে ব্যর্থ হতে পারে।


এই কারণে, আপনি শুধুমাত্র SAST বিশ্লেষণে নিজেকে সীমাবদ্ধ করবেন না। সমস্যাটির বিস্তৃতভাবে যোগাযোগ করা এবং বিভিন্ন ধরণের বিশ্লেষণ ব্যবহার করা ভাল: SCA, DAST, IAST এবং OAST।

SAST টুলস

মালিকানা সমাধান:



বিনামূল্যের সমাধান হল GitLab SAST।

প্রাক-বিল্ড সোর্স SCA চেক

সফ্টওয়্যার কম্পোজিশন অ্যানালাইসিস (SCA) একটি পদ্ধতি যা তাদের ওপেন সোর্স উপাদান বিশ্লেষণ করে অ্যাপ্লিকেশনগুলিকে সুরক্ষিত করে।


SCA স্ক্যানারগুলি পুরানো নির্ভরতাগুলির সন্ধান করে যাতে পরিচিত দুর্বলতা এবং শোষণ থাকে। উপরন্তু, কিছু SCA সরঞ্জাম উপাদানগুলির লাইসেন্সের সামঞ্জস্যতা এবং লাইসেন্স লঙ্ঘনের ঝুঁকি নির্ধারণ করতে পারে।


সোর্স SCA সোর্স কোড বিশ্লেষণ করে এবং আরও নির্দিষ্টভাবে, সোর্স কোডে সংজ্ঞায়িত অ্যাপ্লিকেশন নির্ভরতা। এই বিশ্লেষণটিকে প্রায়শই নির্ভরতা স্ক্যানিং হিসাবে উল্লেখ করা হয়।


SCA আপনাকে এমন একটি সমস্যা সনাক্ত করতে দেয় যেখানে একটি উপাদানের একটি দুর্বলতা সমস্ত অ্যাপ্লিকেশনে নিরাপত্তা সমস্যা সৃষ্টি করতে পারে।


একটি ভাল উদাহরণ Log4Shell . এই দুর্বলতাটি 2021 সালের শেষের দিকে Log4j, একটি জনপ্রিয় জাভা লগিং ফ্রেমওয়ার্ক-এ আবিষ্কৃত হয়েছিল। এটি সবচেয়ে ভয়ঙ্কর দুর্বলতাগুলির মধ্যে একটি হয়ে উঠেছে কারণ এটি আক্রমণকারীদের কয়েক মিলিয়ন ডিভাইসে নির্বিচারে জাভা কোড চালানোর অনুমতি দেয়।

SCA টুলস

ট্রিভি একটি ওপেন সোর্স সমাধান।


বিনামূল্যে মূল্য পরিকল্পনা সহ বাণিজ্যিক সমাধান:



গিটল্যাবের অংশ হিসাবে (কেবলমাত্র আলটিমেট-সংস্করণে উপলব্ধ), আপনি ব্যবহার করতে পারেন গিটল্যাব নির্ভরতা স্ক্যানিং .

পোস্ট-বিল্ড চেক: বাইনারি SCA

CI পাইপলাইনে সোর্স কোড থেকে আর্টিফ্যাক্ট তৈরি করার পরে নির্মাণ-পরবর্তী পর্বটি আসে: একটি ডকার ইমেজ, একটি RPM প্যাকেজ, বা একটি JAR আর্কাইভ। পোস্ট-বিল্ড চেকের মাধ্যমে, আপনি এই বাইনারি শিল্পকর্মের নির্ভরতা বিশ্লেষণ করতে পারেন।



বাইনারি SCA বিশ্লেষণে ডকার ইমেজ, RPM প্যাকেজ এবং JAR/WAR/EAR আর্কাইভের মতো বাইনারি আর্টিফ্যাক্টগুলি পরিদর্শন করা জড়িত। এটি প্রায়শই কন্টেইনার স্ক্যানিং হিসাবেও উল্লেখ করা হয়। যখন বাইনারি আর্টিফ্যাক্টগুলি তৈরি করা হয়, অর্থাৎ, নির্মাণ-পরবর্তী পর্যায়ের আগে নয় তখন এটি চালানোর অর্থ বোঝায়।


ডকার চিত্রগুলির সাথে কাজ করার সময় কিছু উত্তেজনাপূর্ণ বৈশিষ্ট্য রয়েছে। বাইনারি এসসিএ বিশ্লেষকরা ডকার ইমেজগুলির স্তরগুলি পরীক্ষা করে এবং সেগুলিকে সর্বজনীন দুর্বলতার ডেটাবেসে হ্যাশ সমষ্টি হিসাবে সন্ধান করে যেমন ন্যাশনাল ভালনারেবিলিটি ডেটাবেস (NVD) বা Snyk দুর্বলতা DB .


কিছু বিশ্লেষক শুধুমাত্র দুর্বল উপাদানগুলি খুঁজে পেতে পারে না বরং একটি সমাধানের পরামর্শও দেয়, উদাহরণস্বরূপ, ইতিমধ্যেই নির্দিষ্ট দুর্বলতা সহ একটি উপাদানের ন্যূনতম প্রয়োজনীয় সংস্করণ নির্দিষ্ট করে৷

জনপ্রিয় বাইনারি SCA বিশ্লেষকদের উদাহরণ

বিনামূল্যে সমাধান হয় গিটল্যাব কন্টেইনার স্ক্যানিং


ওপেন সোর্স সমাধান:



বিল্ট-ইন বিশ্লেষক সহ ডকার রেজিস্ট্রি - হারবার .

টেস্ট-টাইম চেক: DAST, IAST, এবং OAST

এই পর্যায়ে, গতিশীল গ্রে বক্স টেস্টিং এবং ব্ল্যাক বক্স পরীক্ষা করা হয়। যখন অ্যাপ্লিকেশনটির অভ্যন্তরীণ কাঠামো আংশিক বা সম্পূর্ণ অজানা থাকে, তখন এই নিরাপত্তা পরীক্ষাগুলি আক্রমণকারীর ক্রিয়াগুলি অনুকরণ করে সঞ্চালিত হয় যে দুর্বলতাগুলি খুঁজে পায় এবং তাদের শোষণ করে অ্যাপ্লিকেশনটিকে "ব্রেক" করার চেষ্টা করে৷ আসুন সংক্ষিপ্তভাবে তাদের প্রতিটি নিয়ে আলোচনা করা যাক: DAST, IAST এবং OAST।


টেস্ট-টাইম DAST চেক

DAST স্ক্যানারগুলি বিভিন্ন দুর্বলতার মাধ্যমে বহিরাগত আক্রমণ অনুকরণ করে স্বয়ংক্রিয়ভাবে অ্যাপ্লিকেশন পরীক্ষা করে। অ্যাপ্লিকেশনটি বিশ্লেষকের জন্য একটি কালো বাক্স; এটা সম্পর্কে কিছুই জানা যায় না।


DAST চেকের জন্য, স্ক্যানারের জন্য উপলব্ধ অ্যাপ্লিকেশনটির একটি চলমান উদাহরণ থাকা প্রয়োজন। অধিকন্তু, অ্যাপ্লিকেশনটির পরীক্ষার উদাহরণের পরামিতিগুলি উত্পাদন ইনস্টলেশনের যত কাছাকাছি হবে, তত কম মিথ্যা ইতিবাচক হবে৷


উদাহরণস্বরূপ, ধরুন আপনি শুধুমাত্র HTTP প্রোটোকলের মাধ্যমে অ্যাক্সেসযোগ্য একটি পরীক্ষা অ্যাপ্লিকেশন উদাহরণ স্থাপন করেছেন, কিন্তু উৎপাদনে, অ্যাপ্লিকেশনটি শুধুমাত্র HTTP প্রোটোকলের মাধ্যমে অ্যাক্সেসযোগ্য।


সেই ক্ষেত্রে, DAST স্ক্যানার ক্লায়েন্ট (বিশ্লেষক) এবং সার্ভারের (অ্যাপ্লিকেশন উদাহরণ) মধ্যে ট্রাফিক এনক্রিপশনের অভাব সম্পর্কিত কিছু ত্রুটি তৈরি করবে।

DAST টুলের উদাহরণ

যে সরঞ্জামগুলি আপনার মনোযোগের যোগ্য:


  • GitLab DAST — শুধুমাত্র চূড়ান্ত সংস্করণে উপলব্ধ
  • OWASP জেড অ্যাটাক প্রক্সি (ZAP) — একটি ওপেন সোর্স সমাধান, যা গিটল্যাব DAST-এও ব্যবহৃত হয়
  • অ্যাকুনেটিক্স
  • WebInspect কে শক্তিশালী করুন
  • এইচসিএল সিকিউরিটি অ্যাপস্ক্যান
  • Synopsys পরিচালিত DAST
  • Tenable.io (ওয়েব অ্যাপ স্ক্যানিং)
  • ভেরাকোড ডায়নামিক বিশ্লেষণ


দুর্দান্ত, এগিয়ে যান।

পরীক্ষার সময় IAST চেক

IAST (ইন্টারেক্টিভ অ্যাপ্লিকেশন সিকিউরিটি টেস্টিং) হল একটি গ্রে বক্স টেস্টিং যা হোয়াইট বক্স টেস্টিং SAST এবং ব্ল্যাক বক্স টেস্টিং DAST-এর সুবিধা এবং শক্তিকে একত্রিত করে।


সমস্ত সুবিধা সংগ্রহ করতে এবং SAST এবং DAST পদ্ধতির অসুবিধাগুলি দূর করতে, বিকাশকারীরা IAST আবিষ্কার করেছেন - এই পদ্ধতিগুলিকে একত্রিত করে একটি হাইব্রিড প্রক্রিয়া৷ এটি গতিশীল পরীক্ষার নির্ভুলতা বাড়ায় কারণ এটি কোড বিশ্লেষণের মাধ্যমে অ্যাপ্লিকেশন অপারেশন সম্পর্কে আরও তথ্য দেয়।


এটা মনে রাখা উচিত যে এর সুবিধার পাশাপাশি, IAST-এর সীমাবদ্ধতা রয়েছে। সবচেয়ে মৌলিক হল পরীক্ষার অধীনে আবেদনটি যে ভাষায় লেখা হয় তার উপর নির্ভরতা। IAST সমাধানগুলি অ্যাপ্লিকেশন স্তরে কাজ করে এবং এর আচরণ বিশ্লেষণ করার জন্য এক্সিকিউটেবল কোডে অ্যাক্সেসের প্রয়োজন।


এর মানে হল যে IAST সমাধানগুলিকে অবশ্যই প্রোগ্রামিং ভাষা বুঝতে সক্ষম হতে হবে যেখানে অ্যাপ্লিকেশনটি লেখা হয়েছে। এটি লক্ষ করা উচিত যে একটি নির্দিষ্ট IAST সমাধানের জন্য সমর্থন অন্যদের তুলনায় কিছু ভাষার জন্য আরও ভালভাবে প্রয়োগ করা যেতে পারে।


IAST বিশ্লেষণেও অনেক সময় লাগে। এটি অনেক কারণের উপর নির্ভর করে, যেমন অ্যাপ্লিকেশনের আকার এবং জটিলতা, বাহ্যিক নির্ভরতার সংখ্যা এবং ব্যবহৃত IAST টুলের কর্মক্ষমতা।


এছাড়াও, বিশ্লেষণ প্রক্রিয়াটি নিজেই কোডটি স্ক্যান করে না তবে কেবলমাত্র সেই অংশগুলি পরীক্ষা করে যা সরাসরি কার্যকর করা হয়। অতএব, IAST বিশ্লেষণটি কার্যকরী পরীক্ষার সাথে সর্বোত্তমভাবে মিলিত হয় যখন আপনি যতটা সম্ভব অ্যাপ্লিকেশন পরিস্থিতি পরীক্ষা করতে পারেন।

IAST টুলের উদাহরণ

এখানে আপনার জন্য দুর্দান্ত সরঞ্জাম রয়েছে:



দুর্দান্ত, এগিয়ে যান।

টেস্ট-টাইম OAST চেক

OAST (আউট-অফ-ব্যান্ড অ্যাপ্লিকেশন সিকিউরিটি টেস্টিং) একটি কৌশল যা তৈরি করেছে পোর্টসুইগার এবং এটি DAST-এর একটি এক্সটেনশন যা দুর্বলতা খুঁজে পায় যা DAST দেখতে পায় না, যেমন log4shell।

OAST টুলের উদাহরণ

আমি আপনাকে সুপারিশ করছি:



চলো এগোই.

পোস্ট-ডিপ্লোয় চেক


এটি অ্যাপ্লিকেশন নিরাপত্তা এবং অপারেবিলিটি নিশ্চিত করার একটি অপরিহার্য পর্যায়। প্রি-কমিট চেকগুলির বিপরীতে, যা উন্নয়ন পর্যায়ে সম্পাদিত হয়, পোস্ট-ডিপ্লোয় চেকগুলি আপনাকে প্রাকৃতিক পরিবেশে অ্যাপ্লিকেশন অপারেশন চলাকালীন ইতিমধ্যে সম্ভাব্য সমস্যাগুলি সনাক্ত করতে দেয়।

শিল্পকর্মের নিরাপত্তা নিরীক্ষণ

সময়মতো নতুন দুর্বলতা সনাক্ত করার জন্য, একটি অ্যাপ্লিকেশন মোতায়েন করার পরে সহ নিয়মিত আর্টিফ্যাক্ট পরীক্ষা করা প্রয়োজন।


এটি বিশেষ সংগ্রহস্থল বা সরঞ্জাম ব্যবহার করে করা যেতে পারে, যেমন Snyk ধারক , Trivy, GitLab কন্টেইনার স্ক্যানিং, অথবা আপনার ইন্টিগ্রেশন মডিউল ডেভেলপ করা।

অ্যাপ্লিকেশন নিরাপত্তা পর্যবেক্ষণ

নিরাপত্তা নিশ্চিত করার আরেকটি উপায় হল অ্যাপ্লিকেশন নিজেই নিরীক্ষণ করা। এই উদ্দেশ্যে উপলব্ধ বিভিন্ন প্রযুক্তি আছে:


  • ওয়েব অ্যাপ্লিকেশন ফায়ারওয়াল (WAF) একটি ট্রাফিক ফিল্টারিং টুল। এটি অ্যাপ্লিকেশন স্তরে কাজ করে এবং HTTP/HTTPS ট্র্যাফিক বিশ্লেষণ করে ওয়েব অ্যাপ্লিকেশনগুলিকে রক্ষা করে৷


  • RASP (রানটাইম অ্যাপ্লিকেশন সেলফ-প্রোটেকশন) এমন একটি প্রযুক্তি যা রিয়েল টাইমে একটি অ্যাপ্লিকেশনে আক্রমণ সনাক্ত করে এবং ব্লক করে। এটি রানটাইম পরিবেশে একটি প্রতিরক্ষা ফাংশন যোগ করে, অ্যাপ্লিকেশনটিকে স্বয়ংক্রিয়ভাবে স্ব-রক্ষা করার অনুমতি দেয়।


WAF এর উপর RASP এর প্রধান সুবিধা হল যে এটি অ্যাপ্লিকেশনটি কীভাবে কাজ করে তা বুঝতে পারে এবং আক্রমণ এবং অবৈধ ট্র্যাফিক সনাক্ত করে। RASP শুধুমাত্র স্বাক্ষর ম্যাচিং ব্যবহার করে সাধারণ আক্রমণই দেখতে পারে না বরং অসামঞ্জস্যের প্রতি প্রতিক্রিয়া করে শূন্য-দিনের দুর্বলতাগুলিকে কাজে লাগানোর চেষ্টা করে।


WAF এর বিপরীতে, RASP অ্যাপ্লিকেশনের মধ্যে এবং সাথে কাজ করে। WAF বোকা হতে পারে. যদি একজন আক্রমণকারী অ্যাপ্লিকেশন কোড পরিবর্তন করে, WAF এটি সনাক্ত করতে পারে না কারণ এটি মৃত্যুদন্ডের প্রসঙ্গ বুঝতে পারে না।


RASP অ্যাপ্লিকেশন সম্পর্কে ডায়াগনস্টিক তথ্য অ্যাক্সেস করতে পারে, এটি বিশ্লেষণ করতে পারে, অসঙ্গতি সনাক্ত করতে পারে এবং আক্রমণগুলিকে ব্লক করতে পারে।


RASP প্রযুক্তির একটি বিশেষত্ব রয়েছে যা পূর্বনির্ধারিতভাবে আক্রমণ প্রতিরোধে ফোকাস করে। সিস্টেমের সোর্স কোড অ্যাক্সেসের প্রয়োজন নেই।

RASP বোকা

আমি আপনাকে সুপারিশ করছি:



দুর্দান্ত, এগিয়ে যান।

DevSecOps P ipelines ফলাফল এবং দুর্বলতা ব্যবস্থাপনার ভিজ্যুয়ালাইজেশন

পাইপলাইনের বিভিন্ন পর্যায়ে, আমি অনেক অ্যাপ্লিকেশন নিরাপত্তা পরীক্ষা/DevSecOps বিশ্লেষক ব্যবহার করি। তাদের প্রত্যেকটি তার নিজস্ব বিন্যাসে একটি প্রতিবেদন তৈরি করে, এবং তাদের মধ্যে কিছু তথাকথিত মিথ্যা ইতিবাচক উৎপন্ন করে। এই কারণে, সামগ্রিকভাবে একটি অ্যাপ্লিকেশনের নিরাপত্তা বিশ্লেষণ করা সহজ নয়।


দুর্বলতাগুলিকে কার্যকরভাবে বিশ্লেষণ করতে এবং প্রতিকার প্রক্রিয়া পরিচালনা করতে, বিশেষ দুর্বলতা ব্যবস্থাপনার সরঞ্জামগুলিকে প্রায়শই সিকিউরিটি ড্যাশবোর্ড হিসাবে উল্লেখ করা হয়।


নিরাপত্তা ড্যাশবোর্ডগুলি একীভূত এবং সহজে-বিশ্লেষণ ফর্মে DevSecOps বিশ্লেষণের ফলাফল প্রদান করে সমস্যার সমাধান করে। এইভাবে, নিরাপত্তা প্রকৌশলীরা দেখতে পারেন কোন সমস্যাগুলি বিদ্যমান, কোনটি সবচেয়ে জটিল এবং কোনটি প্রথমে সমাধান করা দরকার।


DevSecOps টুলস

বিস্তৃত সরঞ্জামগুলি সাধারণত নিরাপত্তা ড্যাশবোর্ড হিসাবে ব্যবহৃত হয়: উদাহরণস্বরূপ, ক্লাসিক SOAR/SIEM সিস্টেম এবং সোর্ডফিশ সিকিউরিটি থেকে বিশেষায়িত DevSecOps অর্কেস্ট্রেটর AppSec.Hub বা ওপেন-সোর্স দুর্বলতা ব্যবস্থাপনা টুলকিট DefectDojo।


DefectDojo একটি ব্যাপক টুল। এমনকি এন্টারপ্রাইজ কোম্পানিতেও এটি ব্যাপকভাবে ব্যবহৃত হয়। যাইহোক, এর জনপ্রিয়তা এবং দৃঢ় বয়স সত্ত্বেও, এই টুলের মাঝে মাঝে কিছু প্রাথমিক-স্তরের ত্রুটি থাকে যখন অবদানকারীরা প্রতিশ্রুতিতে মৌলিক কার্যকারিতা ভঙ্গ করে।


যাইহোক, কি চমৎকার যে DefectDojo বিকাশকারী এবং রক্ষণাবেক্ষণকারীরা জটিলতাগুলি সমাধান করতে সাহায্য করে। DefectDojo বিকাশকারীরা খুব প্রতিক্রিয়াশীল মানুষ - আমরা তাদের সাথে সরাসরি যোগাযোগ করার পরামর্শ দিই GitHub-এর ইস্যুগুলির মাধ্যমে।

বাম ধারণা পরিবর্তন করুন: আসুন সংক্ষিপ্ত করা যাক

আবার, নিবন্ধে যা ছিল তার একটি দ্রুত সংক্ষিপ্ত বিবরণ এখানে।


আমি ব্যাখ্যা করেছি যে Shift Left ধারণাটি কী এবং এটি কীভাবে বাগ ফিক্স এবং ডেভেলপমেন্ট টাইম খরচ কমাতে সাহায্য করে: ডেভেলপমেন্ট প্রক্রিয়ায় যত আগে আপনি নিরাপত্তা পরীক্ষা শুরু করবেন ততই ভালো।


তারপরে, আমি DevSecOps পাইপলাইন কাঠামোটি বিনির্মাণ করেছি এবং পাইপলাইনের প্রতিটি পর্যায়ে কী সুরক্ষা পরীক্ষা করা হয় তা দেখেছি:


  • প্রি-কমিট। এটি সংস্করণ নিয়ন্ত্রণ সিস্টেমে প্রবেশ করার আগে সোর্স কোডের নিরাপত্তা পরীক্ষা করে বোঝায়।


  • প্রি-বিল্ড। এটি সংস্করণ নিয়ন্ত্রণ ব্যবস্থার (সিক্রেট ডিটেকশন, SAST, SCA) সোর্স কোড নিরাপত্তার একটি চেক।


  • পোস্ট-বিল্ড। এটি সোর্স কোড (সোর্স এসসিএ, বাইনারি এসসিএ) থেকে তৈরি একটি আর্টিফ্যাক্টের নিরাপত্তা পরীক্ষা।


  • পরীক্ষার সময়। এটি সংগৃহীত আর্টিফ্যাক্ট (DAST, IAST, এবং OAST) থেকে চলমান অ্যাপ্লিকেশনটির নিরাপত্তা পরীক্ষা করা বোঝায়।


  • পোস্ট-ডিপ্লোয়। এটি উত্পাদন পরিবেশে (WAF, RASP) স্থাপনের পরে অ্যাপ্লিকেশন সুরক্ষা পরীক্ষা করা বোঝায়।


এখন, আপনি বুঝতে পেরেছেন কিভাবে DevSecOps পাইপলাইন কাজ করে। এখন, আপনি আপনার DevSecOps পাইপলাইনগুলির পরিপক্কতা মূল্যায়ন করতে পারেন, এর বিকাশের জন্য একটি রোডম্যাপ তৈরি করতে পারেন এবং প্রতিটি কাজের জন্য সঠিক সরঞ্জামগুলি বেছে নিতে পারেন৷