নিরাপত্তা পরীক্ষা — SAST, DAST, fuzzing আর code review

১ · পরীক্ষার মানচিত্র — কে কী ধরে, কোথায় বসে

একটি নতুন ভবন হস্তান্তরের আগে কী হয় ভাবুন। প্রকৌশলী নকশা মিলিয়ে দেখেন। মিস্ত্রি পানির লাইনে চাপ দিয়ে দেখেন ফুটো আছে কি না। ফায়ার সার্ভিস আগুনের মহড়া দেয়। কেউ একজন একটি দরজা জোরে টেনে দেখেন তালা টেকে কি না। প্রত্যেকে আলাদা জিনিস ধরেন। কেউ একা সব ধরেন না।

Software-এর নিরাপত্তা পরীক্ষাও ঠিক তাই। SAST নকশা মেলানোর মতো, কোড না চালিয়েই পড়ে। DAST চলন্ত সিস্টেমে বাইরে থেকে চাপ দেয়। Fuzzing অদ্ভুত ইনপুটে প্রোগ্রাম ভাঙে কি না দেখে। Code review-এ অভিজ্ঞ মানুষ দেখেন যুক্তি ঠিক আছে কি না। এই পর্বের স্থির উদাহরণ একটি কাল্পনিক অনলাইন বাজারের নিজের কোড। পরীক্ষার সব ডেটা ও finding মনগড়া, আর পাতার কোনো কোড বাইরে অনুরোধ পাঠায় না।

একটি প্রশ্ন আগেই পরিষ্কার করি। এটি penetration testing নয়। এখানে আপনি নিজের দলের ভেতর থেকে, নিয়মিত, স্বয়ংক্রিয়ভাবে কোড যাচাই করছেন। Scope আর চুক্তি নিয়ে বাইরের চোখে পরীক্ষা আসবে পরের পর্ব ৫০-এ। আর পরীক্ষার পরিকল্পনা শুরু হয় threat model থেকে: কোন সম্পদ, কোন পথ, কোন ক্ষতি। তা না হলে tool যা পারে তাই পরীক্ষা হয়, যা দরকার তা নয়। পুরো secure SDLC-এর ছবি আছে পর্ব ৪৫-এ।

২ · SAST — কোড না চালিয়ে কোড পড়া

পরীক্ষার খাতা দেখার সময় অভিজ্ঞ শিক্ষক উত্তর মিলিয়ে দেখেন, হাতেকলমে কিছু করে দেখেন না। SAST-ও প্রোগ্রাম চালায় না, পড়ে। কিন্তু পড়ার গভীরতার তিনটি স্তর আছে:

নিচের ডায়াগ্রামে একটি ছোট খেলনা ফাংশনে taint ধাপে ধাপে ছড়াচ্ছে। raw এসেছে ব্যবহারকারীর কাছ থেকে। ডান পাশের ঘরে দেখুন, প্রতিটি ভ্যারিয়েবল কোন প্রসঙ্গে এখনো বিপজ্জনক।

1raw  = readParam("id")2q1   = "...id=" + raw3runQuery(q1)4id   = toInt(raw)5q2   = "...id=" + id6runQuery(q2)7name = escapeHtml(raw)8render(name)9q3   = "...name=" + name10runQuery(q3)

এবার একই হিসাব সত্যিকারের কোডে চালিয়ে দেখুন। প্রোগ্রামটি এখানে শুধু object-এর একটি তালিকা। কিছুই চালানো হয় না, কোনো database নেই। এটি খেলনা tracker, আসল SAST অনেক জটিল।

// Toy taint tracker. The "program" is a list of objects; nothing is executed.
const SOURCES = ['readParam'];
const CLEANS = { toInt: ['sql', 'html'], escapeHtml: ['html'] }; // what each cleans
const SINKS = { runQuery: 'sql', render: 'html' };
const prog = [
  { line: 1, to: 'raw', fn: 'readParam', args: [] },
  { line: 2, to: 'q1', fn: 'concat', args: ['raw'] },
  { line: 3, fn: 'runQuery', args: ['q1'] },
  { line: 4, to: 'id', fn: 'toInt', args: ['raw'] },
  { line: 5, to: 'q2', fn: 'concat', args: ['id'] },
  { line: 6, fn: 'runQuery', args: ['q2'] },
  { line: 7, to: 'name', fn: 'escapeHtml', args: ['raw'] },
  { line: 8, fn: 'render', args: ['name'] },
  { line: 9, to: 'q3', fn: 'concat', args: ['name'] },
  { line: 10, fn: 'runQuery', args: ['q3'] },
];
const taint = {};            // variable -> contexts where it is still dangerous
let findings = 0;
for (const s of prog) {
  const incoming = [...new Set(s.args.flatMap(a => taint[a] || []))];
  if (SOURCES.includes(s.fn)) taint[s.to] = ['sql', 'html'];
  else if (CLEANS[s.fn]) taint[s.to] = incoming.filter(c => !CLEANS[s.fn].includes(c));
  else if (SINKS[s.fn]) {
    const bad = incoming.includes(SINKS[s.fn]);
    if (bad) findings++;
    console.log(`line ${s.line}: ${s.fn}(${s.args}) ${bad ? 'FINDING' : 'ok'}`);
    continue;
  } else taint[s.to] = incoming;  // unknown function: taint passes through
  console.log(`line ${s.line}: ${s.to} = ${s.fn}(${s.args}) taint=[${taint[s.to]}]`);
}
console.log(`findings: ${findings}`);

line 1: raw = readParam() taint=[sql,html]
line 2: q1 = concat(raw) taint=[sql,html]
line 3: runQuery(q1) FINDING
line 4: id = toInt(raw) taint=[]
line 5: q2 = concat(id) taint=[]
line 6: runQuery(q2) ok
line 7: name = escapeHtml(raw) taint=[sql]
line 8: render(name) ok
line 9: q3 = concat(name) taint=[sql]
line 10: runQuery(q3) FINDING
findings: 2

৩ · SAST বাস্তবে — rule, tuning আর false positive

বাজারে নানা tool আছে। উদাহরণ হিসেবে Semgrep কোডের মতো দেখতে pattern দিয়ে rule লিখতে দেয়। CodeQL কোডকে একধরনের database বানিয়ে query চালায়, তাই গভীর data-flow লেখা যায়। দুটির কোনোটিকেই আমরা সুপারিশ করছি না। লাইসেন্সের শর্ত যাচাই করুন: যেমন CodeQL-এর query MIT লাইসেন্সে হলেও CLI আলাদা শর্তে আসে, আর বন্ধ-উৎস কোড বিশ্লেষণে আলাদা বাণিজ্যিক লাইসেন্স লাগার কথা তাদের repository-তে লেখা আছে। শর্ত বদলাতে পারে।

নিচের rule আপনার নিজের Python কোডে eval-এর ব্যবহার ধরে, কিন্তু স্থির লেখায় eval বাদ দেয়। এই শেষের অংশটিই tuning.

rules:
  - id: no-eval-on-dynamic-text
    languages: [python]
    severity: HIGH
    message: eval() runs text as code. Use int(), json.loads() or a small parser.
    patterns:
      - pattern: eval(...)
      - pattern-not: eval("...")
    metadata:
      cwe: "CWE-95"

Rule-টি উদাহরণ, Semgrep-এর docs-এর বর্ণিত গঠন মেনে লেখা। আমরা এখানে YAML-এর গঠন যাচাই করেছি, কিন্তু tool চালাইনি। severity-র মান docs অনুযায়ী এখন LOW থেকে CRITICAL, আর পুরোনো ERROR, WARNING, INFO এখনো চলে। নিজের version-এর docs দেখে নিন। Taint-এর rule-ও লেখা যায়, সেখানে source, sink আর sanitizer আলাদা করে দিতে হয়।

False positive-এর দাম — একটি হিসাব

False positive মানে tool বলল ত্রুটি, আসলে নয়। False negative মানে ত্রুটি আছে, tool চুপ। দুটোরই দাম আছে। ধরুন একটি কাল্পনিক দলের tool প্রথম চালানোয় ২০০টি finding দিল। যাচাই করে দেখা গেল ৩০টি সত্য। প্রতিটি দেখতে সময় লাগে ৬ মিনিট। এরপর দল rule tune করল: finding নামল ৪০-এ, যার ২৫টি সত্য।

সময় পাঁচ ভাগের এক ভাগ হলো, কিন্তু ৫টি সত্য ত্রুটি হারাল। এটিই tuning-এর আসল সিদ্ধান্ত। Recall আর precision-এর টানাপোড়েন IDS-এর পর্বে দেখেছেন, এখানেও একই হিসাব। তাই কোন rule নামালেন, কেন নামালেন, কে অনুমোদন করলেন, লিখে রাখুন। Tuning-এর ভালো উপায়গুলো:

• Sanitizer শেখানো: দলের নিজের নিরাপদ ফাংশন rule-এ যোগ করা, যা false positive কমায় কিন্তু সত্য ত্রুটি হারায় না।
• Path বাদ দেওয়া: তৈরি করা কোড আর test fixture সীমিতভাবে বাদ দেওয়া। সতর্ক থাকুন, test ফোল্ডারে আসল secret-ও থাকতে পারে।
• কারণসহ চুপ করানো: লাইনে suppression দিলে পাশে কারণ, তারিখ আর ticket লেখা। কারণ ছাড়া suppression পরে কেউ বোঝে না।
• শুধু নতুন finding-এ আটকানো: পুরোনো ঋণ আলাদা তালিকায় রেখে শুধু নতুন কোডের ত্রুটিতে build থামানো।

৪ · DAST, IAST আর RASP — চলন্ত সিস্টেমে পরীক্ষা

কোড দেখে সব বোঝা যায় না। Reverse proxy হয়তো একটি header মুছে দিচ্ছে, config হয়তো debug চালু রেখেছে। এগুলো দেখা যায় শুধু সিস্টেম চললে। DAST বাইরে থেকে application-কে ব্যবহারকারীর মতো অনুরোধ পাঠায়, আর উত্তরে ত্রুটির চিহ্ন খোঁজে। এটি কোডের ভেতর দেখে না, তাই একে black-box পরীক্ষা বলে। ZAP-এর মতো tool এর পরিচিত উদাহরণ। DAST ধ্বংসাত্মক হতে পারে: form-এ হাজার হাজার ভুয়া order, মুছে ফেলার বোতাম চাপা, ভুল ঠিকানায় email পাঠানো। তাই এর নিয়ম কড়া।

নিরাপদ DAST চালানোর চেকলিস্ট:

• Staging-এর ঠিকানা আর সময় লিখিত, মালিক ও দলকে জানানো
• শুধু নকল ডেটা, email আর payment বাইরে যায় না
• আলাদা test account, ভূমিকা অনুযায়ী অন্তত দুটি, যাতে authenticated scan login-এর পরের পাতা দেখে
• অনুরোধের গতি সীমিত, আর বন্ধ করার উপায় জানা
• চালানোর আগে backup, শেষে পরিবেশ পরিষ্কার
• API থাকলে OpenAPI spec দেওয়া, যাতে crawler-এর বাইরের পথও পরীক্ষা হয়

৫ · SCA আর secret scanning — দুটি সহজ জয়

আপনার application-এর বড় অংশই হয়তো অন্যের লেখা library. SCA সেই তালিকা ধরে জানা দুর্বলতার সাথে মেলায়। বিস্তারিত দেখেছেন পর্ব ৪৮-এ। এখানে শুধু তিনটি কথা:

• Lockfile থেকে পড়ুন: Manifest-এ লেখা সরাসরি dependency নয়, আসল ইনস্টল হওয়া transitive dependency-সহ তালিকা দেখুন।
• সব alert সমান নয়: পর্ব ৩২-এর CVSS, EPSS আর KEV দিয়ে সাজান। Reachability দেখায় ত্রুটিপূর্ণ ফাংশন আদৌ ডাকা হয় কি না, তবে “reachable নয়” বিচারটিও ভুল হতে পারে।
• এটি অজানা ত্রুটি ধরে না: CVE না থাকলে SCA চুপ। আর ভুয়া নামের package বা supply chain কারসাজির জন্য আলাদা পাহারা লাগে।

Secret scanning কোড আর git history-তে key, token, password-এর আকৃতি খোঁজে। পদ্ধতি দুটি: পরিচিত prefix-এর regex, আর এলোমেলো দেখতে লেখার entropy মাপা। Entropy-ভিত্তিক খোঁজে false positive বেশি, কারণ hash আর ছবির base64-ও এলোমেলো দেখায়। Gitleaks বা TruffleHog-এর মতো tool এর উদাহরণ। তিন জায়গায় পাহারা রাখুন: commit-এর আগে, CI-তে, আর পুরো history-তে একবার।

৬ · Fuzzing — অদ্ভুত ইনপুটে নিজের কোড ঝাঁকানো

বাচ্চার হাতে নতুন খেলনা দিলে কী হয়? সে নিয়ম পড়ে না। উল্টো ধরে, আছাড় দেয়, পানিতে ফেলে। ডিজাইনার যা ভাবেননি, তাই ঘটে। Fuzzing আপনার কোডের সাথে এই কাজটিই করে, লাখো বার। লক্ষ্য একটি: এমন ইনপুট খোঁজা যাতে প্রোগ্রাম crash করে, ঝুলে যায় বা কোনো নিয়ম ভাঙে। Parser, file format, protocol আর decoder এর সেরা লক্ষ্য।

পুরোপুরি এলোমেলো ইনপুট সাধারণত প্রথম যাচাইতেই বাদ পড়ে, ভেতরের কোডে পৌঁছায় না। Coverage-guided fuzzing এটি সমাধান করে। Fuzzer দেখে কোন ইনপুট কোডের নতুন পথ খুলল। সেই ইনপুট রেখে দেয়, আর তাকেই বদলে পরের ইনপুট বানায়। এক ধাপ এক ধাপ করে ভেতরে ঢোকে। মোট চারটি অংশ লাগে:

এই sanitizer taint-এর sanitizer নয়, শব্দ এক কিন্তু কাজ আলাদা। ASan, UBSan, TSan আর MSan হলো compiler-এর দেওয়া পাহারা, যা যথাক্রমে memory, undefined behavior, thread আর অনির্ধারিত মানের ভুল ধরে। C-এর এই ভুলগুলোর ধারণা আছে C কোর্সের এই পর্বে, আর দেখেছেন পর্ব ৪৭-এ।

নিচের কোডটি যা দেখাবে, প্রথমে তা ধাপে ধাপে দেখুন। লক্ষ্য একটি খেলনা parser. একটি record-এ থাকে TV, তারপর kind, length, payload আর একটি flag. kind 2-এর শাখায় length যাচাই করতে ভুলে যাওয়া হয়েছে।

এবার পুরো পরীক্ষাটি চালান। Fuzzer আর parser একই ব্লকে আছে। Fixed seed থাকায় প্রতিবার একই ফল আসবে। পরে মেরামত করে একই fuzzer আবার চলে।

# Mini coverage-guided fuzzer against a deliberately buggy TOY parser.
import random
class Reject(Exception): pass  # clean rejection; anything else is a crash

def parse(d, cov, fixed):            # record: T V kind length payload flag
    if d[:2] != b"TV" or len(d) < 4:
        raise Reject
    kind, length = d[2], d[3]
    cov.add(f"kind{kind}" if kind in (1, 2) else "bad-kind")
    end = 4 + length
    if kind not in (1, 2) or ((kind == 1 or fixed) and end >= len(d)):
        raise Reject                 # kind 2 forgot this length check
    flag = d[end]                    # BUG: kind 2 can read past the end
    cov.add(f"flag{kind}")
    return d[4:end], flag

def fuzz(fixed, execs=3000):
    rng = random.Random(49)          # fixed seed: same result every run
    corpus, seen = [b"TV\x01\x02ab!"], set()
    parse(corpus[0], seen, fixed)
    for i in range(1, execs + 1):
        m = rng.choice(corpus); pos = rng.randrange(len(m))
        m = m[:pos] + bytes([rng.choice([0, 1, 2, 3, 255])]) + m[pos + 1:]
        cov = set()
        try: parse(m, cov, fixed)
        except Reject: pass
        except IndexError:
            return print(f"exec {i}: CRASH input={m.hex(' ')}")
        if cov - seen:
            print(f"exec {i}: new {sorted(cov - seen)} input={m.hex(' ')}")
            seen |= cov; corpus.append(m)
    print(f"{execs} execs, no crash, corpus size {len(corpus)}")

fuzz(fixed=False); print("--- after the fix ---"); fuzz(fixed=True)

exec 1: new ['bad-kind'] input=54 56 03 02 61 62 21
exec 10: new ['flag2', 'kind2'] input=54 56 02 02 61 62 21
exec 13: CRASH input=54 56 02 ff 61 62 21
--- after the fix ---
exec 1: new ['bad-kind'] input=54 56 03 02 61 62 21
exec 10: new ['flag2', 'kind2'] input=54 56 02 02 61 62 21
3000 execs, no crash, corpus size 3

বাস্তবে C কোডের জন্য harness এত ছোট হতে পারে। নিচের উদাহরণ libFuzzer-এর, Clang-এর সাথে আসে। AFL++ আর Honggfuzz-ও এমন engine. Python-এ Atheris, Java-তে Jazzer-এর মতো tool আছে। এটি শুধু আপনার নিজের parser-এর জন্য।

#include <stddef.h>
#include <stdint.h>

int parse_record(const uint8_t *data, size_t size);  /* your own code */

int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    parse_record(data, size);
    return 0;
}

/* Build: clang -g -O1 -fsanitize=fuzzer,address fuzz_parser.c parser.c -o fuzz_parser
   Run on your own machine: ./fuzz_parser corpus/ */

Property-based testing — নিয়ম লিখুন, ইনপুট tool বানাবে

Fuzzing crash খোঁজে। Property-based testing খোঁজে নিয়মের ভঙ্গ। আপনি উদাহরণ লেখেন না, এমন একটি কথা লেখেন যা সব ইনপুটে সত্য হওয়ার কথা। যেমন: encode করে decode করলে আসল ডেটাই ফেরে। Tool নানা ইনপুট বানায়, আর ব্যর্থ ইনপুটকে ছোট করে আপনাকে দেখায়। Haskell-এর QuickCheck (২০০০) এই ধারার সূচনা, Python-এ Hypothesis পরিচিত।

from hypothesis import given, strategies as st
from myparser import encode, decode   # your own code

@given(st.binary(max_size=255))
def test_round_trip(payload):
    assert decode(encode(payload)) == payload

৭ · Bug থেকে স্থায়ী পাহারা — regression আর misuse-case test

সড়ক দুর্ঘটনার পরে শুধু গাড়ি মেরামত করলে একই মোড়ে আবার দুর্ঘটনা হবে। ভালো কর্তৃপক্ষ সেখানে স্পিড ব্রেকার বসায়, যা স্থায়ীভাবে থাকে। একটি সারানো bug-কে regression test বানানো ঠিক সেই স্পিড ব্রেকার। নিরাপত্তা bug প্রায়ই ফিরে আসে, যখন কেউ কোড নতুন করে লেখেন বা পুরোনো branch মেলান।

54 56 02 ff 61 62 21
IndexError in parse()

parse(bytes.fromhex("54 56 02 ff 61 62 21"))
IndexError  (পুনরায় ঘটানো গেছে)

with self.assertRaises(Reject):
    parse(crash_input)
old code: problems 1

if 4 + length >= len(d):
    raise Reject("length beyond record")
return d[4:4 + length], d[4 + length]

fixed code: problems 0
crash input-টি fuzz corpus-এও যোগ হলো

নিচের কোড একই test-কে পুরোনো আর মেরামত করা দুই কোডেই চালায়। এখানে unittest ব্যবহার হয়েছে, যা Python-এর সাথেই আসে (পুরো ধারণা আছে Python-এর testing পর্বে)।

# A past bug becomes a permanent test. Runs against old and fixed code.
import unittest

class Reject(Exception):
    pass

def parse_old(d):                    # kind-2 record, before the fix
    length = d[3]
    return d[4:4 + length], d[4 + length]

def parse_fixed(d):
    length = d[3]
    if 4 + length >= len(d):
        raise Reject("length beyond record")
    return d[4:4 + length], d[4 + length]

parse = None                         # chosen below

class Bug142Regression(unittest.TestCase):
    def test_length_past_end_is_rejected(self):
        with self.assertRaises(Reject):
            parse(bytes.fromhex("54 56 02 ff 61 62 21"))

    def test_valid_record_still_parses(self):
        self.assertEqual(parse(b"TV\x02\x02ab!"), (b"ab", 33))

    def test_last_valid_length(self):    # boundary: flag is the last byte
        self.assertEqual(parse(b"TV\x02\x03ab!?"), (b"ab!", 63))

for name, fn in [("old code", parse_old), ("fixed code", parse_fixed)]:
    parse = fn
    result = unittest.TestResult()
    unittest.defaultTestLoader.loadTestsFromTestCase(Bug142Regression).run(result)
    bad = [t.id().split(".")[-1] for t, _ in result.errors + result.failures]
    print(f"{name}: ran {result.testsRun}, problems {len(bad)} {bad}")

old code: ran 3, problems 1 ['test_length_past_end_is_rejected']
fixed code: ran 3, problems 0 []

Misuse-case test — “কী করা উচিত নয়” পরীক্ষা করা

সাধারণ test বলে, ক্রেতা নিজের order দেখতে পান। Misuse-case test বলে, ক্রেতা অন্যের order দেখতে পান না। এই “না” গুলো সাধারণত কেউ লেখেন না, অথচ broken access control-এর ত্রুটি ঠিক এখানেই থাকে, আর SAST বা DAST এগুলো প্রায়ই ধরতে পারে না, কারণ tool জানে না কে কার order দেখার অধিকারী। Threat model-এর প্রতিটি ঝুঁকি থেকে একটি করে test বানান।

৮ · হাতে secure code review আর পরীক্ষার গাইড

Tool “কোন ফাংশন বিপজ্জনক” বলতে পারে। “এই ক্রেতার কি এই ছাড় পাওয়ার কথা?” বলতে পারে না। সেই প্রশ্ন মানুষের। সাধারণ review-এর নিয়ম Code review পর্বে আছে। Secure review আলাদা, কারণ এতে আপনি কোডটি ওপর থেকে নিচে পড়েন না। আপনি ডেটার পিছু নেন।

একটি কার্যকর ক্রম:

1. উদ্দেশ্য বুঝুন: এই পরিবর্তন কী করে, কোন ডেটা ছোঁয়, threat model কী বলে।
2. প্রবেশপথের তালিকা করুন: Route, API, file upload, queue, webhook, cron job.
3. Sink খুঁজুন: SQL, shell, HTML, file path, redirect, deserialize, URL fetch.
4. দুটি জোড়া দিন: প্রতিটি sink থেকে পেছনে হেঁটে দেখুন, ডেটা কোথা থেকে আসে, পথে কী পরিষ্কার হয়।
5. Trust boundary দেখুন: কোথায় identity আর অনুমতি যাচাই হয়, আর সেটি সব পথে আছে কি না।
6. অনুপস্থিত জিনিস খুঁজুন: Diff-এ যা নেই, সেটিই প্রায়ই ত্রুটি: নতুন route-এ authorization না থাকা।

গাইড দুটি — WSTG আর ASVS

নিজে নিজে সব মনে রাখতে হবে না। OWASP-এর দুটি নথি কাজে লাগে, আর দুটির কাজ আলাদা:

একসাথে ব্যবহার সহজ: ASVS থেকে আপনার application-এর level-এর requirement নিন, আর প্রতিটির জন্য WSTG থেকে পদ্ধতি ও নিজের misuse-case test বানান। আপনি যেদিন পড়ছেন সেদিনের version প্রকল্পের পাতায় দেখে নিন।

৯ · ফল সামলানো — triage, CI আর যা ধরা পড়ে না তা মাপা

তিনটি tool একই ত্রুটি তিনভাবে জানাতে পারে। লাইন নম্বর আলাদা, নাম আলাদা। হাসপাতালের জরুরি বিভাগে যেমন রোগী বাছাই হয়, finding triage-ও তাই: সত্য কি না, কতটা গুরুতর, কে সারাবেন, কবে। প্রথম কাজ deduplication. SARIF-এর মতো সাধারণ format নানা tool-এর ফল এক জায়গায় আনা সহজ করে।

একটি হিসাবে সতর্ক থাকুন। Tool-এর জগতে “false positive rate ৬০%” বলতে মানুষ প্রায়ই বোঝান, ফলের ৬০% ভুল। এটি আসলে FP ÷ (FP + TP). গবেষণা আর এই কোর্সের সংজ্ঞায় false positive rate হলো FP ÷ (FP + TN), অর্থাৎ নিরাপদ জিনিসের কত অংশে ভুল alert হলো। আলাদা দুটি সংখ্যা। Tool-এর দাবি পড়লে জিজ্ঞেস করুন, হরে কী আছে।

// Toy triage. Fake findings from three imaginary tools on your own code.
const raw = [
  ['sast-a', 'CWE-89', 'order.js', 'getOrder', 'real'],
  ['sast-b', 'CWE-89', 'order.js', 'getOrder', 'real'],
  ['dast-c', 'CWE-89', 'order.js', 'getOrder', 'real'],
  ['sast-a', 'CWE-79', 'view.js', 'showName', 'real'],
  ['dast-c', 'CWE-79', 'view.js', 'showName', 'real'],
  ['sast-a', 'CWE-22', 'file.js', 'download', 'real'],
  ['sast-a', 'CWE-89', 'report.js', 'daily', 'false'],
  ['sast-b', 'CWE-89', 'report.js', 'daily', 'false'],
  ['sast-a', 'CWE-79', 'admin.js', 'banner', 'false'],
  ['sast-b', 'CWE-79', 'admin.js', 'banner', 'false'],
  ['sast-b', 'CWE-327', 'hash.js', 'cacheKey', 'false'],
  ['sast-a', 'CWE-798', 'test/fixture.js', 'setup', 'false'],
];
const seen = new Map();
for (const [tool, cwe, file, fn, verdict] of raw) {
  const key = `${cwe}|${file}|${fn}`;     // line numbers left out: they move
  if (!seen.has(key)) seen.set(key, { tools: new Set(), verdict });
  seen.get(key).tools.add(tool);
}
const unique = [...seen.values()];
const tp = unique.filter(f => f.verdict === 'real').length;
const fp = unique.length - tp;
const safeCases = 40, seededBugs = 5;     // from a labelled test set of your own
const pct = x => (100 * x).toFixed(1) + '%';
console.log(`raw ${raw.length} -> unique ${unique.length}`);
for (const [k, f] of seen) console.log(`  ${k}  tools=${f.tools.size}  ${f.verdict}`);
console.log(`TP ${tp}, FP ${fp}, precision ${pct(tp / (tp + fp))}`);
console.log(`share of findings that were false: ${pct(fp / (tp + fp))}`);
console.log(`FP rate FP/(FP+TN): ${pct(fp / safeCases)} of ${safeCases} safe cases`);
console.log(`recall on seeded bugs: ${pct(tp / seededBugs)}`);
console.log(`Benchmark-style score TPR-FPR: ${pct(tp / seededBugs - fp / safeCases)}`);

raw 12 -> unique 7
  CWE-89|order.js|getOrder  tools=3  real
  CWE-79|view.js|showName  tools=2  real
  CWE-22|file.js|download  tools=1  real
  CWE-89|report.js|daily  tools=2  false
  CWE-79|admin.js|banner  tools=2  false
  CWE-327|hash.js|cacheKey  tools=1  false
  CWE-798|test/fixture.js|setup  tools=1  false
TP 3, FP 4, precision 42.9%
share of findings that were false: 57.1%
FP rate FP/(FP+TN): 10.0% of 40 safe cases
recall on seeded bugs: 60.0%
Benchmark-style score TPR-FPR: 50.0%

CI-র জন্য ছোট একটি tool set

দশটি tool বসিয়ে কেউ ফল না পড়লে লাভ নেই। প্রতিটি শ্রেণি থেকে একটি দিয়ে শুরু করুন, আর আগে ঠিক করুন কে দেখবেন। Pipeline-এর গঠন আর gate-এর নকশা আছে DevSecOps পর্বে।

Tool কী বাদ দিচ্ছে, তা মাপা

“শূন্য finding” দুই রকম হতে পারে: কোড ভালো, অথবা tool অন্ধ। পার্থক্য জানার উপায় আছে:

• Seeded bug: Test branch-এ জানা ত্রুটি রেখে দেখুন tool ধরে কি না। শুধু নিজের test কোডে, production-এ কখনো নয়।
• পুরোনো ঘটনা ফিরে দেখা: আগে যে bug production-এ গিয়েছিল, tool কি সেটি তখনকার কোডে ধরত?
• জানা উত্তরের সেট: OWASP Benchmark-এর মতো সেটে TPR − FPR মাপা হয়। সব কিছুতে “ত্রুটি” বলা tool-এর স্কোর ০। তবে এই সেট ছোট ও কৃত্রিম কেস দিয়ে বানানো, তাই আপনার কোডে ফল আলাদা হতে পারে।
• Coverage দেখা: DAST কত route ছুঁল? Fuzz কত শাখায় গেল? না ছোঁয়া অংশ নিয়ে tool কিছুই বলতে পারে না।
• দুই tool-এর মিল: নিচের হিসাবটি দেখুন।

১০ · AI-এর যুগে নিরাপত্তা পরীক্ষা

AI কোড পড়তে পারে, test লিখতে পারে, finding বোঝাতে পারে। সে একজন দ্রুত সহকারী। কিন্তু নিরাপত্তায় তার ভুলের দাম বেশি, কারণ ভুল উত্তরও আত্মবিশ্বাসী শোনায়। সাধারণ ভুলগুলো:

AI-এর ফল হাতে পেলে — চেকলিস্ট

• Prompt-এ কোনো secret, token বা ব্যক্তিগত ডেটা দিইনি
• প্রতিটি CVE, CWE আর standard-এর নম্বর মূল উৎসে মিলিয়েছি
• AI-এর “এটি false positive” কথাটি নিজে source থেকে sink পর্যন্ত যাচাই করেছি
• AI-এর লেখা test পুরোনো কোডে ব্যর্থ হয়, এটি দেখেছি
• Diff পড়েছি: কোনো check, test বা verification বন্ধ করা হয়নি
• মানুষের ওপর প্রভাব ফেলে এমন সিদ্ধান্ত একজন মানুষ নিয়েছেন