Chốt tiêu chí trước khi xem bản trình diễn
Nghiệm thu phần mềm theo yêu cầu cần chứng minh rằng người dùng hoàn thành được công việc đã thống nhất, với dữ liệu và quyền truy cập phù hợp. Theo đề xuất của LYVIA, hãy chuẩn bị tình huống kiểm thử trước buổi bàn giao, thay vì chỉ xem nhà phát triển bấm qua các màn hình.
NIST mô tả SSDF là tập hợp thực hành phát triển phần mềm an toàn và ngôn ngữ chung hỗ trợ trao đổi giữa bên phát triển và bên mua. Từ góc độ triển khai, LYVIA đề xuất biến yêu cầu chung thành câu hỏi kiểm chứng: ai thực hiện, dùng dữ liệu nào, kết quả mong đợi là gì và bằng chứng nằm ở đâu.
Ví dụ minh họa: với công cụ quản lý yêu cầu nội bộ, một tình huống là nhân viên tạo yêu cầu, quản lý phê duyệt và bộ phận xử lý cập nhật kết quả. Đây là tình huống giả định để xây dựng tiêu chí, không phải kết quả của một khách hàng.
SSDF chia thực hành thành 4 nhóm: chuẩn bị tổ chức, bảo vệ phần mềm, tạo ra phần mềm an toàn và ứng phó với lỗ hổng. Đây là khung tham khảo của NIST; bảng dưới đây là cách LYVIA đề xuất chuyển nhu cầu bàn giao thành bằng chứng cụ thể, không phải chứng nhận SSDF.
| Nội dung kiểm tra | Bằng chứng cần xem | Điều kiện chấp nhận |
|---|---|---|
| Nghiệp vụ | Người dùng thực hiện tình huống đã thống nhất | Kết quả khớp dữ liệu mẫu và quy tắc nghiệp vụ |
| Phân quyền | Thử bằng tài khoản của từng vai trò | Không đọc hoặc sửa dữ liệu ngoài quyền được giao |
| Sự cố kết nối | Mô phỏng lỗi và kiểm tra trạng thái | Có thông báo, người phụ trách và cách xử lý |
| Bàn giao | Tài liệu, quyền quản trị, bản xuất dữ liệu | Đội ngũ có thể vận hành phần việc đã nhận |
Nguồn tham khảo: NIST — Secure Software Development Framework
Kiểm tra bằng từng vai trò thực tế
OWASP ASVS cung cấp cơ sở để kiểm tra các biện pháp bảo mật kỹ thuật của ứng dụng web. Doanh nghiệp có thể yêu cầu bên triển khai chỉ rõ phạm vi kiểm tra phù hợp, thay vì coi việc đăng nhập thành công là bằng chứng toàn bộ hệ thống an toàn.
Trong ví dụ của LYVIA, hãy tạo tài khoản thử cho nhân viên, quản lý và người quản trị. Nhân viên xem yêu cầu của mình; quản lý xử lý đúng phạm vi được giao. Thử mở trực tiếp đường dẫn của một yêu cầu không thuộc quyền truy cập, thay vì chỉ kiểm tra nút có bị ẩn trên giao diện hay không.
Ghi kết quả mong đợi và kết quả thực tế cho từng vai trò. Dữ liệu thử cần đủ gần với nghiệp vụ để phát hiện sai sót, nhưng không nên sao chép dữ liệu khách hàng nhạy cảm khi không cần thiết. Một lần kiểm tra này không thay thế đánh giá bảo mật chuyên sâu.
Nguồn tham khảo: OWASP — Application Security Verification Standard
Thử cả lúc kết nối hoặc dữ liệu gặp lỗi
Microsoft hướng dẫn thiết kế nhánh xử lý khi một bước tự động thất bại, hết thời gian chờ hoặc bị bỏ qua. Tài liệu cũng trình bày cơ chế thử lại cho lỗi tạm thời. Những khả năng đó cần được cấu hình theo hệ thống cụ thể, không mặc định có sẵn trong mọi phần mềm.
Danh sách nghiệm thu do LYVIA đề xuất gồm ba câu hỏi: nếu kết nối bị ngắt thì người dùng thấy gì; nếu bấm gửi hai lần thì có tạo hai yêu cầu không; nếu dữ liệu thiếu thì hệ thống từ chối hay âm thầm lưu sai? Với mỗi trường hợp, cần xác định người nhận cảnh báo và cách xử lý tiếp.
Đừng chỉ yêu cầu ảnh chụp thông báo lỗi. Hãy đối chiếu bản ghi sau thử nghiệm, kiểm tra việc gửi trùng và xác nhận có thể tiếp tục từ trạng thái hợp lệ. Nếu chưa xử lý được, ghi rõ lỗi tồn đọng và tác động trước khi quyết định đưa vào sử dụng.
Nguồn tham khảo: Microsoft Learn — Employ robust error handling
Bàn giao để đội ngũ tiếp tục vận hành
SSDF của NIST đề cập cả việc chuẩn bị tổ chức, bảo vệ phần mềm và ứng phó với lỗ hổng. Vì vậy, LYVIA khuyến nghị xem bàn giao là một phần của khả năng vận hành lâu dài, không chỉ là nhận đường dẫn website hoặc tệp mã nguồn.
Biên bản nên chỉ rõ phiên bản đã nghiệm thu, tình huống đã kiểm tra, lỗi còn lại và người quyết định chấp nhận. Danh mục bàn giao cần ghi tài khoản thuộc doanh nghiệp, tài liệu sử dụng, cách sao lưu và đầu mối hỗ trợ. Quyền sở hữu mã nguồn và giấy phép bên thứ ba phải theo hợp đồng.
Chọn một người trong đội ngũ thực hiện lại công việc bằng tài liệu bàn giao. Nếu họ cần người phát triển thao tác hộ ở mọi bước, cần bổ sung hướng dẫn trước khi kết thúc. Phạm vi bảo trì, thời gian phản hồi và chi phí vận hành nên được thống nhất riêng.
Điều kiện đưa vào sử dụng theo đề xuất LYVIA: các tình huống nghiệp vụ quan trọng đã đạt, không còn lỗi chặn vận hành trong phạm vi thống nhất, người phụ trách đã nhận tài liệu và biết cách xử lý sự cố. Nếu thiếu một điều kiện, ghi rõ phần chưa nghiệm thu và kế hoạch khắc phục trước khi mở rộng.
Nguồn tham khảo: NIST — Secure Software Development Framework
Câu hỏi thường gặp
Có cần kiểm tra mọi chức năng trong một buổi?
Nên ưu tiên quy trình quan trọng và các điều kiện nghiệm thu đã thống nhất, sau đó ghi rõ phần chưa kiểm tra. Đây là cách tổ chức do LYVIA đề xuất; không nên tuyên bố đạt toàn bộ ASVS nếu chưa đánh giá đầy đủ phạm vi tương ứng.
Một bản trình diễn chạy tốt đã đủ để nghiệm thu chưa?
Chưa đủ. Theo đề xuất của LYVIA, cần có người dùng thực hiện, kiểm tra quyền truy cập và tình huống lỗi, rồi ghi nhận bằng chứng trên phiên bản sẽ bàn giao.
Nguồn và ngày đối chiếu
- NIST — Secure Software Development Framework — 2026-09-24
- OWASP — Application Security Verification Standard — 2026-09-24
- Microsoft Learn — Employ robust error handling — 2026-09-24
Bài viết liên quan
Áp dụng vào doanh nghiệp của bạn
Mỗi quy trình có dữ liệu, quyền truy cập và giới hạn khác nhau. LYVIA cùng bạn xác định phạm vi, tiêu chí nghiệm thu và chi phí vận hành trước khi triển khai.