My open-source experience

sahaj srivastava — Tue, 06 Oct 2026 07:03:46 +0000

When I first entered the college I head of the word Github and open-source contribution. It sounded strange at first that how solo developers can make a contribution to major software which people use in their daily lives. When I entered the field of open source development I understood that there is more to it that meets the I. Open-source development is actually about developers find potential bugs and enhancements and how to work on them thoroughly and making sure that out work is recognized. This makes a good developer portfolio or what I am told by the way.

Well here are the three learnings that I faced and reflected over my first official open source contribution through kalvium Ed-tech organization:-

=> The problem and the work: This week I worked on BookCars (aelassas/bookcars), a TypeScript-based car-rental platform, and investigated a possible authorization issue in the booking system. I focused on the updateStatus() endpoint, where a supplier can update booking statuses after passing authentication and the supplier-role check. While tracing the code, I noticed that the endpoint looks up bookings only by their IDs and does not verify that the booking actually belongs to the supplier making the request, unlike the existing deleteBookings() logic which explicitly checks supplier ownership. I compared the relevant route, controller, and authorization code instead of assuming that the issue existed from the endpoint name alone. My work was therefore mainly code investigation and evidence gathering, with the potential issue being that one supplier could change another supplier's booking status if they obtained its booking ID.

Issue: Github Issue link

=> How you used and verified AI: I used AI mainly as a second pair of eyes for code exploration and reasoning, rather than treating its answers as proof. For example, AI helped me identify that I should compare the updateStatus() controller with other booking operations and inspect how supplier authorization was implemented. I then opened the actual repository code myself and verified that the route uses authJwt.verifyToken and authJwt.authSupplier, while updateStatus() queries bookings by ID without checking the supplier ID. I also checked deleteBookings(), where an explicit comparison between the logged-in supplier and the booking's supplier already exists. This comparison was important because it showed that the concern was based on an actual difference in the code rather than simply trusting AI's claim that the endpoint was vulnerable.

=> Reflection: The hardest part this week was not finding something that looked suspicious, but proving that it was actually worth reporting. I had to trace the request from the route through the authentication middleware into the controller and then compare it with another endpoint before I could understand the authorization gap properly. I learned that good open-source work requires much more than spotting a possible bug: I need to understand the surrounding architecture, existing security patterns, expected behavior, and potential impact before making a claim to maintainers. Next week, I will spend more time creating a minimal local reproduction or regression test before proposing an issue, so that my reports contain executable evidence rather than only static code analysis.

DEV Community: sahaj srivastava

My open-source experience