SAST đọc mã mà không chạy, DAST tấn công app đang chạy mà không đọc mã. Tôi gài lỗ hổng vào một app rồi chạy bandit và một DAST tự viết: mỗi công cụ bắt đúng cái công cụ kia mù, gần như bù trừ hoàn toàn — SAST cho danh sách *khả năng*, DAST cho danh sách *thực tế*, và một câu SQLi lệch khuôn thì cả hai đều hụt.
Kẻ tấn công parse không chỉ điều khiển kích thước dữ liệu mà cả cấu trúc của nó, và mỗi chiều đánh vào một tài nguyên khác nhau: JSON lồng sâu 100.000 cấp (195 KB) làm tràn stack, một số 100.000 chữ số đốt CPU O(n²), một mảng 5 triệu phần tử ngốn RAM. Tôi đo cả ba, và cho thấy vì sao giới hạn kích thước body — biện pháp phổ biến nhất — chỉ chặn được đúng một trục.
Checksum và chữ ký trông na ná nhau — đều là một chuỗi băm để kiểm — nhưng khác nhau ở toàn bộ vấn đề: cái nào cần bí mật để tạo ra. Tôi dựng quy trình ký Ed25519 và tấn công ba cách: sửa byte lộ, tự ký lại lộ; rồi cho thấy checksum chống được tai nạn nhưng vô dụng trước kẻ kiểm soát nơi phát hành, vì nó không đòi bí mật gì cả.
Tôi cộng cả ba lớp quan sát trên cùng một dịch vụ và đo tổng: −12,9% thông lượng, +19,3% CPU, +45,8% bộ nhớ. Nhưng phát hiện quan trọng hơn con số tổng là mô hình chi phí — chỉ số giữ trạng thái gộp nên KHÔNG tỷ lệ với lưu lượng (1.312 byte dù 20 nghìn hay 20 triệu yêu cầu), còn log và trace ghi từng sự kiện nên phình tuyến tính. Cùng lượng việc, trace tốn gấp 1.540 lần chỉ số.
DoS thường được hình dung là cơn lũ lưu lượng. Nhưng loại nguy hiểm hơn chỉ cần một request nhỏ mà đắt: regex 30 ký tự làm máy chủ bận 20 giây, 49 KB nén giải ra 50 MB, chính cơ chế băm mật khẩu chậm trở thành vũ khí. Bốn kiểu bất đối xứng, đo thật.
Một timing side channel: cách bạn so sánh token với bí mật để lộ token đúng tới đâu — không qua nội dung, mà qua thời gian. Byte-by-byte dừng sớm rò tuyến tính ~9 ns/byte; compare_digest giữ 666 ns bất biến. Và một bất ngờ: == của Python lại KHÔNG lộ, vì một lý do đáng nhớ.