Secure SDLC — নকশা থেকে release পর্যন্ত নিরাপত্তা

১ · নিরাপত্তা কেন শেষে জোড়া দেওয়া যায় না

একটি পাঁচতলা কারখানা ভবনের কথা ভাবুন। নকশায় জরুরি সিঁড়ি ছিল না। ভবন শেষ হওয়ার পর পরিদর্শক বললেন, এখন সিঁড়ি লাগবে। কী হবে? দেয়াল ভাঙতে হবে, মেশিন সরাতে হবে, হয়তো ভবনের বাইরে লোহার সিঁড়ি ঝুলিয়ে কাজ চালাতে হবে। অথচ নকশার টেবিলে সিঁড়ির জায়গা রাখতে লাগত এক বেলা।

Software-এও তাই। SDLC মানে Software Development Life Cycle, অর্থাৎ একটি software-এর ধারণা থেকে অবসর পর্যন্ত পুরো জীবনপথ। আর Secure SDLC মানে সেই পথের প্রতিটি ধাপে নিরাপত্তার কাজ যুক্ত রাখা। এটি কোনো নতুন process নয়। আপনার দল Agile, Kanban বা অন্য যে পদ্ধতিতেই চলুক, সেই ধাপগুলোর ভেতরেই কাজগুলো বসে।

আগের পর্বগুলোতে দেখেছেন OWASP Top 10-এ insecure design নামে একটি আলাদা শ্রেণি আছে। নকশাতেই নিয়ন্ত্রণ না থাকলে নিখুঁত কোড দিয়েও সেই ফাঁক বন্ধ হয় না। শেষে pentest করে ধরা পড়লেও সমাধান তখন ওই লোহার সিঁড়ির মতো।

দেরির খরচ: সংখ্যাটি সৎভাবে বলা

একটি হিসাব দেখুন। ধরুন একটি অনলাইন বাজারে যে কেউ অন্যের order-এর refund চাইতে পারছেন (broken access control). ঘণ্টাগুলো আমাদের ধরে নেওয়া, কোনো গবেষণার ফল নয়।

এখানে অনুপাত ২৭ : ১. কিন্তু log-এর একটি ভুল বানান release-এর পরে ধরা পড়লেও হয়তো ১০ মিনিটেই সারে। অর্থাৎ খরচ ঠিক করে ভুলটির ধরন: নকশা কতটা বদলাতে হবে, আর ক্ষতি ইতিমধ্যে ঘটেছে কি না। শুধু ক্যালেন্ডার নয়।

২ · ছয়টি ধাপ, প্রতিটিতে একটি কাজ আর একটি প্রমাণ

পদ্ধতি যাই হোক, প্রায় সব software ছয়টি ধাপ পার হয়। Agile দলে এই ছয় ধাপ দুই সপ্তাহেই একবার ঘুরে আসে, এমনকি একটি ছোট feature-এও। নিচের ছবিটি মনে রাখুন। শেষের তীরটিই সবচেয়ে গুরুত্বপূর্ণ: operate থেকে শেখা জিনিস আবার requirement-এ ফেরে।

“প্রমাণ” কলামটি ইচ্ছা করে রাখা। কাজ হয়েছে বলার চেয়ে দেখাতে পারা ভালো: ছয় মাস পরে কেউ জিজ্ঞেস করলে একটি লিংক খুললেই উত্তর মিলবে। প্রমাণ মানে মোটা নথি নয়। একটি ticket-এর দুই লাইনও প্রমাণ।

নিচে একটি কাল্পনিক অনলাইন বাজারের একটি feature, “গ্রাহক refund চাইবেন”, পুরো পথ পার হচ্ছে। “খোলা ঝুঁকি” সারিটি খেয়াল করুন।

৩ · Requirement — abuse case আর পরীক্ষাযোগ্য শর্ত

ব্যাংকে নতুন চেক বই চালু করার আগে কর্মকর্তা শুধু ভাবেন না “গ্রাহক কীভাবে চেক লিখবেন”, ভাবেন “কেউ জাল সই করলে কী হবে”। Requirement-এর সাধারণ ভাষা বলে সিস্টেম কী করবে। Abuse case বলে কী করতে দেবে না। এটি ডেভেলপারের কাজের নকশা নয়, ক্ষতির পরিস্থিতির একটি লিখিত বর্ণনা, যাতে আগেভাগে বাধা বসানো যায়।

প্রতিটি নতুন feature-এ চারটি প্রশ্নই যথেষ্ট: (১) এখানে কার ডেটা বা টাকা আছে? (২) অন্য একজন ব্যবহারকারী এটি করলে কী হবে? (৩) একই কাজ হাজারবার হলে কী হবে? (৪) ভেতরের কর্মী ভুল করলে বা অসৎ হলে কী হবে? এই আলোচনা user story লেখার সময়েই হয়, আলাদা সভা লাগে না।

এরপর আসে security requirement. শুধু “সিস্টেম নিরাপদ হবে” কোনো requirement নয়, কারণ পরীক্ষা করা যায় না। প্রতিটি শর্তকে এমন হতে হবে, যাতে কেউ পাস বা ফেল বলতে পারেন। এই শর্তকে বলে acceptance criteria. তৈরি তালিকা চাইলে OWASP-এর ASVS ভালো শুরু, তবে পুরোটা নয়, নিজের ঝুঁকির সাথে মেলে এমন অংশ নিন।

নিচের খেলনা কোড tag দেওয়া requirement থেকে পরীক্ষার ধারণা বানায়। এটি কোনো সিস্টেম স্পর্শ করে না, শুধু লেখা তৈরি করে। Tag-এর catalogue দলের নিজের অভিজ্ঞতা থেকে বড় হয়।

// Toy generator: turns tagged requirements into abuse cases and test ideas.
const requirements = [
  { id: 'R1', text: 'Customer views own order', tags: ['owner-data'] },
  { id: 'R2', text: 'Customer requests a refund', tags: ['owner-data', 'money'] },
  { id: 'R3', text: 'Guest asks for a login OTP', tags: ['public-cost'] },
  { id: 'R4', text: 'Seller uploads a product file', tags: ['file'] },
  { id: 'R5', text: 'Support exports customer list', tags: [] },
];
const catalogue = {
  'owner-data': ['user A asks for a record of user B', 'server returns 403; nothing leaks'],
  'money': ['same refund is sent twice', 'second request changes no balance'],
  'public-cost': ['one number asks many times', 'limit hits; request 6 gets 429'],
  'file': ['file type differs from its name', 'server rejects it and logs the event'],
};
let total = 0;
const needHuman = [];
for (const r of requirements) {
  console.log(`${r.id} ${r.text}`);
  if (r.tags.length === 0) needHuman.push(r.id);
  for (const tag of r.tags) {
    const [abuse, expected] = catalogue[tag];
    total++;
    console.log(`  T${total} [${tag}]`);
    console.log(`     Given/When: ${abuse}`);
    console.log(`     Then: ${expected}`);
  }
}
console.log('--');
console.log(`requirements=${requirements.length} tests=${total}`);
console.log(`no tag, human review needed: ${needHuman.join(', ') || 'none'}`);

R1 Customer views own order
  T1 [owner-data]
     Given/When: user A asks for a record of user B
     Then: server returns 403; nothing leaks
R2 Customer requests a refund
  T2 [owner-data]
     Given/When: user A asks for a record of user B
     Then: server returns 403; nothing leaks
  T3 [money]
     Given/When: same refund is sent twice
     Then: second request changes no balance
R3 Guest asks for a login OTP
  T4 [public-cost]
     Given/When: one number asks many times
     Then: limit hits; request 6 gets 429
R4 Seller uploads a product file
  T5 [file]
     Given/When: file type differs from its name
     Then: server rejects it and logs the event
R5 Support exports customer list
--
requirements=5 tests=5
no tag, human review needed: R5

৪ · Shift left, কিন্তু বোঝা না বাড়িয়ে

Shift left মানে নিরাপত্তার কাজ পথের শুরুর দিকে সরানো। পরিকল্পনার ছবিতে কাজটি বাঁ দিকে যায়, তাই এই নাম। উদ্দেশ্য ভালো। কিন্তু খারাপভাবে করলে এর মানে দাঁড়ায়: ডেভেলপারের ঘাড়ে শত শত alert আর ৫০ লাইনের checklist চাপিয়ে দেওয়া। তখন মানুষ পথ এড়িয়ে যান। সমস্যাটি অলসতা নয়, নকশার।

ঢাকায় রাস্তা পার হওয়ার কথা ভাবুন। ওভারব্রিজ যদি দূরে আর ভাঙা হয়, “রাস্তা পার হবেন না” সাইনবোর্ডে কেউ থামেন না। ব্রিজটি ঠিক জায়গায় আর সহজ হলে মানুষ নিজেই ওপরে ওঠেন। নিরাপদ পথ যদি সবচেয়ে সহজ পথ হয়, নিয়ম মনে করিয়ে দিতে হয় না। এটিই পুরো অংশের মূল কথা, আর এটি পর্ব ৩-এর psychological acceptability নীতিরই বাস্তব রূপ।

Design ধাপে সব feature-এর threat model লাগে না। একটি সহজ trigger রাখুন: টাকা, ব্যক্তিগত ডেটা, login বা অনুমতি, নতুন বাইরের integration, অথবা নতুন public endpoint ছুঁলে ৩০ মিনিটের threat model. বাকি ছোট কাজ সরাসরি যায়। Review-তে দুই স্তর কাজ করে: সাধারণ PR-এ সহকর্মী, আর auth/ বা payment/ ফোল্ডার ছুঁলে champion-কে বাধ্যতামূলক reviewer করে দেওয়া।

৫ · Security gate — blocking না advisory

মেট্রো স্টেশনের গেট দুই রকম আচরণ করে। টিকিট না থাকলে দরজা খোলে না। আর ব্যাগে সন্দেহজনক কিছু দেখলে কর্মী দেখে ছেড়ে দেন। Software-এর security gate-ও তাই। Pipeline-এর কোনো ধাপের পরীক্ষার ফল দেখে সে সিদ্ধান্ত দেয়: এগোবে কি না।

Pipeline-এর কলকবজা, কোন ধাপে কোন tool, token আর pinning নিয়ে এখানে কথা বলব না। সেসব আছে DevSecOps পর্বে আর Continuous Integration পর্বে। আমরা দেখব নীতি: কোন জিনিসে থামাবেন, কে ছাড় দেবেন।

একটি ভালো নীতির চারটি অংশ: নতুন জিনিসে থামান, পুরোনো ঋণে নয়, যাতে আজকের PR-এর লেখক গত বছরের দায় না নেন। পৌঁছানো যায় এমন জিনিসে থামান। সমাধানের পথ থাকতে হবে। আর সিদ্ধান্তটি policy as code হিসেবে repository-তে থাকবে, যাতে নীতিও review হয়। ছাড় সম্ভব, কিন্তু গোপন বা স্থায়ী নয়। নিচের খেলনা evaluator তাই করে। Build-এর ফল পাতার ভেতরের object, কিছুই scan হচ্ছে না, আর তারিখ simulated.

// Toy security gate on in-memory build results. Nothing is scanned.
const exceptions = [
  { id: 'EX-7', finding: 'F5', expires: '2026-11-30', owner: 'CTO' },
];
const heavy = ['critical', 'high'];
function decide(f, today) {
  if (f.kind === 'secret') return ['BLOCK', 'secret: no exception allowed'];
  if (!heavy.includes(f.sev)) return ['ADVISE', 'below blocking severity'];
  if (!f.isNew) return ['ADVISE', 'old debt: tracked on the board'];
  if (!f.reachable) return ['ADVISE', 'not reachable: review later'];
  const ex = exceptions.find(e => e.finding === f.id);
  if (ex && today <= ex.expires) return ['PASS*', `${ex.id} until ${ex.expires}`];
  if (ex) return ['BLOCK', `${ex.id} expired on ${ex.expires}`];
  return ['BLOCK', 'new, reachable, serious'];
}
const builds = [
  { id: 101, today: '2026-11-02', findings: [
    { id: 'F1', kind: 'sast', sev: 'high', isNew: true, reachable: true },
    { id: 'F2', kind: 'sca', sev: 'medium', isNew: true, reachable: true },
    { id: 'F3', kind: 'secret', sev: 'high', isNew: true, reachable: true } ] },
  { id: 102, today: '2026-11-03', findings: [
    { id: 'F2', kind: 'sca', sev: 'medium', isNew: true, reachable: true },
    { id: 'F4', kind: 'sca', sev: 'critical', isNew: false, reachable: true } ] },
  { id: 103, today: '2026-11-20', findings: [
    { id: 'F5', kind: 'sca', sev: 'high', isNew: true, reachable: true } ] },
  { id: 104, today: '2026-12-01', findings: [
    { id: 'F5', kind: 'sca', sev: 'high', isNew: true, reachable: true } ] },
];
for (const b of builds) {
  const rows = b.findings.map(f => [f.id, ...decide(f, b.today)]);
  const failed = rows.some(r => r[1] === 'BLOCK');
  console.log(`build ${b.id} (${b.today}): ${failed ? 'FAILED' : 'PASSED'}`);
  rows.forEach(r => console.log(`  ${r[0]} ${r[1].padEnd(6)} ${r[2]}`));
}

build 101 (2026-11-02): FAILED
  F1 BLOCK  new, reachable, serious
  F2 ADVISE below blocking severity
  F3 BLOCK  secret: no exception allowed
build 102 (2026-11-03): PASSED
  F2 ADVISE below blocking severity
  F4 ADVISE old debt: tracked on the board
build 103 (2026-11-20): PASSED
  F5 PASS*  EX-7 until 2026-11-30
build 104 (2026-12-01): FAILED
  F5 BLOCK  EX-7 expired on 2026-11-30

এবার দেখুন gate ব্যর্থ হলে একজন ডেভেলপারের দিনটি কেমন যায়। এটি ওপরের build 101 থেকে build 102-তে যাওয়ার গল্প।

FAILED
F1 BLOCK  sast   high   query built by joining strings
F2 ADVISE sca    medium library update available
F3 BLOCK  secret high   key pattern in config file

F1  real: input reaches the query    -> fix now
F2  real: small update               -> ticket, 30 days
F3  real: test key, but a live one   -> treat as leaked

// before: text is joined into the query
// sql = "... WHERE id = " + <user-input>
// after: the value travels separately
// sql = "... WHERE id = ?", params = [orderId]
+ regression test for the same input path

1. revoke the old key        done
2. issue a new key           done
3. store it in the vault     done
4. check access logs         no unknown use
5. remove from config        done

PASSED
F2 ADVISE below blocking severity
F4 ADVISE old debt: tracked on the board

TICKET-212  F2 update library    due 30 days
TICKET-213  pre-commit secret check for all repos
NOTE        F1 pattern added to review notes

৬ · Release আর operate — ঝুঁকি বুঝে সিদ্ধান্ত

Release-এ এসে প্রশ্নটি “ত্রুটি আছে কি” নয়। ত্রুটি প্রায় সবসময় থাকে। প্রশ্ন হলো “জানা ঝুঁকিগুলো নিয়ে আমরা কি এখন যেতে রাজি, আর সেই সিদ্ধান্ত কার?” Sign-off মানে একজন দায়িত্বশীল মানুষের নাম ওই সিদ্ধান্তের পাশে থাকা। ডেভেলপার নিজে ঝুঁকি গ্রহণ করেন না। ব্যবসার সেই অংশের মালিক, অর্থাৎ risk owner, করেন, কারণ ক্ষতি হলে তাঁকেই জবাব দিতে হবে।

কাজের একটি হিসাব দেখুন। সংখ্যাগুলো ধরে নেওয়া। একটি high finding আছে, library-র fix এখনো নেই। Release ৩০ দিন পেছালে ব্যবসার ক্ষতি ৳৩,০০,০০০. ঘটনা ঘটলে ক্ষতি ৳৫০,০০,০০০. ঘটার সম্ভাবনা মাসে ২%, আর WAF rule আর feature সীমা (compensating control) দিলে ০.৫%.

এই হিসাবে নিয়ন্ত্রণসহ release করাই যৌক্তিক: ৳২৫,০০০ বনাম ৳৩,০০,০০০. আর সমান হওয়ার বিন্দুটি আসল কথা বলে। আসল মাসিক সম্ভাবনা ৬%-এর বেশি হলে সিদ্ধান্ত উল্টে যায়। কিন্তু সতর্ক থাকুন: সম্ভাবনার অনুমান প্রায়ই আন্দাজ (risk-এর সূত্র নিয়ে মতভেদও আছে, দেখুন পর্ব ২)। Exploit প্রকাশ্য হলে, যেমন ত্রুটিটি KEV তালিকায় এলে, সংখ্যাটি রাতারাতি বদলায়। আর কিছু জিনিস টাকায় মাপা যায় না: মানুষের ব্যক্তিগত ডেটা, নিরাপত্তা-সংকটাপন্ন কাজ, আইনি দায়। সেখানে মানুষের বিচারই শেষ কথা।

এই সিদ্ধান্তের লিখিত রূপই risk exception. এতে পাঁচটি জিনিস থাকতে হবে: কোন finding, কেন এখন ঠিক করা যাচ্ছে না, কোন সুরক্ষা বসানো হলো, কে অনুমোদন করলেন, আর কবে মেয়াদ শেষ। মেয়াদ নেই এমন ছাড় আসলে ছাড় নয়, নীরবে নেওয়া risk acceptance. সব ছাড় একটি risk register-এ থাকে। নিচে EX-7-এর পুরো জীবন দেখুন, যা ওপরের কোডের সেই ছাড়।

Release-এর ছোট checklist

• সব blocking gate পাস, চালু ছাড়ের তালিকা দেখা হয়েছে
• SBOM তৈরি ও রাখা হয়েছে, যাতে পরে জানা যায় কোন version-এ কী ছিল (পর্ব ৪৮)
• Migration আর rollback-এর পথ পরীক্ষিত, secret পাল্টানোর দরকার নেই
• নতুন feature-এর log আর alert চালু, দায়িত্বে কে আছেন তা জানা
• ঝুঁকিপূর্ণ পরিবর্তন হলে ধাপে ধাপে খোলা হবে, পুরো গ্রাহকের জন্য একসাথে নয়

Operate: কাজ এখানে শেষ হয় না

চালু হওয়ার পরের তিনটি অভ্যাস। Monitoring: login ব্যর্থতা, refund-এর হার, অনুমতির 403 বেড়ে যাওয়া, এগুলো নিরাপত্তার সংকেত। Patch: dependency আর server-এর জন্য পর্ব ৩২-এর অগ্রাধিকার। CVSS-এর সাথে KEV আর EPSS মিলিয়ে দেখুন। Disclosure: বাইরের কেউ ত্রুটি পেলে কোথায় জানাবেন, তা পর্ব ৬-এর coordinated disclosure মেনে ঠিক রাখুন। Site-এ একটি security.txt (RFC 9116, ২০২২) রাখা সবচেয়ে সস্তা শুরু। দরকার হলে গ্রাহকদের জন্য security advisory প্রকাশ করুন। আর ঘটনা ঘটলে incident management-এর পথ ধরুন, যার পূর্ণ আলোচনা পর্ব ৬১-এ।

৭ · Finding, triage আর security debt

Tool চালালেই শত শত finding আসে। এগুলো হাসপাতালের জরুরি বিভাগের রোগীর মতো। যিনি আগে এলেন তিনি আগে নন, যাঁর অবস্থা গুরুতর তিনি আগে। এই বাছাইকে বলে finding triage. প্রতিটি finding-এর জন্য চারটি প্রশ্ন: এটি সত্যি কি? পৌঁছানো যায় কি? ক্ষতি কতটা? কে সারাবেন, কবে?

ফল হতে পারে পাঁচটি: এখনই সারানো, সময়সীমা দিয়ে ticket, false positive (কারণসহ বন্ধ, যাতে rule ঠিক করা যায়), প্রযোজ্য নয়, অথবা মেয়াদসহ ছাড়। কোনো finding মালিকহীন থাকবে না, এটিই একমাত্র কঠোর নিয়ম। Microsoft-এর SDL-এ এমন স্থির মানকে বলা হয় bug bar: কোন শ্রেণির ত্রুটি নিয়ে release হবে না, তা আগেই ঠিক থাকে, যাতে চাপের সময় তর্ক না হয়।

না সারানো finding জমে হয় security debt. এটি technical debt-এর মতো ঋণ, পার্থক্য হলো এর সুদ হঠাৎ একদিনে চাইতে পারে। বাকিতে চা খাওয়ার খাতা ভাবুন। দোকানদার প্রতিদিন চান না, কিন্তু খাতাটি না দেখলে একদিন অঙ্ক দেখে চমকে যাবেন। নিচের খেলনা কোড seed করা PRNG দিয়ে ৬০টি কাল্পনিক finding বানায়, আর ১৮০ দিনের simulated হিসাব দেখায়। SLA আর পয়েন্ট দলের ধরে নেওয়া নীতি, কোনো standard নয়।

// Toy finding ageing with a seeded PRNG and a simulated calendar (day numbers).
function mulberry32(a) {
  return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
}
const rand = mulberry32(45);
const SLA = { critical: 7, high: 30, medium: 90 };   // assumed team policy, in days
const WEIGHT = { critical: 10, high: 3, medium: 1 }; // assumed debt points
const sevs = ['critical', 'high', 'high', 'medium', 'medium', 'medium'];
const findings = [];
for (let i = 0; i < 60; i++) {
  const sev = sevs[Math.floor(rand() * sevs.length)];
  const opened = 1 + Math.floor(rand() * 180);
  const fixDays = Math.floor(rand() * 2.2 * SLA[sev]);
  findings.push({ sev, opened, closed: rand() < 0.2 ? null : opened + fixDays });
}
console.log('day  opened  closed  open  overdue  debt  oldest');
for (const day of [30, 60, 90, 120, 150, 180]) {
  const seen = findings.filter(f => f.opened <= day);
  const open = seen.filter(f => f.closed === null || f.closed > day);
  const overdue = open.filter(f => day - f.opened > SLA[f.sev]);
  const debt = overdue.reduce((sum, f) => sum + WEIGHT[f.sev], 0);
  const oldest = Math.max(0, ...open.map(f => day - f.opened));
  console.log([day, seen.length, seen.length - open.length, open.length, overdue.length, debt, oldest]
    .map(v => String(v).padEnd(6)).join(' ').trimEnd());
}
const done = findings.filter(f => f.closed !== null && f.closed <= 180);
const within = done.filter(f => f.closed - f.opened <= SLA[f.sev]).length;
const median = xs => { const s = [...xs].sort((a, b) => a - b); return s[Math.floor(s.length / 2)]; };
console.log(`closed in time: ${within}/${done.length} = ${(100 * within / done.length).toFixed(1)}%`);
for (const sev of Object.keys(SLA)) {
  const days = done.filter(f => f.sev === sev).map(f => f.closed - f.opened);
  console.log(`median days to fix ${sev}: ${median(days)} (n=${days.length}, SLA ${SLA[sev]})`);
}

day  opened  closed  open  overdue  debt  oldest
30     8      2      6      2      20     28
60     17     6      11     2      20     58
90     26     12     14     5      36     88
120    38     14     24     8      39     118
150    51     25     26     9      44     148
180    60     33     27     12     47     178
closed in time: 21/33 = 63.6%
median days to fix critical: 7 (n=9, SLA 7)
median days to fix high: 28 (n=16, SLA 30)
median days to fix medium: 42 (n=8, SLA 90)

কোন metric কাজের

৮ · Framework — SSDF, SDL, SAMM আর BSIMM

চারটি নাম প্রায়ই একসাথে শুনবেন। এগুলো প্রতিযোগী নয়, চারটি আলাদা প্রশ্নের উত্তর। রান্নার সাথে তুলনা করলে: একটি হলো “কোন কোন জিনিস থাকতেই হবে” তালিকা, একটি অভিজ্ঞ বাবুর্চির রেসিপি, একটি নিজের রান্নাঘরের মূল্যায়নপত্র, আর একটি বড় রেস্তোরাঁগুলো আসলে কী করে তার জরিপ।

মূল পার্থক্যটি মনে রাখুন: SAMM বলে কী করা ভালো (prescriptive), BSIMM দেখায় অন্যরা কী করছেন (descriptive). অন্যরা করছেন বলেই সেটি আপনার জন্য ঠিক, তা নয়। আর এগুলোর কোনোটিই নিজে থেকে software নিরাপদ করে না। এটিও মনে রাখুন, NIST-এর এই নথি বাংলাদেশের কোনো আইন নয়। মার্কিন সরকারি ক্রয়ের প্রেক্ষিতে এর গুরুত্ব বেড়েছিল। আপনার ক্লায়েন্ট চাইলে তবেই এটি চুক্তির বিষয়।

নিচের কোডটি SAMM-এর ১৫টি practice-এর ওপর একটি কাল্পনিক ৫ জনের দলের স্ব-মূল্যায়ন। মানগুলো ধরে নেওয়া। আসল SAMM toolkit প্রতিটি practice-এর প্রশ্ন ধরে নম্বর দেয়, এখানে সহজ করে প্রতিটিকে ০ থেকে ৩ দেওয়া হয়েছে।

// SAMM-style self-assessment. Answers (0 to 3) are assumed for a toy 5-person team.
// Simplified: the real SAMM toolkit scores individual questions.
const answers = {
  Governance: { 'Strategy & Metrics': 0, 'Policy & Compliance': 1, 'Education & Guidance': 1 },
  Design: { 'Threat Assessment': 1, 'Security Requirements': 0, 'Secure Architecture': 1 },
  Implementation: { 'Secure Build': 2, 'Secure Deployment': 1, 'Defect Management': 1 },
  Verification: { 'Architecture Assessment': 0, 'Requirements-driven Testing': 1, 'Security Testing': 1 },
  Operations: { 'Incident Management': 1, 'Environment Management': 2, 'Operational Management': 1 },
};
const target = { 'Security Requirements': 1, 'Defect Management': 2, 'Incident Management': 2,
                 'Strategy & Metrics': 1, 'Threat Assessment': 2 };
const gaps = [];
let all = 0, count = 0;
for (const [fn, practices] of Object.entries(answers)) {
  const scores = Object.values(practices);
  const avg = scores.reduce((a, b) => a + b, 0) / scores.length;
  all += scores.reduce((a, b) => a + b, 0); count += scores.length;
  console.log(fn.padEnd(15) + avg.toFixed(2) + '  ' + '#'.repeat(Math.round(avg * 4)));
  for (const [name, score] of Object.entries(practices))
    if (target[name] !== undefined && target[name] > score)
      gaps.push({ name, score, want: target[name] });
}
console.log('overall        ' + (all / count).toFixed(2) + ' of 3');
console.log('next quarter (gap first, then lowest score):');
gaps.sort((a, b) => (b.want - b.score) - (a.want - a.score) || a.score - b.score);
gaps.forEach((g, i) => console.log(`  ${i + 1}. ${g.name}: ${g.score} -> ${g.want}`));

Governance     0.67  ###
Design         0.67  ###
Implementation 1.33  #####
Verification   0.67  ###
Operations     1.33  #####
overall        0.93 of 3
next quarter (gap first, then lowest score):
  1. Strategy & Metrics: 0 -> 1
  2. Security Requirements: 0 -> 1
  3. Threat Assessment: 1 -> 2
  4. Defect Management: 1 -> 2
  5. Incident Management: 1 -> 2

৯ · ৫ জন ডেভেলপারের দলের ৯০ দিনের পরিকল্পনা

ধরুন ঢাকার একটি software দল। ৫ জন ডেভেলপার, কোনো আলাদা নিরাপত্তা কর্মী নেই। কাজ চলে কয়েকটি ক্লায়েন্টের web app আর একটি নিজস্ব পণ্য নিয়ে, hosting কখনো cPanel, কখনো VPS. ডলারের খরচ সীমিত। সপ্তাহে কাজ ৫ × ৪০ = ২০০ ঘণ্টা। ধরে নিই এর ৫% নিরাপত্তায় দেওয়া হবে: সপ্তাহে ১০ ঘণ্টা। এটি কোনো মান নয়, শুরু করার মতো একটি বাজেট। মূল কৌশল: আগে এমন জিনিস, যা একবার করলে স্থায়ী হয়।

বাংলাদেশের প্রেক্ষিতে যা আলাদা করে ভাবতে হয়

• Payment আর mobile wallet: Gateway-র callback server-এ যাচাই করুন, browser থেকে আসা “payment সফল” কথায় বিশ্বাস করবেন না। এটি প্রথম abuse case হওয়ার যোগ্য।
• SMS OTP-র খরচ: OTP-র প্রতিটি অনুরোধে টাকা যায়। সীমা না থাকলে অপব্যবহার সরাসরি বিলে দেখা দেয় (পর্ব ৪৩)।
• Client handover: Project দেওয়ার পরে patch কে করবেন, চুক্তিতে লিখুন। অনেক সাইট দেওয়ার পরে আর কেউ ছোঁন না, আর সেখানেই পুরোনো plugin জমে (পর্ব ৪৪)।
• লোক বদল: ছোট দলে একজন গেলেই জ্ঞান যায়। Account, secret আর সিদ্ধান্ত লিখে রাখুন, আর কেউ ছাড়লে সেদিনই access বন্ধ করুন।
• বিনামূল্যের পথ: Open source scanner আর code host-এর বিনা খরচের সুবিধা দিয়ে অনেকটা হয়। Tool-এর নাম বদলাতে পারে, নীতি নয়। Tool কেনার আগে দেখুন কে তার ফল পড়বেন।
• ব্যক্তিগত ডেটা আর আইন: Requirement ধাপেই জিজ্ঞেস করুন কোন ব্যক্তিগত ডেটা সত্যি দরকার। দেশের উপাত্ত সুরক্ষা ও সাইবার আইনের সারকথা পর্ব ৬-এ আর পর্ব ৭০-এ। ব্যাংক বা আর্থিক খাতের ক্লায়েন্টের নিজস্ব নিয়ন্ত্রকের নির্দেশনা থাকতে পারে, সরাসরি মিলিয়ে নিন। এটি আইনি পরামর্শ নয়।
• পরীক্ষার অনুমতি: ক্লায়েন্টের সিস্টেমে scan বা pentest শুধু লিখিত অনুমতিতে (পর্ব ৫০)। নিজের দলের staging পরিবেশ ব্যবহার করুন।

১০ · AI-এর যুগে Secure SDLC

AI এখন SDLC-র প্রায় সব ধাপে: requirement লেখা, কোড, পরীক্ষা, এমনকি review. একটি সহজ নীতি মনে রাখুন: AI-এর কোড একজন দ্রুত কিন্তু অপরিচিত ঠিকাদারের কোড। Gate একই, review একই, আর merge যিনি করলেন, দায়ও তাঁর। এই বিষয়ে একটি পরিচিত গবেষণা Perry ও সহলেখকদের (ACM CCS, ২০২৩): ৪৭ জন অংশগ্রহণকারীর পরীক্ষায় AI সহকারী পাওয়া দল বেশি অনিরাপদ কোড লিখলেন, আর নিজেদের কোডকে বেশি নিরাপদ ভাবলেন। নমুনা ছোট, আর সহকারীটি ছিল পুরোনো প্রজন্মের, তাই ফলটি আজকের সব tool-এ হুবহু খাটবে, এমন বলা যায় না। তবে আত্মবিশ্বাস বেড়ে যাওয়ার ঝুঁকিটি মনে রাখার মতো।

AI ব্যবহারের চেকলিস্ট

• AI-এর লেখা কোড একই PR, একই review, একই gate পার হয়েছে
• Login, অনুমতি, টাকা বা ব্যক্তিগত ডেটার কোড একজন মানুষ লাইন ধরে পড়েছেন
• নতুন package-টি সত্যি আছে, চেনা, আর lockfile-এ দেখা হয়েছে
• Prompt-এ কোনো secret, গ্রাহকের ডেটা বা ক্লায়েন্টের গোপন কোড যায়নি
• Error সারাতে কোনো নিরাপত্তা-পরীক্ষা বন্ধ করা হয়নি
• AI-এর বলা CVE, standard আর সংখ্যা মূল উৎসে মিলিয়েছি
• Merge-এর দায় একজন মানুষের নামে, AI agent-এর অনুমতি সীমিত

নিজে AI মডেল বানালে NIST-এর SP 800-218A (জুলাই ২০২৪) দেখুন, যা generative AI-এর জন্য SSDF-এর একটি প্রোফাইল। শুধু ব্যবহারকারী হলে ওপরের চেকলিস্টই আপাতত যথেষ্ট।