Mở đầu — vì sao bài này quan trọng
Có một hiểu lầm rất phổ biến trong đội ngũ kỹ thuật: "Bảo mật là việc của team Security" hoặc "Chúng ta có anh chuyên gia bảo mật rồi, khỏi lo". Nếu bạn là Tech Lead và bạn tin điều này, sớm hay muộn bạn sẽ phải trả giá — thường là vào lúc 2 giờ sáng, khi một lỗ hổng trong code của team bạn bị khai thác.
Sự thật là: với tư cách Tech Lead, bạn không phải là security expert (chuyên gia bảo mật), và cũng không ai kỳ vọng bạn phải là chuyên gia. Nhưng bạn accountable — chịu trách nhiệm giải trình cuối cùng — cho mức độ an toàn của code mà team bạn viết ra. Đây là sự khác biệt cốt lõi giữa "responsible" (người thực thi) và "accountable" (người chịu trách nhiệm). Bạn có thể ủy quyền việc pentest cho chuyên gia, nhưng bạn không thể ủy quyền trách nhiệm rằng team mình phải viết code an toàn.
Tại Việt Nam và Đông Nam Á, áp lực này càng lớn. Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân đã có hiệu lực, các startup fintech phải qua vòng thẩm định bảo mật của Ngân hàng Nhà nước, và các công ty làm outsourcing cho khách châu Âu bị ràng buộc bởi GDPR. Một sự cố rò rỉ dữ liệu không chỉ là vấn đề kỹ thuật — nó là vấn đề pháp lý, tài chính và uy tín. Là Tech Lead, bạn đứng ở tuyến đầu quyết định team có xây được thói quen an toàn hay không.
Bài học này không dạy bạn trở thành hacker. Nó dạy bạn cách lãnh đạo vấn đề bảo mật: biết đủ để đặt đúng câu hỏi, dựng đúng hàng rào phòng thủ, và tạo ra văn hóa mà mỗi kỹ sư đều coi bảo mật là một phần công việc của mình.
Khái niệm cốt lõi
Security là trách nhiệm phân tán, không phải phòng ban
Mô hình cũ coi Security là một "cổng gác" cuối cùng — code viết xong, ném qua cho team Security review, họ tìm lỗi rồi trả về. Mô hình này thất bại vì hai lý do: nó quá muộn (lỗi kiến trúc đã nằm sâu trong hệ thống) và quá đắt (sửa lỗi ở production đắt gấp 30–100 lần sửa lúc thiết kế).
Mô hình hiện đại gọi là "shift left" — dịch trách nhiệm bảo mật về phía sớm nhất trong vòng đời phát triển. Nghĩa là mỗi developer suy nghĩ về bảo mật ngay khi viết dòng code đầu tiên, chứ không đợi ai đó nhắc. Vai trò của Tech Lead là biến "shift left" từ một khẩu hiệu thành thói quen hằng ngày của team.
Threat modeling — tư duy như kẻ tấn công
Kỹ năng quan trọng nhất mà một Tech Lead cần truyền cho team không phải là biết vá lỗi, mà là biết đặt câu hỏi đúng trước khi lỗi xảy ra. Threat modeling (mô hình hóa mối đe dọa) là một bài tập tư duy đơn giản với bốn câu hỏi:
- Chúng ta đang xây gì? (vẽ luồng dữ liệu)
- Cái gì có thể sai? (dữ liệu nào nhạy cảm, ai muốn tấn công)
- Chúng ta sẽ làm gì với rủi ro đó?
- Chúng ta có làm đủ tốt không?
Top 10 mối nguy phải nắm (theo hướng OWASP)
OWASP Top 10 là danh sách chuẩn công nghiệp về các lỗ hổng web nguy hiểm nhất. Là Tech Lead, bạn không cần thuộc lòng cách khai thác từng lỗi, nhưng phải nhận diện được chúng khi review code hoặc thiết kế:
- Broken Access Control — Kiểm soát truy cập lỗi. User A xem được dữ liệu của user B chỉ bằng cách đổi ID trên URL. Đây là lỗi phổ biến và nguy hiểm nhất hiện nay.
- Cryptographic Failures — Lưu mật khẩu dạng plaintext, truyền dữ liệu không mã hóa, dùng thuật toán yếu.
- Injection — SQL Injection, Command Injection: dữ liệu người dùng bị thực thi như lệnh. Phòng bằng parameterized queries.
- Insecure Design — Lỗi ngay từ thiết kế, ví dụ không có rate-limit cho OTP nên bị brute-force.
- Security Misconfiguration — Để mặc định password admin/admin, mở S3 bucket public, bật debug mode ở production.
- Vulnerable Components — Dùng thư viện có lỗ hổng đã biết (như Log4Shell 2021).
- Authentication Failures — Đăng nhập yếu, session không hết hạn, không có MFA.
- Data Integrity Failures — Tin tưởng dữ liệu từ nguồn không kiểm chứng, deserialization không an toàn.
- Logging & Monitoring Failures — Bị tấn công mà không hề hay biết vì không có log.
- Server-Side Request Forgery (SSRF) — Server bị lừa gọi tới tài nguyên nội bộ.
Defense in depth — phòng thủ nhiều lớp
Không lớp bảo vệ nào là hoàn hảo. WAF (tường lửa ứng dụng) có thể bị vượt qua, validation phía client có thể bị bỏ qua. Nguyên tắc "defense in depth" nói rằng bạn phải có nhiều lớp: validate cả client lẫn server, mã hóa cả khi truyền lẫn khi lưu, phân quyền cả ở tầng API lẫn tầng database. Nếu một lớp thủng, lớp sau vẫn chặn được.
Tình huống thực tế
Tình huống 1: Startup fintech TP.HCM và lỗ hổng đổi ID
Một startup ví điện tử ở TP.HCM (gọi tắt là PayViet) có khoảng 40 kỹ sư, đang tăng trưởng nóng. Một researcher độc lập gửi email báo cáo: API /api/transactions?userId=1002 cho phép bất kỳ ai đã đăng nhập xem lịch sử giao dịch của bất kỳ user nào, chỉ bằng cách đổi số userId. Đây chính là lỗi Broken Access Control — hệ thống chỉ kiểm tra "bạn đã đăng nhập chưa" mà quên kiểm tra "dữ liệu này có phải của bạn không".
Điều đáng nói: code này đã qua review của hai senior. Vì sao lọt? Vì cả team coi việc "đã đăng nhập" là đủ, không ai đặt câu hỏi về quyền sở hữu dữ liệu ở cấp từng bản ghi. Tech Lead của team sau sự cố đã làm ba việc: thêm một middleware bắt buộc kiểm tra ownership ở mọi endpoint truy cập dữ liệu người dùng, thêm test tự động mô phỏng "user A cố xem dữ liệu user B" cho mọi API, và đưa "Access Control" thành mục đầu tiên trong checklist review.
Bài học: Lỗ hổng nguy hiểm nhất thường không phải lỗi tinh vi, mà là giả định sai lầm mà cả team cùng chia sẻ. Vai trò Tech Lead là phá vỡ giả định tập thể đó bằng threat modeling và test tự động.
Tình huống 2: Log4Shell và cuộc chạy đua nửa đêm
Tháng 12/2021, lỗ hổng Log4Shell (CVE-2021-44228) trong thư viện Log4j — một thư viện Java được dùng ở hầu như mọi nơi — bùng nổ. Điểm nghiêm trọng CVSS 10/10. Kẻ tấn công chỉ cần gửi một chuỗi text đặc biệt là có thể chiếm quyền điều khiển server.
Một công ty outsourcing ở Hà Nội với hơn 200 kỹ sư rơi vào tình cảnh hỗn loạn: không ai biết chính xác dự án nào đang dùng Log4j phiên bản nào, vì không có bản kiểm kê (inventory) các thư viện phụ thuộc. Team mất gần hai ngày chỉ để trả lời câu hỏi "chúng ta có bị ảnh hưởng không". Trong khi đó, một công ty đối thủ đã cài sẵn công cụ SCA (Software Composition Analysis) như Dependabot và Snyk — họ nhận cảnh báo tự động trong vòng vài giờ và vá xong trước bình minh.
Bài học: Bạn không thể bảo vệ thứ bạn không biết mình đang có. Tech Lead phải đảm bảo team có khả năng trả lời tức thì: "Chúng ta đang dùng những thư viện nào, phiên bản nào, cái nào có lỗ hổng?" Điều này đạt được bằng công cụ tự động, không bằng trí nhớ con người.
Tình huống 3: Secret bị commit lên Git
Một team nhỏ ở Đà Nẵng làm SaaS cho khách Mỹ. Một junior developer, trong lúc vội, commit thẳng file .env chứa AWS access key lên repository công khai trên GitHub. Trong vòng 9 phút, những con bot quét GitHub đã tìm thấy key này và bắt đầu tạo hàng loạt EC2 instance để đào tiền mã hóa. Hóa đơn AWS cuối tháng lên tới hơn 12.000 USD.
Nguyên nhân gốc không phải sự bất cẩn của một cá nhân, mà là thiếu hàng rào tự động: không có .gitignore chuẩn, không có secret scanning trong pipeline, không có pre-commit hook chặn commit chứa key. Sau sự cố, Tech Lead cài git-secrets và bật GitHub Secret Scanning, đồng thời chuyển toàn bộ secret sang một secret manager thay vì file .env.
Bài học: Đừng bao giờ đổ lỗi cho cá nhân về một lỗi mà lẽ ra hệ thống phải chặn được. Vai trò lãnh đạo của Tech Lead là dựng hàng rào để "làm đúng là con đường dễ nhất, làm sai bị chặn tự động".
Hướng dẫn từng bước
Đây là lộ trình để một Tech Lead nâng tầm bảo mật cho team, đi từ nền tảng đến trưởng thành:
Bước 1 — Kiểm kê tài sản và dữ liệu nhạy cảm. Liệt kê: hệ thống của bạn lưu dữ liệu gì (mật khẩu, thông tin cá nhân, dữ liệu thanh toán), dữ liệu nào chảy qua đâu, ai truy cập được. Không thể bảo vệ cái bạn không biết.
Bước 2 — Chạy một buổi threat modeling. Với mỗi tính năng lớn hoặc mỗi quý, ngồi cùng team 45–60 phút, vẽ luồng dữ liệu, và hỏi bốn câu hỏi threat modeling ở trên. Ghi lại rủi ro và ưu tiên xử lý.
Bước 3 — Dựng hàng rào tự động trong CI/CD. Đây là đòn bẩy lớn nhất. Cài tối thiểu: SAST (quét mã nguồn tĩnh, ví dụ SonarQube, Semgrep), SCA/Dependabot (quét thư viện có lỗ hổng), và secret scanning (chặn commit chứa key). Để pipeline fail khi phát hiện lỗ hổng nghiêm trọng.
Bước 4 — Đưa bảo mật vào Definition of Done và code review. Thêm checklist bảo mật vào PR template: đã validate input chưa, đã kiểm tra quyền truy cập chưa, có log secret ra ngoài không. Bảo mật không phải bước riêng, nó là một phần của "xong".
Bước 5 — Quản lý secret đúng cách. Chuyển mọi credential ra khỏi code, dùng secret manager (AWS Secrets Manager, HashiCorp Vault, hoặc tối thiểu là biến môi trường được mã hóa). Áp dụng nguyên tắc least privilege — mỗi service chỉ có đúng quyền tối thiểu cần thiết.
Bước 6 — Chuẩn bị cho sự cố. Có sẵn quy trình: ai được báo, ai có quyền quyết định rotate key, cách cô lập hệ thống. Bảo mật không phải là ngăn 100% sự cố (bất khả thi), mà là phát hiện nhanh và phản ứng gọn.
Bước 7 — Đầu tư vào văn hóa và kỹ năng. Tổ chức buổi chia sẻ ngắn, mời researcher demo một cuộc tấn công thật, khen thưởng người phát hiện lỗ hổng. Biến bảo mật thành niềm tự hào chứ không phải gánh nặng.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi bảo mật là việc của người khác. Tech Lead nói "để team Security lo" là đã thất bại. Bạn accountable, hãy hành động như vậy.
Lỗi 2 — Security theater (bảo mật hình thức). Bắt đổi mật khẩu 30 ngày một lần, ép độ phức tạp vô lý khiến người dùng viết password ra giấy note dán màn hình. Đây là làm cho có, không tăng an toàn thực. Hãy tập trung vào rủi ro thật (như MFA) thay vì hình thức.
Lỗi 3 — Đổ lỗi cá nhân sau sự cố. Điều này giết chết văn hóa báo cáo. Người ta sẽ giấu lỗi thay vì báo. Hãy dùng postmortem blameless và hỏi "hệ thống nào đã cho phép lỗi này xảy ra".
Lỗi 4 — Bảo mật bằng cách che giấu (security by obscurity). Nghĩ rằng "không ai biết endpoint này đâu" là an toàn. Kẻ tấn công có công cụ quét mọi thứ.
Lỗi 5 — Bỏ qua dependency. Phần lớn code chạy trong production không phải bạn viết, mà là thư viện của người khác. Không quét dependency là bỏ ngỏ cửa lớn nhất.
Mẹo: Ưu tiên theo rủi ro, đừng cố làm tất cả cùng lúc. Một endpoint xử lý thanh toán cần mức độ khắt khe khác với trang "Giới thiệu". Áp dụng nguyên tắc 80/20 — bịt những lỗ hổng nghiêm trọng nhất trước.
Mẹo: Làm cho "đường an toàn" là "đường dễ đi nhất". Nếu team có sẵn hàm safeQuery() chống injection, thư viện auth chuẩn, template PR có checklist — kỹ sư sẽ tự nhiên làm đúng mà không cần nhớ.
Bài tập thực hành
- Threat modeling một tính năng. Chọn một tính năng team bạn đang làm (ví dụ chức năng reset mật khẩu). Vẽ luồng dữ liệu và trả lời bốn câu hỏi threat modeling. Liệt kê ít nhất 5 cách một kẻ xấu có thể lạm dụng nó.
- Audit OWASP Top 10. Với hệ thống hiện tại của bạn, chấm điểm từng mục trong OWASP Top 10 theo thang: (a) có phòng thủ tự động, (b) phòng thủ thủ công, (c) chưa có gì. Xác định ba mục yếu nhất cần xử lý trước.
- Kiểm tra hàng rào CI/CD. Liệt kê pipeline của team đang có những công cụ bảo mật tự động nào (SAST, SCA, secret scanning). Nếu thiếu, viết đề xuất một trang giải thích công cụ nào cần thêm và vì sao.
- Viết checklist bảo mật cho PR. Soạn một checklist 5–7 mục gọn gàng để đính vào mọi pull request của team, dựa trên các rủi ro cụ thể của sản phẩm bạn.
- Diễn tập sự cố (tabletop). Giả định "một AWS key bị lộ lên GitHub". Cùng team viết ra: ai làm gì, trong bao lâu, theo thứ tự nào. Tìm ra điểm nghẽn trong quy trình phản ứng.
Tóm tắt
- Là Tech Lead, bạn không phải security expert, nhưng bạn accountable cho mức độ an toàn của code team mình. Trách nhiệm này không thể ủy quyền.
- Bảo mật hiện đại là trách nhiệm phân tán ("shift left"), đưa về sớm nhất trong vòng đời phát triển, không phải cổng gác cuối cùng.
- Kỹ năng quan trọng nhất cần truyền cho team là threat modeling — biết đặt đúng câu hỏi trước khi lỗi xảy ra, không cần công cụ đắt tiền, chỉ cần một bảng trắng và tư duy như kẻ tấn công.
- Nắm OWASP Top 10 đủ để nhận diện, với Broken Access Control, Injection và Vulnerable Components là những mối nguy phổ biến nhất tại Việt Nam.
- Đòn bẩy lớn nhất là hàng rào tự động trong CI/CD (SAST, SCA, secret scanning) — biến "làm đúng thành con đường dễ nhất".
- Ba câu chuyện thực tế — lỗi đổi ID ở fintech, Log4Shell, secret bị commit — cho thấy lỗ hổng nghiêm trọng thường đến từ giả định tập thể sai và thiếu hàng rào, chứ không phải sự bất cẩn cá nhân.
- Không đổ lỗi cá nhân, không làm bảo mật hình thức, và luôn ưu tiên theo rủi ro thật. Mục tiêu không phải ngăn 100% sự cố, mà là phát hiện nhanh và phản ứng gọn.