Security

2 posts
challenge-icon

Solo builder: Vibe coding vs Cybersecurity?

user-avatar
Huyên Nguyễn
10/06/2026

Tôi không viết code, nhưng tôi thấy cái giá của việc bỏ qua security

Khi làm QA/Tester, có một thời gian tôi từng nghĩ: chỉ cần một tính năng hoạt động đúng theo yêu cầu thì đó đã là một sản phẩm tốt.Một màn hình hiển thị đúng, một nút bấm hoạt động đúng, dữ liệu trả về đúng kết quả — mọi thứ đều có vẻ ổn.Nhưng càng tham gia nhiều dự án, tôi càng nhận ra có những vấn đề không nằm ở việc “tính năng có chạy hay không”, mà nằm ở câu hỏi: “Nếu người dùng sử dụng sai cách thì chuyện gì sẽ xảy ra?”Đây cũng là lúc tôi nhìn vấn đề security khác đi.Trong quá trình test một hệ thống, tôi từng gặp một tình huống khiến tôi thay đổi cách suy nghĩ. Một chức năng về mặt giao diện hoạt động hoàn toàn bình thường. User không có quyền xem dữ liệu của người khác trên màn hình.Nhưng khi kiểm tra sâu hơn ở phía API, tôi phát hiện nếu thay đổi một vài thông tin trong request, hệ thống vẫn có thể trả về dữ liệu không thuộc quyền truy cập.Về mặt chức năng, tính năng vẫn có thể được xem là “pass”.Nhưng về mặt bảo mật, đó là một rủi ro.Nếu chỉ test theo luồng thông thường:đăng nhậpthao tác đúngkiểm tra kết quả hiển thịthì có thể sẽ bỏ qua những trường hợp quan trọng như:User có thể truy cập dữ liệu của người khác không?API có kiểm tra quyền thật sự không?Dữ liệu nhạy cảm có bị trả về quá nhiều không?Người dùng có thể cố tình thay đổi request để vượt qua giới hạn không?Từ đó, cách test của tôi thay đổi.Tôi không chỉ kiểm tra “happy case” nữa, mà bắt đầu suy nghĩ theo hướng của một người dùng muốn làm sai:“Nếu tôi cố tình đổi ID thì sao?”“Nếu tôi gọi API trực tiếp thì sao?”“Nếu tài khoản này thử truy cập dữ liệu của tài khoản khác thì sao?”Tôi cũng nhận ra một điều: security không nên là việc để đến cuối cùng mới xử lý.Tất nhiên, trong thực tế, các team luôn có áp lực về thời gian. Đặc biệt với những sản phẩm cần ra mắt nhanh, việc cân bằng giữa tốc độ và an toàn không hề đơn giản.Theo tôi, không nhất thiết phải xây dựng mọi thứ quá phức tạp ngay từ đầu. Cách hiệu quả hơn là xác định đâu là phần quan trọng cần bảo vệ trước:Dữ liệu cá nhân của người dùng.Quyền truy cập giữa các nhóm tài khoản.Các API quan trọng.Những luồng liên quan đến thanh toán hoặc thông tin nhạy cảm.Những phần này cần được đặt security ngay từ đầu, thay vì chờ đến khi sản phẩm lớn lên mới sửa.Trước đây tôi từng nghĩ security là phần việc chủ yếu của Developer. Nhưng sau quá trình làm việc, tôi thấy đây là trách nhiệm của cả team.Dev xây dựng hệ thống.QA tìm ra những góc nhìn khác.Product hiểu người dùng.Mỗi vị trí đều góp phần tạo nên một sản phẩm đáng tin cậy.Vibe coding hay phát triển nhanh giúp chúng ta kiểm chứng ý tưởng sớm hơn. Nhưng nếu chỉ tập trung vào tốc độ mà bỏ qua an toàn, cái giá phải trả sau này có thể lớn hơn rất nhiều.Bài học tôi rút ra là:Một sản phẩm tốt không chỉ là sản phẩm chạy được, mà còn là sản phẩm có thể bảo vệ người dùng khi mọi thứ không diễn ra như mong đợi.Build nhanh giúp sản phẩm đi trước.Security giúp sản phẩm đi xa.
challenge-post-cover
#4
0
14
challenge-icon

Solo builder: Vibe coding vs Cybersecurity?

user-avatar
Nguyen Hai
10/06/2026

Builder’s Note: Tốc Độ Tạo Ra Cơ Hội Và Bảo Mật Giữ Cánh Cửa đó Luôn Mở

Chào mọi người, mình là Richard, Hiện tại mình là Lead của một Builder Lab tại Unikorn.vn . Chúng mình là một Research labs tập trung vào nghiên cứu và phát triển các mô hình Agentic hiện hành và ứng dụng của nó vào thực tế. Trong quá trình làm việc với các builder, founder và developer, mình thường xuyên bắt gặp một cuộc tranh luận quen thuộc: Tốc độ hay bảo mật quan trọng hơn? Đây là một câu hỏi mà mình tin rằng không chỉ các builder, mà bất kỳ ai đang trong quá trình xây dựng sản phẩm, startup hay thậm chí là thương hiệu cá nhân trong kỷ nguyên AI đều từng đặt ra ít nhất một lần. Chúng ta đang sống trong thời đại mà một cá nhân có thể làm được khối lượng công việc từng cần đến cả một đội ngũ. AI giúp việc nghiên cứu nhanh hơn, phát triển nhanh hơn, thử nghiệm nhanh hơn và đưa sản phẩm ra thị trường nhanh hơn bao giờ hết. Nhưng chính vì tốc độ đó, một câu hỏi mới bắt đầu xuất hiện: Liệu chúng ta có đang đi quá nhanh so với khả năng kiểm soát những gì mình tạo ra? Khi sản phẩm bắt đầu có người dùng, khi dữ liệu bắt đầu được lưu trữ, khi những quyết định của chúng ta ảnh hưởng trực tiếp đến trải nghiệm của khách hàng, thì tốc độ không còn là yếu tố duy nhất cần được quan tâm. Đó là lý do vì sao cuộc tranh luận giữa tốc độ và bảo mật ngày càng trở nên phổ biến trong cộng đồng builder. Tuy nhiên, sau nhiều năm xây dựng sản phẩm, từ những dự án thất bại cho đến những sản phẩm thực sự được người dùng đón nhận, mình nhận ra đây có lẽ đây chưa phải là câu hỏi đúng mà là một insight đang hình thành. Với chúng mình, vấn đề không nằm ở việc chọn bên nào. Mà là hiểu rõ sản phẩm của mình đang ở giai đoạn nào. Bởi mỗi giai đoạn của một sản phẩm đều có những bài toán khác nhau cần giải quyết. Chúng mình không chọn giữa tốc độ và bảo mật, chúng mình chọn thời điểm thích hợp. Qua bài viết này chúng mình chia sẻ về góc nhìn hiện tại của team đối với quá trình xây dựng sản phẩm và vận hành trong kỉ nguyên AI. Build Fast, Harden Later Tìm kiếm cơ hội và xác thực giá trị. Khi mới bắt đầu xây dựng một sản phẩm, thứ chúng ta đang thiếu không phải là bảo mật, khả năng mở rộng hay một kiến trúc hoàn hảo. Thứ chúng ta thiếu là sự xác thực từ thị trường. Chúng ta chưa biết liệu vấn đề mình đang giải quyết có thực sự tồn tại hay không hay liệu giải pháp của mình có đủ hấp dẫn để người dùng thay đổi thói quen hiện tại. Rủi ro lớn nhất là dành hàng tháng, thậm chí hàng năm để xây dựng một thứ mà không ai thực sự cần. Mỗi sản phẩm đều bắt đầu bằng những giả định. Chúng ta giả định rằng khách hàng đang gặp một vấn đề. Chúng ta giả định rằng giải pháp của mình là phù hợp. Chúng ta giả định rằng người dùng sẵn sàng thay đổi thói quen để sử dụng sản phẩm mới. Nhưng suy cho cùng, tất cả vẫn chỉ là giả định cho đến khi được thị trường xác nhận. Đó là lý do mình luôn xem tốc độ là một lợi thế chiến lược ở giai đoạn đầu. Không phải tốc độ để viết nhiều code hơn. Không phải tốc độ để ra mắt nhiều tính năng hơn. Mà là tốc độ để học nhanh hơn. Một tính năng được hoàn thành sớm hơn có thể mang lại một phản hồi giá trị sớm hơn. Một ý tưởng được đưa ra thị trường sớm hơn có thể giúp chúng ta phát hiện sai lầm sớm hơn. Một tuần tiết kiệm được trong quá trình phát triển có thể giúp tránh lãng phí nhiều tháng đi sai hướng. Trong kỷ nguyên AI, bất kỳ ai cũng có thể tạo ra sản phẩm nhanh hơn trước đây rất nhiều. Nhưng điều thú vị là công nghệ không làm thay đổi bài toán cốt lõi. Nó chỉ rút ngắn khoảng thời gian từ "Tôi nghĩ đây là một ý tưởng hay" đến "Thị trường xác nhận liệu nó có thực sự là một ý tưởng hay hay không." Và theo mình, đó mới là giá trị lớn nhất của vibe coding. Bởi một builder không phải là người xây được nhiều thứ nhất. Mà là người dùng công cụ hiệu quả để tìm ra đúng thứ tạo ra giá trị thực sự. Nhưng đó chỉ mới là giai đoạn đầu hãy cùng chúng mình tiếp tục trong cuộc hành trình này nhé :> Earn Trust, Protect It khi đã có người dùng, hãy bảo vệ niềm tin mà bạn đã tạo dựng. Nếu tốc độ giúp chúng ta tìm thấy cơ hội, thu hút những người dùng đầu tiên và chứng minh rằng sản phẩm thực sự tạo ra giá trị, thì điều gì sẽ quyết định liệu cơ hội đó có trở thành tăng trưởng bền vững hay chỉ là một khoảnh khắc ngắn ngủi ? Liệu chúng ta đã sẵn sàng để gánh vác niềm tin mà người dùng trao cho mình hay chưa ? Đằng sau mỗi tài khoản là một con người và mỗi dữ liệu được lưu trữ là một sự tin tưởng. Mỗi lần họ quay lại sử dụng sản phẩm là một sự kỳ vọng rằng những gì chúng ta xây dựng sẽ luôn ở đó khi họ cần. Càng nhiều dữ liệu, càng nhiều trách nhiệm. Những quyết định kỹ thuật từng có thể tạm chấp nhận ở giai đoạn MVP bắt đầu bộc lộ giới hạn của chúng. Và đó là lúc mình bắt đầu nhìn nhận bảo mật theo một cách khác. Không phải như một checklist kỹ thuật. Mà như một lời cam kết của người xây dựng với những người đã lựa chọn tin tưởng sản phẩm của mình. Nó không tạo ra những con số tăng trưởng ấn tượng. Nhưng nó là thứ âm thầm bảo vệ tất cả những gì bạn đã mất rất nhiều thời gian để xây dựng. Và khi sản phẩm bước vào giai đoạn phát triển, bảo vệ niềm tin đó trở thành một trong những trách nhiệm quan trọng nhất của một builder. Đây là lúc nâng cấp bảo mật, tập trung vào các tính năng bảo vệ hệ thống, tránh rò rỉ dữ liệu và đảm bảo tuân thủ các quy định về bảo mật thông tin. Một câu hỏi mà nhiều người có thể đặt ra là: "Nếu bảo mật quan trọng như vậy, tại sao không đầu tư mạnh ngay từ ngày đầu tiên ? " Theo mình, câu trả lời nằm ở nguồn lực. Đặc biệt đối với các builder, startup hay những đội ngũ nhỏ. Thời gian, nhân lực và ngân sách luôn là hữu hạn. Mỗi giờ dành cho một việc cũng đồng nghĩa với việc không thể dành cho một việc khác. Trong giai đoạn đầu, thứ cần được chứng minh không phải là hệ thống của chúng ta có hoàn hảo hay không. Thứ cần được chứng minh là sản phẩm có thực sự tạo ra giá trị hay không. Bởi nếu không giải quyết được một vấn đề thực sự của người dùng, thì dù kiến trúc có đẹp đến đâu hay bảo mật có tốt đến đâu, sản phẩm vẫn khó có thể tồn tại. Nhưng khi sản phẩm bắt đầu có người dùng, mọi thứ thay đổi. Lúc này chúng ta không còn bảo vệ một ý tưởng. Chúng ta đang bảo vệ dữ liệu, công việc và niềm tin của những con người thực sự. Đây cũng là thời điểm mà chi phí của một sự cố bắt đầu lớn hơn rất nhiều so với chi phí phòng ngừa. Một lỗi nhỏ ở giai đoạn chưa có người dùng thường chỉ ảnh hưởng đến builder. Nhưng cùng lỗi đó ở giai đoạn tăng trưởng có thể ảnh hưởng đến hàng trăm hoặc hàng nghìn người. Đó là lý do vì sao mình cho rằng đây là thời điểm lý tưởng để đầu tư mạnh hơn vào bảo mật. Không phải vì bảo mật đột nhiên trở nên quan trọng. Mà vì lúc này cuối cùng đã có một thứ đủ giá trị để bảo vệ. Kết luận Sau tất cả, mình không nghĩ đây là cuộc tranh luận giữa tốc độ mà vibe coding đem lại và bảo mật. Bởi vì một sản phẩm thành công cần cả hai. Tốc độ giúp chúng ta khám phá cơ hội, nó giúp chúng ta học hỏi nhanh hơn, biến những ý tưởng trên giấy có cơ hội trở thành giá trị thực tế. Nhưng khi cơ hội đó xuất hiện, khi người dùng bắt đầu tin tưởng sản phẩm và khi những giá trị thực sự được tạo ra, bảo mật trở thành một phần không thể thiếu của hành trình. Không phải vì chúng ta sợ rủi ro. Mà vì chúng ta tôn trọng những gì mình đã xây dựng và những người đã đặt niềm tin vào nó. Là một builder, điều quan trọng không phải là chọn giữa tốc độ hay bảo mật. Điều quan trọng là hiểu sản phẩm của mình đang ở đâu trên hành trình phát triển. Biết khi nào cần tăng tốc. Biết khi nào cần củng cố nền móng. Biết khi nào cần theo đuổi cơ hội và biết khi nào cần bảo vệ những cơ hội đó. Đó cũng là cách mà team chúng mình đang tiếp cận việc xây dựng sản phẩm trong kỷ nguyên AI. Không ngừng đổi mới, học hỏi. Nhưng cũng không quên trách nhiệm đi kèm với sự tăng trưởng. Bởi cuối cùng: Tốc độ tạo ra cơ hội. Bảo mật giúp bạn bảo vệ cơ hội đó. Cảm ơn các bạn đã quan tâm <3 
challenge-post-cover
#1
13
187

You've reached the end.